Austin Hay: preference

Transcript context

…You're like, that's just permissioning gone wrong. So, I think a big part of the role is designing systems that are automated to handle that stuff because ideally you don't want to be sitting around in your computer all day clicking one conductor request to approve permissions. You should look at the role, look at the experience of tenure and department and make a decision about which accesses you get. So, automating that is a big part of my job. The manual part of my job, which I feel like is actually really fun, is again the designing systems and contracts for the future. So, it's about how do we design a system and create a vision and persuade people about what our system technology can look like over the course of one to two years, the time span that I usually look at. And then how do you change state from then to now? Some of that has to bring in financials and contracts. That's where this plays a role. What are our contract terms today? What's the price we're paying? What is our growth going to be? Can we build a financial model to show how much it's going to cost us both in terms of operational efficiency and actual real fixed and variable costs to end up in that state? And then how do I create a graceful argument to persuade people that we should spend engineering time and resources? And usually it nets out pretty clear. It's like if it's less than a certain amount, how do you justify spending any engineering time on it? You have to wait for the problem to become big enough. But then back to your other point around how do I give growth managers out there something useful. I would say the big thing that people forget in an early stage of a company's lifetime is that the company will outlast you, hopefully. You will not be the last growth manager unless the company fails. So, I tend to take a little bit of a different approach than most, which is like I think you should always be thinking about the future. That doesn't necessarily mean you should make design choices that over index towards the future so much that you miss product market fit or you make poor product decisions. But when you set up tools and you pick tools and you implement them, you should be thinking, what's going to happen a year from now if I don't change anything? And is this going to be a catastrophic situation or not? And then try to take actions to mitigate that risk. Some examples are like if it's $2,000 to get SSO and two days to set it up and that prevents you from having a security problem where somebody downloads all your users, it seems like a great investment. And guess what? Over time, if you don't do that, you're going to eventually have to hire an IT person to go and set up SSF for all your tools. So, some of this is more of just being a good steward about managing first and third party tools with an eye towards the future. It's always a trade-off, right? o go and set up SSF for all your tools. So, some of this is more of just being a good steward about managing first and third party tools with an eye towards the future. It's always a trade-off, right? Because the more time you spend when you're building product early in a company's lifetime, that time could be spent on other things. So, if you waste it managing third party tools or setting up correctly, then maybe you miss out on a key product feature. So, I think it is a tough balance to strike. Coming back to the different kind of roles within the growth umbrella, if someone has someone leading paid growth let's say, and they're just like a paid growth person, do you also find a MarTech person to work alongside this person? How connected would you be to someone that's just responsible for paid growth?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.