Office of the CTO Playbook with Auth0 CTO & Co-Founder Matis Woloski | SaaStr Software Community

All right, well, thank you and glad to be here at Zaster Enterprise. And so I'm going to talk about the Office of the cto, which is my organization right now. It's about running this team and it's called the Office of the cto. The agenda really is about first some context. You know, my journey, how I came to be the cto, the type that I am today, and what's been my journey to get there from a product engineering standpoint. Then I'm going to touch on, okay, what is it looking like to run an office of a cto? What is the vision for the team and the charter that we set up for that in conjunction with the broader product engineering organization? And then we have, I'll touch on like more tactical stuff like focus areas and work streams for a team and then plus with some key takeaways. So feel free to ask questions in the chat. We have a fair amount of time for that. I think I'll speak for around 20 minutes or so with kind of like these areas and then we'll open up for questions and use the opportunity really to just ask whatever you want. I'm open book from that point of view. Nothing is sacred. Cows. So moving to the first slide. Office of the cto. If you ever heard of that term before, it can mean many things, different things depending on the type of organization that you are working on. So for example, if you ask in VMware what the office of CTO is about or if you guys in Google Cloud, it's probably like a 20 people, 30 people team that typically works together with the sales organization, the field teams, and they're a little bit of like a glorified field CTO team and they help customers become more successful adopting the platform. They kind of bridge the gap between business and technology and that's kind of how it works, you know, bigger scale companies. There are also other type of office of the CTOs where it's more about research. And by the way, when I'm saying office of the cto, it's really all like, you know, when you become a bigger company, you know, like we are like seven years in now, eight years in out of zero. The CTO founder who used to run everything, like what are you going to do next type of thing. So, so that's why also it's being used in that, in that context too. And so that's where I'm coming from too. So I'm going to explain like what's been my journey that took me to create this small Organization within the product engineering organization. So Alcido started in 2013. We were funded. And I have my co founder, Eugenio, who is the CEO today. And I was a CTO when we started the typical, like, you know, he was more focused on customers and sales. Even though he's an engineer, he was focused on that. And I was focused on technology product. And so that's been how we created the product and the initial. The initial teams. And this has been like the case for at least four or five years. So in 2017, it was the first time that I delegated a function that I was running to an executive. And this was when we hired the CISO chief security officer in 2017. And we had. And this was kind of like the first thing that I felt that, you know, I wasn't an expert on and I didn't really have experience doing it before. And it requires deep expertise. So I, you know, we hired that person, that person reported to the CEO and I kept running product engineering design and all the product engineering functions. In 28 and 2018, we hired our first VP of Engineering. Until then, I was kind of like the VP of Engineering, and I have a couple of directors of engineering. And so this was the first time I kind of delegated the function of engineering. And also we wanted to hire a good VP of engineering. So this person also reported to a CEO. So at that point, I was like running product on one side. Security was another department and engineering was another department. So I had product design at that point. And this is one. The first time that I created like the office of a cto, which was a little bit of like, all right, you know, engineering doesn't report to me anymore, but I still have all these ideas and concepts that I want to work on, but I don't have a team to work on those. Right. Because now this is. This is running engineering, so I need to borrow resources or something. So I ended up creating this small team, which typically is like the OG in the company, like the people that you started with the early engineers, and there was like three or four people. And this first version of the Office of the CTO wasn't successful. I mean, it was okay, but I guess not successful from the point of view of what I was really wanting to do, which is like incubating new products. And the reason. Reason that that happened is because this, this the context of where we were in that at the time in the company, we weren't mature enough or like, we weren't in that time where like, this was going to be successful. So the engineers on my team ended up being a little bit more like filling the gaps and swatting. And we will do some architectural work and some look at the holistic big picture of the product and say, well, we need to fill these gaps here and there, or we need to bootstrap these new items in the roadmap. But we will always be working on the current roadmap and not future things. So that was a bit problematic in 2019. It was like me trying to find my ikigai, if you know that term, what my passion is, what I can add value as a CTO founder. And so in 2019, we hired our CPO, which is currently with us. And this was a key kind of milestone and decision point, at least in my journey, because at that point, I didn't have any more operational responsibility for the teams. Everything was run by executives that had more experience than I had. And honestly, that was the right thing to do as well. You can scale up to a certain point, and if you haven't done this before and that's not what you like doing, then you have to let it go. And so that's when OPTO, obviously, the OB2 was born. And in fact, I made a decision to report to the cpo, which takes me to the next slide that talks about the structure, the org structure, that I think it's a key aspect of making this model effective. So in this model, we have the CRO, which is our field, revenue, marketing, sales. And then you have the cpo, which is all things about product delivery. It's like delivering the product no matter what time frames and horizons of the roadmap. And so the VP of Product, VP of Engineering, and myself reports to the cpo. There is also program management and other functions on that team. But I'm highlighting here that I'm a peer to the VP of Engineering and the VP of Product, which I think, because what happened otherwise, when if I would be reporting to the CEO, is that I will have a lot of conflicts with the cpo, right, in terms of, like, oh, you know, I'm gonna. I'm gonna go and do this, like, lab experiment things. And, you know, I would. You know, I'm a builder, so I would. I would want to be. To see those things become a product. And so, like, you know, you have to have like, a super great relationship with the CPO for this being a successful model. And so I, you know, I don't think. I mean, that was. He was a new person, so I think it was better to just be part of the whole product delivery organization. So that was the org structure that we set up for this to work. And you know, going now into like, okay, now that we know where we fit in the organization, what's the charter for the team? And by the way I have a small team, it's four or five core people. I will explain in a little bit how we incubate products but essentially this small team is focusing on this 18 plus month horizon, meaning working ahead of engineering in adjacencies and stuff that we can get into that we don't have the bandwidth to look into with a core product engineering organization. So we do prototyping and we do research. We do also some strategic corp dev like the technical side of things and staying aware of what type of companies are out there, what type of potential acquisitions we can do. Um, but it's a little bit like, of like getting yourself out of the water and you know, look ahead and like okay, what are the products that we can incubate that will become a product in a year and a half, two years time frame? So it's, it's, it's like a call is planting the seeds. And it's also similar to how BC kind of model works where startups are going and need to make a pitch or business case of why we should invest in something. So it works in that way too. And that's how we fund. Not just I have a small team that is kind of the bootstrapping aspect of it. Maybe we prototype something and then at some point we make a decision to invest on that idea because we showcase that to the leadership team and it's a good investment. And so that's when we fund and funding means okay, we can now hire a team that can build that product which it's still on my team to incubate. So I go into how that will transition later on to the core organization. And, and the last point is that this is you know, like this is not about research in the way that like it's lab type of research of like things that are not connected with customer problems and like super like futuristic ideas. It's really about understanding the market and the customers and their problems. So you know I have, I talk a lot with customers with my team and we make sure that we incorporate feedback early on. And that's why it's like Horizon 2 is this a year and a half. There are some companies that have three horizons. Horizon 1 is the core roadmap, organic roadmap. Horizon 2 is this type of product adjacency we can get into or next product type of things. And then Horizon 3 is really about how the future will look like and how we can get ready for that. And that's more like maybe three, four, five years horizon and that's. And so but I mean like my team is in that middle horizon and this visualizes a little bit what I'm saying. Some companies have Horizon 3 which starts here and look at how the whole industry might change in, in four years from now. Which you know, it's totally valuable. But in the stage where we are as a company, it made sense to first split between two horizons and not three. And probably as we continue to grow there might be some room for like doing Horizon 3 stuff. So the other important aspect of like alignment between the office of the CTO and the rest of the organization, apart from like the org structure that it's. It's a critical piece. It's also like how you define these swim lanes across the the product organization. Right. For the same reason that you don't want to create conflicts. So this two by two metrics shows products and markets. And if you look at the bottom left quadrant, that's really where the product core organic roadmap lives. It's building our existing product, selling to our existing market. So in the case of Auth0, this is Auth0 core product selling to developers. The market is developers. If you go up in one quadrant you have the kind of going to new markets. This is an area that it typically happens within the product organization. Let's say we want to start selling to the fintech market or we want to start selling to more security CISO type of organizations. So we will have to adjust the product to be more to have features or to be better suited for those markets. Actually we put this kind of as a focus area, but we don't do that much in practice. It's easier to just focus on new products selling to the existing market. Meaning these are product adjacencies that we have a sales force already that can sell to our existing customers because it's the same audience that we sell the core product. And so it's all these adjacencies to authentication in the case of OD0 that we can get into and sell to customers. So another kind of part of bringing clarity in when you're setting up this type of organization is what are the actual focus areas that the team. The team will be doing. So in this case like this is a blurred picture because there is actual like things Here, this is the actual mind map that I did for auth0. And the whole idea here is really that this is all the adjacencies, this is all the things that we can get into. It serves a little bit the purpose of painting the picture and then highlighting the stuff that we would, we would want to focus on in the short term as a team, right? So again, it's all about clarity and alignment within the organization. And this is a public thing that anyone in their org can look at. Then you have like I put here, the work streams. Getting more tactically speaking here, product adjacencies is the core, like the main thing that we are currently focused on. Once you kind of agree on the things that you're going to focus on, then it's about building those things, prototyping those things and validating with customers and creating that first mvp. But we also do this, as I said before, like corporate development, technical arm. If there is a potential M and A or partnership that requires that we get involved in doing some technical decisions, we also do some of that and it's more opportunistic. That's why it's probably like 10% of the time for a team. And the last piece is this research, demos, white papers. This is more about these kind of longer term topics that maybe it's three, four or five years ahead that we want to get a point of view on, but we are not ready to build a product for this. This is examples. Here is like, well, the centralized identity is one of those things that might be something that we want to focus on in the future because it becomes a thing on its own. And so we want to get a point of view of how this thing will connect with our core product. And so we do some research, some demos, maybe some partnerships and we get informed on the subject. And for example, we are about to publish a blog post around decentralized identity without zero. And that's coming also from this team. And the final thing that I want to talk about is this whole thing about transitioning from office of the CTO to the product engineering organization. This is most likely where most of the pain comes from. And this is again based on experience. And why we made a couple of decisions to change the model is because this is where the friction comes in, right? Like, first of all, nobody likes getting code. So our defense, right? So if you are an engineer on a certain team and a PM on a certain team and like, okay, here is a great idea that we validated and we build an MVP for go ahead and maintain it and grow it. Now that's of course the recipe for failure. So the way that we structure this is in the first line. There you see Office Obsidian doing the research. We decided something is worth prototyping with and validating. And so we, you know, we build like this kind of minimum kind of prototype to see if like I call it like, you know, it's similar to like trying to find oil. It's like you try, you start like doing the whole and see if like there is oil coming from there. And it's a little bit of intuition market and talking to customers. And so what happens during that time is that this is typically in a timeframe of three months, six months. We collaborate with the product manager that is part of the product management organization. This is where you start creating alignment and collaboration among the organization. And it's not just us kind of going solo, rogue and trying to build something, but there is the PM already getting involved, talking to customers, like building what we call the business case. At that point when we have something solid that we can present to the leadership, we go and present it and say, hey, this is the opportunity that we see ahead for this type of product. And this is where a funding decision is made and funding decision, release. Like here is budget to build the team and build the product. Not just build a product with this small core team that I have, but more like hire the people to build the product. So that's one like, you know, we start hiring a PM team and this is so like, you know, this timeline is like looks super clean here. Of course it's much more nuanced and there is overlaps in things. But you can imagine this is a little bit how it works for some time. As we build the team, we continue to work on the product, we continue to work on validation and discovery. And this is done in conjunction between office of GTO and this PM and designer. This is when we start. It's not a transition, but it starts to become a product at some point in that journey. And this is a little bit like tied to like 18 plus month horizon. Right in that journey you get to a point where like okay, you know, we validated this product. We have like 10 customers using this in. We call it early access. So we are ready to transition this now to be properly staffed and maintain and scale in the product organization. And that's when, you know, that's when we transition off and it becomes a product itself. That's how the office of the CTO works at Auto. And again, this is Our flavor of office of cto. And as I said, a lot depends really on the personality and the skills of the cto. I am a builder myself, and that's why this is a model that works for me and works for Auth0 as well. So far, it's been running super well. And again, there are some key takeaways here that I think are worth repeating. Which are One is the organizational structure. And buying, organizationally speaking, is a critical aspect. I cannot emphasize this enough. If you're trying to do this and you report to the CEO, it's gonna be tough. And you have to be ready for friction. And so unless there is some specific. The person who runs product engineering, it's like it's another founder, for example, and like, you know, have like, great relationship. Maybe it works, but. But it's, It's. It's gonna bring friction. So it's better if it's all under a single leader. The second takeaway is, is clear horizon or responsibilities, which is another, like, reinforcement of keep things clear for everyone. And by having these horizons and kind of like focus on product adjacencies that are not touching the core, then there is no friction. Also with the engineering team, for example, you cannot take dependencies on the engineering team because that's also going to bring some issues. Maybe you can take a few, but they have to be super, like, handpicked in a way. Finally, the last point is you have to get budget to do this. Because if you just try to do this with three people, what will happen is that you will prototype on something, you will create this amazing idea, but then nobody's gonna pick that up, nobody's gonna put it on the roadmap because there's gonna be always more important things to do. So unless there is very great support, organization is speaking. But getting the budget means that now you have the room to build the team yourself and then move it off and becoming a team on the core organization. And so with that, thank you. I think there are some questions. I'm gonna stop sharing here and put the chat. No, there is no. All right, so I'm open for questions. There is a new question here from Joaquin. Which metrics are used for prototype validations? So that's a good question. I tried to find the perfect metrics for this, but the reality is that it's the same thing that when you're incubating a startup, like, there is a bit of intuition and a bit of, like, gut feeling and market understanding. So the best proxy really is just talking to customers. And find quotes. Find like for example, one thing that we are doing is we actually put a price on something that we are building and we are asking the customers, you know, would this be something that you would pay for? And so from that perspective, it's not just about getting the oh yeah, this is awesome. But this is how much it was cost. Is this worth paying and potentially building? And then of course this model works well when you're more mature as an organization. So you know, what are the chases that you can get into? I wouldn't do this in the first three years of the company because there is so much to do in the core business that you are that you will be wasting time and focus more importantly. So yeah, that's a good. All right, second question. How do you support technical employees that are transitioning to leading teams and people? How do you support technicals that are transitioning to leading teams and people? So are you asking from the perspective of my team officer of CTO, the incubation of the team? Can you clarify a little bit that question, Taylor? If you don't mind, I'll go to the next one. So Martin is asking great overview. Besides the three hours itself, what are the tools frameworks you used to know that you are in the right horizon. Oh, three horizons. Sorry, three hours. What are a tool framework you used to know that you are in the right horizon and not looking too close too far? Yeah, okay, good question. So I will go back to that like two by two matrix really. I think and that's why it's also important to mention that you should do this when you are more mature. Because otherwise your focus has to be on that organic core problem. You probably haven't finished building that you yet. Right. So and you never finish. But there is a lot to do. There are still to win the market that you are in. So in terms of tools and framework, I think that's really the best. Like you would look into adjacencies and adjacencies really the way, the best way I found myself thinking about it is what are the things that I could build that doesn't require to touch the core product, but are still things that I could sell to my existing customers. Right. That that is probably the best way to think about it. And I can, you know examples of that. Like for example, we're looking now into fine grain authorization. Authorization of course is super close to us. But we are building this in a way that it can actually be a standalone product on its own. But we have a better to weather story Meaning that if you use this new product without serial core product, then it's even better. Anyway, that's the answer to that. Okay, Taylor says, what was the biggest challenge when creating your office of a cto? What are your best tactics for overcoming the friction? Good question, too. So everything I said around clear swim lanes alignment and communication, that's kind of like zero. Like this level zero, right? Like, you have to do that. Otherwise, you know, people start wondering, like, why is these people doing this new stuff? And, like, we're doing this other stuff, right? So that has to be super clear. And it has to come from leadership. So that is the best, really the best way to overcome friction. But then there are, like, ways also to alleviate. Like, because still, like, people think that, oh, well, you know, officers here is doing these new things and we are not. And so, for example, with my team also, because they are like people that have been around for a while, we do a problem that we call gaku, which is a mentorship program that anyone can sign up to, and we help anyone in the organization to become better and help them on the job. And so that creates this kind of, like, connection between the office of CTO engineers and the core engineering team. And that's been successful because at the end of the day, you want to have a good relationship among. Among everyone, right? So then we also do internal. Internal hiding. So, for example, now that we are building some new stuff, we do the internal hiding from people that are in the core engineering team. And we want to, you know, we want to give them the opportunity to work on this stuff. So those are a couple of things to overcome the friction. There is also, like, potential rotation. I haven't done rotation myself. I found that to be a bit disruptive. Disruptive for people. And in general, like, it didn't suit well, but internal hiring is better. All right, so now. So the clarification from Taylor on the people leader question, I'm thinking many people on your team have more technical backgrounds, but then moving to roles within office of cto, where they are leading people, how do you help manage and support that? Okay, so, yeah, so. So the reality is that the people in my team are like staff level engineers and principal engineers. These people typically have done some management before. These are not junior engineers. Of course, that wouldn't work because this is a, this is a space for more of the pioneers and the people who have been there, done that type of things. So it really. So. But having said that, there is a, you know, throughout the journey of building new things, there Is some time that like where you let these people like work on these ideas on their own, right. And like try to develop these initial prototypes and then you start hiring the team when you are like, okay, we are ready to move to the next stage and then that's when they become engineer managers. But they don't become managers for forever. Probably 3/4, 4/4 later, the team transitions towards the core engineering team and we go back and start again. So it's a little bit of a mix and so far it's been working well. They don't need, they are okay as managers as well. All right, another question. How do you collaborate with other department like sales, marketing, etc. Right. So a couple of, yeah, touch points that we have on that front with sales and the field in general. It's actually, you know, I do a lot of stuff with them because this is the way that you validate the stuff that you're building, right. And you're delivered on your own from that point of view because well, there is a 95% of the energy is on the core product and there is like field enablement and all this stuff that happens at the organization as business as usual. And so for example, what I do is I'm always like on the, on the lookout for customers who might be good, good candidates for a certain thing that we are doing. Right. So and this is more of like me kind of being like on the, on Slack channels and looking at Salesforce and you know, understanding and being with customer calls and where I pick up these like few customers that I want to use as the ones that give us feedback and early kind of solid like partners for us to build things. So that's a bit of partnership with sales and the field, with the marketing team. It's more about, for example on this kind of research and demos and like we, you know, we do blog posts and those things, you know, we collaborate with marketing on with what type of blog posts and how, et cetera. Yeah, so those are like two typical touch points that we have. Right. We have another question. How do you guys handle the embed call out phase as to make sure this doesn't drain the energy focus and the possibility to keep working on new prototypes. What's your experience? Okay, good question. So the, the reality is that, that, that phase really, I mean it's, we are not gonna go like it. You know, it's a cycle, right? So you start doing something, it's, it's a prototype. You work on your own, you start hiding like it makes sense. You Start hiring the team. You build a team, you build the product. This is probably like from 9 to 12 months, right? During that time, you know, we are not looking at another product, another idea. Now we are in, you know, kind of like in incubation mode. Once we. And this is kind of, by the way, this is how it works today. So once it's. At some point, like in these nine to 12 months, like, this is, you know, we already working with the core engineering team and we handed off, like, the team, and after that, we go back to the first step again. So we are not doing the handoff. And at the same time looking at new things maybe we do with, like, these are things, like there are multiple of these happening at the same. So right now I'm running three. Three of these new products, right? None of, like, not all of them might become a product. And maybe, let's say two of the three become a thing, but maybe I will stage those, right? So I will focus first on the one that I see most of the potential, and that's the one that we will hand off, and then the other one continues running. And then. Because also you cannot do a lot of these handoffs at the same time, right? So you have to be a little bit more focused on that. So that's how it works. All right, great questions, by the way. And I think we have no more questions, but feel free to follow me on Twitter. I will pause here and you can DM me. I have DMs open. If you have more questions, I'm happy to. Happy to help you.

Perfect. Thank you so much, Mateus, for that great session. We have a lot more. I think this is ending our sessions for the day, but thank you so much for joining us for Saster Enterprise.

Thank you, everyone. Bye bye.