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. 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 the 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 more tactical stuff, like focus areas and work streams for the team, and then close with some key takeaways. So feel free to ask questions in the chat. We'll 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, you know, ask in VMware like 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 are 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. Bigger scale companies. There are also other types 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 7 years in now, 8 years in at Opsido, the CTO founder who used to run everything, like what are you going to do next? Type of thing. So that's why also it's being used in that context too. And so I'm— 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 We're funded and I have my co-founder Eugenio, who is the CEO today, and I was the CTO when we started. The typical, like, you know, he was kind of 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 4 or 5 years. So in 2017, it was the first time that I delegated the function that I was running to an executive, and this was like 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 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 2018, we hired our first VP of engineering. Until then, I was kind of like the VP of Engineering and I had a couple of directors of engineering. And so this was the first time that I kind of delegated the function of engineering. And also, you know, we wanted to hire a good VP of Engineering, so this person also reported to the 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 of the first times that I created like the office of the 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 like 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 running engineering, so like I need to borrow resources or something. So I ended up creating this small team, which typically is like the, you know, the OG in the company, like the people that you started with, like the early engineers. And, you know, it was like 3 or 4 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 wanted to do, which is like incubating new products. And the reason that happened is because this— the context of where we were in that at the time in the company, we weren't mature enough for 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 like SWAT team, And we would do some architectural work and some like kind of 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 like the roadmap, like the current roadmap and not future things. So that was a bit problematic in 2019. It was like me trying to find like my ikigai, if you know what that term means. Kind of 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, you know, a key kind of milestone and decision point in the— at least in my journey, because at that point, like 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 know, 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, right? So that's what— that's— and so that's when I opted— 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 CEO, 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 am highlighting here that I'm a peer to the VP of Engineering and the VP of Product, which I think— because what happened otherwise, if 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 go and do this like lab experiment things. And, you know, I'm a builder, so I would want to see those things become a product. And so like, you know, you would have to have like a super great relationship with the CPO this be a successful model. And so I don't think— I mean, 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 going now into like, OK, now that we know where we fit in the organization, what's the charter for the team? And by the way, this is— I have a small team. It's 4 or 5 core people. I will explain in a little bit how we incubate products. But essentially, this small team is focusing on this 18+ 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 the core product engineering organization. So we do prototyping and we do research. We do some also some strategic corp dev, like the technical side of things. And like kind of staying aware of like, you know, what type of companies are there, what type of potential acquisitions we can do. But it's a little bit 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, 2 years timeframe? So it's like I call it planting the seeds. And it's also similar to how VC kind of model works where, you know, startups, they are going and need to make a pitch our business case of why we should invest in something. So it works in that way too. And that's how we fund, not just like— it's also— 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 we— it's still on my team to incubate. And so I go into how that will transition later on to the core organization. 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 talk a lot with customers, with my team, and we make sure that we incorporate feedback early on. And it's gonna— that's why it's like Horizon 2 is this a year and a half. There are some companies that have 3 horizons. Horizon 1 is the core roadmap, organic roadmap. Horizon 2 is like this type of product that Jason M. Lemkin said we can get into, or like next product type of things. And then Horizon 3 is really about like how the future will look like and how we can get ready for that. And that's more like maybe 3, 4, 5 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 like look at, you know, how the whole industry might change in 4 years from now, which, you know, it's totally valuable and— but in the, 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, the other important aspect of like alignment between the office of the CTO and the rest of the organization apart from the org structure, that it's a critical piece, it's also how you define these swim lanes across the product organization, right? For the same reason that you don't want to create conflicts. So this 2x2 matrix 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, the Auth0 core product selling to developers. The market is developers. If you go up in one quadrant, you have the market 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. We 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 Auth0 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, okay, what are the actual focus areas that the team will be doing? So in this case, this is a blurred picture because there is actual 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 want to focus on in the short term as a team. So again, it's all about clarity and alignment within the organization. And this is a public thing that anyone in the org can look at. Then you have like the— 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 agreed on like the things that you're going to focus on, like then it's about building those things, prototyping those things, and, you know, 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&A or partnership that requires that we get involved in doing some technical diligence, we also do some of that. And it's more opportunistic. That's why it's probably like 10% of the time for the team. And the last piece is like this research, demos, white papers. This is more about these kind of longer-term topics that maybe it's 3, 4, or 5 years ahead that we want to get a point of view on, but we are not ready to build a product for this, right? So this is like examples here is like, well, decentralized 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 these things 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 just— we are about to publish a blog post around decentralized identity with Oxido, 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? First of all, nobody likes getting code thrown over the fence, right? So if you are an engineer on a certain team and a PM on a certain team and like, OK, here is a great idea that we validated and we built 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 structured this is we— so in the first line there, you see Office Obsidio 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 to— you start like doing the whole and see if like there is all 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 3 months, 6 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 really is 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 when we start hiring a PM team. And this is all like, you know, this timeline 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. And so for some time, there is, you know, 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 the CTO and this PM and designer. This is when we start like, it's not a transition, right? But it starts to be become a product. At some point in that journey, and this is a little bit like tied to like 18+ month horizon, right? In that journey, you get to a point where like, OK, 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 maintained and scaled in the product organization. And that's when we transition off and it becomes a product itself. That's how the office of the CTO works at Auth0. 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 the model that works for me and works for Auxilio 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 like, 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 going to be tough and you have to be ready for friction. And so unless there is some specific, like 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 it's gonna bring friction. So it's better if it's all under a single leader. The second takeaway is clear horizon of 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, hand-picked in a way. And finally, the last point is you have to get budget to do this because If you just try to do this with 3 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, right? Nobody's gonna put it on the roadmap because there's gonna be always more important things to do. So unless there is a very, very great support organizationally 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 going to stop sharing here and put the chat. No, there is no. All right, so I'm open for questions. Oh, there is a new question here from Joaquin. Which metrics are used for prototype validations? So that's a good question. I try to find, you know, the perfect metrics for this, but the reality is that when you're— it's the same thing that when you're incubating a startup, right? 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 will cost. Is this worth paying and potentially building? And then, of course, this model works well when you are more mature as an organization. So you know what are the cases that you can get into. I wouldn't do this in the first 3 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 technical employees that are transitioning to leading teams and people? So are you asking from like the perspective of my team, Office of the CTO, the incubation of the team? Can you clarify a little bit like that question, Taylor, if you don't mind? I'll go to the next one. So Martin is asking, great overview. Besides the 3 hours itself, what are the tools, frameworks you use to know that you are in the right horizon? Oh, 3 horizons, sorry. 3 hours, all right. What are the tools, framework you use 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 2x2 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 product. You probably haven't finished building that yet, right? So, and you never finish, but there is a lot to do there 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 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? That is probably the best way to think about it. And I can, examples of that, for example, we are looking now into fine-grained authorization. Authorization, of course, is super close to us as an adjacency, but we are building this in a way that it can actually be a standalone product on its own, but we have a better-together story. Meaning that if you use this new product without Cero core product, then it's even better, right? Anyway, that's the answer to that. Okay, Taylor is asking, what was the biggest challenge when creating your office of the CTO? What are your best tactics for overcoming the friction? Good question too. 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, you know, 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, Office SEO 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 program that we call Gaku, which is a mentorship program that anyone can sign up to, and we help anyone in the organization to, you know, become better and, you know, help them on the job. And so that creates this kind of like connection between the Office of the 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 everyone, right? So Then we also do internal hiring. So for example, now that we are building some new stuff, we do the internal hiring from people that are in the core engineering team and we want to, you know, we want to give them every— we want to give everyone 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 like to be a bit 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 the CTO where they are leading people. How do you help manage and support that? Okay, so Yeah, 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 space for more the pioneers and the people who have been there, done that type of things. So it really— but having said that, there is a— throughout the journey of building new things, there is some time where you let these people work on these ideas on their own, right? And 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 engineers, managers. But they don't become managers forever, right? Like, you know, like probably like 3 quarters, 4 quarters later, the team transitions towards the core engineering team and we go back and start again, right? So, you know, it's a little bit of a mix and, you know, so far it's been working well. They don't need the— they are okay as managers as well. All right, another question. How do you collaborate with other departments like sales, marketing, etc.? All 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 a little bit on your own from that point of view because, well, there is the— 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 candidates for a certain thing that we are doing, right? So, and this is more of like me kind of being like on the 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 both type of blog posts and how, etc. Yeah, so those are like two typical touch points that we have. All right, we have another question. How do you guys handle the embed collab 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 reality is that that phase really, I mean, we are not gonna go like, you know, it's a cycle, right? So you start doing something, it's a prototype, you work on your own, you start hiring, like it makes sense, you start hiring the team, you build the 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 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 this 9 to 12 months, like this is, you know, we are 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— this is another thing. It's like there are multiple of these happening at the same time. So right now I'm running 3 of these new products, right? Not all of them might become a product and maybe let's say 2 of the 3 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, you know, 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. 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 post here, @woloski, and you can DM me. I have DMs open. If you have more questions, I'm happy to Happy to, 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 SAS/STR Enterprise.

Thank you, everyone. Bye-bye.