Growing Others to Grow Yourself

Transcript

Troutt: I'm Audrey. CTO at Tomo, which is a real estate and fintech startup. The CTO is very new. I want to talk about growth. I want to talk about transitions in your career. This is very top of mind for me, because I became a CTO about one month ago. It's a big deal. This is a dream job. This has been my dream job for a long time. Before that, for the last two and a half years, I was VP of Engineering at Tomo. I also loved being a VP. I built the engineering organization, and our technology platform, and the engineering culture all from the ground up. I was a great VP. Now, as CTO, I find myself in this new role, in this new position, with new challenges and opportunities ahead. As I prepare myself to grow into this new role and grow out of my previous role, I'm thinking about and reminded about all the transitions that I've made in my career from when I was just starting out as a software engineer, all the way up through all the steps until now. I think about where I need to grow, where I need to grow in terms of depth, and how the breadth of my understanding has grown. I need a deeper understanding and new parts of the business that I haven't been involved in before. The breadth of my responsibilities certainly has changed from my previous role. I know that one of the pitfalls that I need to avoid is holding on too close to those things that I loved and that I was really good at, at being a VP. Because holding close to that will only hold me back from growing into a great CTO. These are lessons that I've learned many times through my career. Why I'm here is to tell you a lot of stories about those lessons that I learned. I want to share those with you in hopes that it'll be helpful as well.

Why Are You Here?

I hope that's why you're here. I talked to a few of you to find out why you're here as well. You might be here because you're curious. What do people do all day if they have the title of engineer, or senior engineer, or tech lead, or platform lead? I'm going to talk about that. We're going to start there in talking about titles and a framework. I want to define some terms that I use when I talk about career growth with engineers, that translate a little bit better across companies. Because as I think we all know, titles can be really slippery when you're looking at your growth across different companies and looking to coach folks from other places. Overall, I'm hoping that you're here to gain a model for thinking about your growth, and your career, and thinking about the growth of other engineers that you're going to be mentoring. This talk is about some of the surprising inflection points that I've seen, and I've discovered as I've been going from one level to the next. I want to give you a heads-up about what to expect, and some advice along the way. I want to share with you overall how important it is to grow others, to grow leaders in order to grow yourself in your career. In my experience, these lessons are a lot easier to see in hindsight. I'm hoping it'll be helpful to you if I share these as my mentors have done for me over the years.

Model for Growth (Definitions)

We're going to start with some definitions. Companies have career ladders with titles like this, with engineer, senior engineer, principal engineer, staff engineer. Does principal come before staff or is that after? There are many ways you can define these levels. I'm sure we have all experienced difficulty in trying to match these up across companies. I can't fix that. I'm not going to fix that for you. A different way to look at your career ladder is by talking about the role you play on your team and how that changes as you level up and grow. Here's how I like to frame it. You start out as a trusted contributor. Your objective is to learn and become a trusted contributor on your team. You got to build your technical foundation for the languages that you're using, the platform that you're working on, the tools that you use as a developer. You need to learn about the coding standards and the process that your team uses. You need to learn about the domain that you're working in, and the product that you're working on. You get to a point where you can take a well-defined user story or a ticket that's really well-defined, or a bug report, and be trusted to fix it independently. That's what it means to be a trusted contributor on your team and to your code base.

You get to a point where you may not be able to always articulate why but you know what the right thing is to do at any given time. You might still need some help with complex issues, or when the architecture isn't really well suited for the problem that you're trying to solve. You can add a ton of value as a trusted contributor. Then, as a feature leader, you've reached a point where not only can you independently solve even complex or novel problems, but you can also take a feature or product request, and help to dig in on the requirements and break down the work into an implementation plan that you and your team can follow. You can lead feature development for your team for well scoped projects, for well scoped features. Feature leaders are at a point in their career where they can start to raise the bar, they're thinking about raising the bar for quality or test coverage, or tooling, or documentation, other important concerns about our craft. At this level, they're often involved in both asking and answering that question why, not just what we need to do, but why that's really important. Still keeping mostly within the scope of your team there.

Then there's team leader, or tech leader. As you grow, you take on the role of a tech lead or a team leader. At this level, you typically have a deep and broad understanding of your technical stack. You can lead system design across systems. You're likely still writing code, and you might even be leading your team projects, you're usually leading engineering projects for your team. Potentially, you're responsible for leading your team's process as well, like as a scrum leader. Even if you're not leading the process, engineers at this level typically have a big influence on how engineers collaborate on their team in terms of process and culture and tools and patterns and coding standards and things like that. Then when your company reaches a certain size, there is yet another individual contributor level that's often needed. I call this a platform leader. These are engineers who are, formally or informally, they have responsibility for leading broad architectural decisions of their platform, or they're leading large systems across teams. They might even be leading the broader technical direction for their entire company, if you're part of a smaller company. They might oversee large architectural changes, or lead the review and adoption of new patterns for the code base across teams. These are often engineers who are involved in research and development or driving early strategy conversations about the business, about what's possible, where can we go, where can we innovate? These can even be industry leaders who are speaking at conferences like this. There was one just done before me, as well, about the direction we should all be heading in this industry across companies.

What Do People Do All Day?

You see these terms and how I use them. Another way of looking at it and understanding what these mean, is by thinking about what would they do in a typical day? An engineer, of course, does a lot more than just writing code. You do peer code review. You're going to be testing things. You're going to be deploying things. You might be triaging some bugs. You've got some team process to participate in, like estimating, and planning, and doing retros, and demos, and things like that. As a feature leader, you're going to do all of that, but a trusted contributor does. Because you now have responsibility for at least some feature development, in a typical day, you might spend some time digging in with your product partner to understand those requirements and write up some tickets. You're going to maybe break some tickets down and get prepared to do a refinement for those. You're going to spend some time also because you're at that level in your career where you're thinking about how we work. You're going to spend some time thinking about the code base and how it could be improved. You're going to be thinking about documentation. They're probably also spending time mentoring the trusted contributors on their team. Tech leads and team leads often do all that and more. They're responsible for driving engineering projects. They're probably working even more closely with their product and business partners to define and drive projects for the team. They're expected to be deriving our best practices and developing our strategy as a team for the long-term health of that team, or that platform, or the feature, or whatever scope your team is responsible for. They're probably participating in not just mentoring, but also interviewing as well for trusted contributors and feature leaders and future teammates.

For platform leaders, the day-to-day is often very different from any of the other levels. Again, this varies widely company to company. They may not even focus or be involved in the output of a specific team or a specific project. Their whole role might be much more about moving the needle on larger engineering initiatives that might span multiple teams, they might span multiple systems. They might spend their day being consulted by different engineers and teams that need input and direction. The mentoring and coaching they do is probably a lot more focused on team leaders and tech leads. They're responsible for deeply understanding the business's long-term goals and defining the technical strategy that will get us there, which might include maybe spinning off new projects, or making broad technical changes, or also cultural changes or cross-team process evolution too. Part of the reason why engineering career ladders and titles are so confusing is that these roles overlap. They overlap and they look different on different companies, on different teams even within the same company, and for different people at different times.

Scope of Responsibility and Expertise

I assert, a perfect mapping does not exist. I don't think that my model is perfect. There certainly are exceptions where a bullet point will fall to the left or the right of what I have listed here. I do find this model helpful, which is of course why I'm sharing it with you. What I'm trying to illustrate is that as you grow, you increase the breadth and depth of your expertise and responsibility. First, you might grow depth and breadth across technology, but then that expands to include people, mentoring people, and practices, and then process and your business. Breadth and depth in all of these dimensions. When you start out, you're focused on your own learning. You start out as a trusted contributor, you're on one team. You're focused on your own learning and often in one layer of the tech stack because you're just getting started. Then as a feature leader, your responsibility broadens. You might work on multiple projects. You're usually still embedded on one team, but your understanding of the code base and your product broadens so that you're familiar with how things work in different areas. Your expertise deepens within your platform, and goes deeper into new areas of your application stack and your code base so that you can solve those larger, more complex problems. Then as a team lead or a tech lead, you broaden your responsibilities again, often to include the whole team, the whole tech stack, multiple simultaneous projects. Broadening goes out. You most certainly will deepen your skills, and your technical understanding in multiple areas, and your skills around influencing culture, and process, and planning for the team in order to make them successful. Then, as a platform leader, your scope broadens again, to include more teams, more initiatives, more responsibility for charting the path into the future for your team or your company. You need to deepen your understanding of your business and the market in which you operate, and the industry that you're working in, in order to guide the engineering strategy in the right direction.

As you grow from level to level, in your career, you tend to alternate like this between increasing the breadth and depth of your responsibilities and expertise. Sometimes to get to the next level, you really need to do both, grow in both breadth and depth, but it is hard to grow in two dimensions at the same time. I find it helpful when I'm coaching engineers to talk in these terms of breadth and depth and help them figure out where they could focus on stretching the most. Do they need to broaden their responsibilities, broaden their understanding, or do they need to focus next on building depth in specific areas? Sometimes I like to show this in terms of an engineering rubric. Here, as you move from level to level, so in this case, row to row, you can see how your skills deepen, the colors get darker, the numbers get higher as you go level to level. Also, your responsibilities and skills broaden as you fill in more columns. Sometimes it's helpful to illustrate it in this way.

Inflection Points: How Your Role Changes

In my experience, in addition to the breadth and depth, I've also seen inflection points when making these particular career steps from trusted contributor to feature leader to team leader to platform leader. The first one's a little bit obvious, maybe. It happens earlier in your career, when you go from being a follower to being a leader. You can no longer look to someone else to define the architecture, or choose the right algorithm, or figure out what's going on in production that's making all my data fall on the floor. The second inflection point happens when you start to take a leadership role on your team, even as an IC. This one I call player to coach. This is a moment when you realize you can't be on the field all the time. You need to focus your energy on setting your team and your teammates up for success. I'm going to talk more about what that looks like for me and how that works. There's one more inflection point, and you hit when you're a leading platform engineer. This takes you away from the day-to-day operation on teams, the day-to-day development that's happening. I call this inflection point, actor to director. This might at first seem a lot like players or coach, like a player is on the field and the actor is on the stage. There's a subtle and important difference in that the director, and think of this as like a director in a play, they do all of their work in planning and rehearsal. They're not standing on the sidelines making calls the way a coach does during a game. I'm going to share some more examples of what that has looked like for me.

What's It Like to Take Each Step?

What is it like? What was it like for me? What have I seen it be like for others? Over again, you start out as this awkward newbie. You work really hard, and you become awesome at what you do, only to have to give it up and start all over again, at the next level in your career with a new skill set, new responsibilities. At each new level, it's hard to let go of the things that you were good at before, but you have to, you must. What I hope to share with you in this talk is how through it all, the key to success is to focus on growing others to take your place, to be able to do what you can do, so that you can take on new challenges, new opportunities, new responsibilities, and further deepen your expertise. Before I get into storytelling about my many past mistakes and lessons learned, I wanted to pause and say, I'm talking a lot about growth. What I mean by that isn't just about getting a bigger salary or a bigger title. Those are great. You should get those as you grow. It's really about learning. It's about challenging yourself to be able to have a bigger impact and to learn more so that you can add more value to your business, to your industry, to your community.

Growing to Feature Leader

We're going to talk about growing from a trusted contributor to a feature leader. I think most of you are beyond this point in your career. I think it's helpful to start at the beginning, especially as you're mentoring others who are taking this step in their career as well. I want to challenge you to think about this if you're far beyond this, do you remember when you were reaching for that first senior engineer role? It was admittedly a long time ago for me. Here's a reminder of what those two levels looked like for me. I definitely learned some lessons here. I've seen those repeated in engineers that I've coached over the years. When I started out as a trusted contributor, I had an amazing team around me. They were all super senior engineers, and they would help digest the products requirements. They would break that down into a really great actionable plan. They would point out what's going to be the easy parts and what's going to be the hard part. They would carve out just the right tickets for me right, for the things that are appropriate for me at my level. Then for anything more complicated, I could pair up with them. I learned from them through this process. Even when they carved things out for me, it felt amazing. I hope you remember this too as a trusted contributor, to be so set up for success, whether through pairing with them and learning, or for them carving out tickets that were just right for me, and just appropriately challenging. It felt really good, and it was fun. At some point, you are needed to solve problems that are bigger, when anyone can carve out for you, and there isn't anyone who can break it down. At some point it is your turn to make the plan. This isn't easy to do, especially the first time. I remember struggling with this. I've seen a lot of other people struggle with this as well.

There are two primary ways I see people struggle when they're asked to put together an implementation plan and lead feature development the first time. They do one of two things, they freeze, or they hide. By freeze, I mean that people would freeze up or flounder when they're asked to figure it out. Figure out this feature, how should we build this? What do we really need? They freeze. It's like writer's block. It's usually just a sign that they need more practice building muscles. Building muscles for how to dig in on requirements. Building muscles for how to dig into the code and figure out how this feature is going to fit in, and coming up with a solution or an implementation plan, and sharing that. This is something that you can practice. For this I recommend pairing up, just pair up with a more senior engineer and get more reps, get more practice until it becomes easier. It is totally normal and ok to struggle. The other way I see people struggle when they're just starting out as a feature leader is they hide. This is when they really do understand the requirements and they do have an idea for how to solve it, but they're either uncomfortable putting their ideas out there for others to follow, or they just struggle to articulate their implementation ideas in a way that other engineers can follow, they can join in on. These are the ones that often will plow ahead if you let them. They will just keep implementing everything by themselves because it's a lot easier. They understand that I got a plan, I'm just going to go. Maybe this is where like cowboy coders come from. They just get stuck at this hiding point. What I do know is this is a trap. Trying to always go it alone means feature development can only move as fast as you, which may not be fast enough for your business or your team, long-term.

Learning to articulate technical ideas and define work that others can join in on is a muscle. You can learn it the same way we've all learned it. We weren't born knowing how to do this. Maybe you need to learn some effective ways of drawing technical diagrams, or documenting APIs, or just succinctly capturing technical ideas outside of code. It helps here as with the folks who are freezing to pair up and get more practice on this and feedback by working closely with other more senior engineers. Also, in this case, for folks that struggle in this way, I find it helpful to take up every opportunity you can to practice these skills even outside of feature development. Volunteer to write documentation. Volunteer to write runbooks, or onboarding guides. Volunteer for that. The important thing is you've got to learn to pass the ball. The ball in this case is the technical understanding needed to do the work. To grow as a feature leader, you have to increase the depth of your technical and product understanding, of course. You need to increase the breadth of your skills to include communicating technical ideas to your teammates, in a way that they can join in and follow along. It is really important to break through this growth point, because what happens is that as a feature leader, you become a force multiplier. You can create clarity. You can create direction for your teammates, the same way those senior engineers did for you when you were starting out as a trusted contributor. This is the stage where you make the transition from follower to leader.

Growing to Team Leader

Now you're a senior engineer, you're a feature leader, what comes next? That next level is again what I call tech lead or team lead. Here's how I think those are different. This is when you've reached the stage when your technical and product knowledge is so deep and so broad on your team that you are the one everyone looks to, to handle the gnarliest of problems. I remember one of the first times I found myself as a new tech lead, and I was on a team and I was surrounded by much more junior engineers. When we're kicking off a new project, we're adding a big new feature to our SDK or our app, just like as a feature leader, as a tech lead you work really closely with your manager and your product and business partners. You figure out what needs to get built. You start planning how it needs to get built. You come up with a technical design. You know how it will need to fit within the existing systems. You know what's going to be the easy part, and you know what's going to be the hard part. My initial approach, and this, again, is very common, was to keep all of the challenging, tricky work to myself, and then farm out only those much simpler things to the more junior engineers around me. Have you done this? We've all done this. It just feels practical in the moment. There's always a need to move as fast as possible. You're the fastest one for the job. You can't even always put down a plan and articulate exactly what needs to do. When things are more complicated for the more delicate parts of a new feature development, you don't have time to write down everything you know about the code base along with a very detailed implementation plan for someone to follow. You literally can't do that. Sometimes these things need to be figured out as the feature is getting built. You got to do some prototyping. You have to do some research, find the right algorithm, or framework, or pattern to solve the problem.

In many cases, this approach works fine. The feature gets built. The code is great. The code might even end up better because you personally were in there making improvements while you were building this tricky feature. You probably learned something by building this. You're going to learn something more about your code base, or your architecture, or this product, but you haven't grown. All of you tech leads and team leads, you can keep doing this forever. You can keep personally building every fancy, innovative, new feature that your product needs, but that is all you're going to be doing. There's a similar trap that I fell into many times as a lead engineer, when there are issues in production, an alarm is going off, data is not flowing, errors are being reported. My initial approach as the person who knows everything about everything, is to jump on it and fix it. Again, this works. Problem solved, very quickly. We can all go back to bed. The problem is that it left me being the person that was needed every time the system broke, every time any system broke that I had built. It's the same trap again. This is not the last time you'll see it either. This is a pattern I've seen again with the tech leads that I've coached over the years, by withholding the gnarliest, least well-defined, and frankly, most interesting work for yourself, you're depriving the people around you of an opportunity to grow. You may not see it at the time, but you are depriving yourself of an opportunity to grow, too. It's not uncommon for this bottleneck situation to only be resolved when that senior engineer finally burns out and unexpectedly leaves the company and the rest of the team is left to fill in the gaps. You know, you've all been there. I've been on both sides of that. It is not a good time.

What do you do? What does it look like to grow others in this situation instead? How do you grow from that? Let's go back to feature development. Let's say after working with my manager and my product partner, I understand what needs to get built. What I learn to do is to write up just enough: just enough guidelines, just enough context, just enough warnings about what to watch out for. I would carve those out and I would be able to give those individual features to another team member. I would still define and refine user stories, but I wouldn't assign all of them to myself. I wouldn't assign all the tricky ones to myself. I had to learn to step back and let the engineers around me take a stab at figuring out those trickier parts. I'd still tell people what they needed to do sometimes, but I also made a point in those cases to explain why. Why was I suggesting that approach, so that they could think for themselves and make decisions if needed during implementation without having to come back and ask me every time if it's ok. Of course, I would still pair program and code review. I would jump in if really needed, I was still there on the team, but I would give them space to try. They might fail but they're definitely going to learn from that.

The same is true with production incidents, and on-call issues. I had to learn how to document enough information so that anyone could see, for the most common alerts and errors, they could see what is happening and know where to begin troubleshooting and resolving it. Then I'd set up an on-call rotation, and let people be on the hook to responding for these alarms. I'd still be there if needed, but I would let them try. You know what happened? Features still got built. Incidents still got resolved. Yes, sometimes it took longer, maybe, but sometimes the result was even better than I could have planned. For feature development, one time, there was a more junior engineer, and he knew a lot more about a new framework than I did, that I hadn't considered. He came up with a great, clean, scalable solution for our projects, because I'd given him that piece and he figured it out. For incident triage, one time another engineer used their on-call time to automate a bunch of steps that I had previously been running more manually with scripts. My team was happy. In my experience, this is the kind of team that people love being a part of. This is a place where they're supported, and challenged, and given room to grow as leaders and take ownership of new problems and new systems.

What happened is that more people knew how to do what I knew how to do, which meant that, as a team, we can do more in parallel, and more perspectives resulted in us coming up with better solutions. Even better than that, not always being on-call and heads down building everything, freed up more of my time to look at our overall architecture. I could look at our technical operations. I could look into our tech debt. I could plan and implement improvements that would make our apps more stable, and our team more productive. I had more time to make documentation and to do knowledge sharing so that my potential leaving one day wouldn't be such a pain for everyone, and we can onboard new developers more easily. Not only did my team learn to operate like a well-oiled machine, but because I was doing more planning and documenting and handoffs, I deepened my skills for communicating technical ideas at a higher level. I had time to take those ideas and plans, and influence other teams across the company. Even outside the company at conferences like this, which broadened my influence. I had time and headspace to join meetings with senior leaders about new strategic initiatives, or get involved earlier and more often on the planning that was done even further out into the future. This was a big part of my growth as a tech lead into more of a platform leader, which is what I want to talk about next.

What I learned from all of this is to grow other engineers to become leaders as well, to be able to plan and implement features independently. To triage production issues. To be able to think and act without me. With your bottleneck removed, your team can do more in parallel. More software and better software is going to be built because you are able to make this step. Growing other engineers, and most importantly, letting go of being the only go-to expert for everything, gave me time to learn about and influence more projects and more systems and work on larger technical problems, which broadened my responsibility and deepened my expertise. In this role, you have the experience and the context to see the big picture for your team, and to shape the future of your code. That is what you should be doing. Figuring out implementation details and writing the code and reacting to errors in production is something all engineers can eventually do, let at least some of that go. Remember, above all, it's not just about delegating work that's beneath you. That's not what this is about. You have to give your teammates opportunities to plan and implement, maybe fail, but definitely learn while supporting them and providing your overall technical direction.

Growing to Platform Leader

We're going to talk about growing beyond a team lead into a platform leader. Again, not all companies are large enough to have a role like this, like a platform leader. Some companies have architects that are in a role like this. This may look different for you, but this role is when you are near or at one of the highest technical leaders in your company, and you're needed to drive innovation and technical change across multiple teams, across potentially your entire organization. Sometimes, again, you do this by being embedded on a team. Sometimes you are floating in between and being consulted by many projects and many teams. When I first had a role where I was a leader across teams, I still worked a lot like a team lead, because that's what I knew. It's what I was really good at. I paid a lot of attention to process. I paid a lot of attention to technical plans and requirements and code review. I still wrote a lot of code. I wanted to make sure everyone knew what needed to get built, what the plan was for deploying our features to production across teams. I owned a lot of that process across teams. I ran a lot of the meetings. I was creating documentation. I was reporting on our progress. I was doing deployments and testathons, and prod maintenance. I was celebrating when we finished things. None of these are bad things to do. The problem is that by taking all of the responsibilities for coordinating development across the platform onto myself, it meant that every time there was a question about a cross-team requirement, or a big implementation decision, or something going wrong in production that didn't obviously go to one of the teams, everyone looked at me. I was keeping too many challenges and responsibilities to myself, and depriving the people on the various teams an opportunity to grow.

I think you all know what that is. That's a trap. That's a bottleneck. Instead of being a bottleneck just for feature implementation, and maybe incidents on one team like before, now it was a bottleneck for broad technical decisions and cross-team process. Even as I grew into my role, I was overwhelmed by the number of meetings I had to attend, and being consulted and running a lot of the process. It made it really hard to take a day off, let alone thinking about anything except the day-to-day operation of the platform. It meant that when I had to write a new project proposal or research a new idea, or just do bigger thinking, I struggled to find the time or the energy. I was burning myself out. What does it look like to grow beyond this? The trick was to grow the whole org to be able to make technical decisions, to run our cross-team release process without me if needed. I had to grow tech leaders and team leaders. I had to trust them to run things and even coordinate amongst themselves.

One of the best pieces of advice I got when I was in this point in my career was to focus on doing what only I can do. Focus on doing what only you can do. For every meeting, for every task that needs to get done, for every challenge that needs to get addressed, ask yourself, is this something that only you can do? If not, you should be helping somebody learn how to do that. I had to coach more of our engineers to think like tech leads, to talk about not just what but why. I needed to invest more in documenting and getting others to document our architecture, and our policies, and our best practices. I needed to do more training and knowledge sharing, generally. I had to automate processes where possible to make the right thing to do the easy thing to do. Like automated builds and releases, and made checklists for technical interviews and onboarding and releases. I still had to make sure that I set boundaries and provided enough context to the teams for the initiatives that I was pushing across the organization. I also had to trust the teams and reinforce this culture where it's safe, and ok to act and maybe fail, because we will learn from it every time and improve. I'm not usually so big on sports metaphors, but this is really helpful. This is where you have to learn to identify as the coach, not the star player. You have to take yourself off the field, and coach your teammates and the engineers in your organization to win. What happened was that I was able to avoid burning out. I was able to start looking further into the future and think about how our platform needed to evolve, and what opportunities we had ahead to bring innovation into our product.

There are a bunch of pitfalls at this level of platform leader. I'm going to dive into another one. I think there are three more left. The next pitfall comes, when as part of this leadership that you're doing across the platform, involves some of the longer term and forward thinking, and things like big organizational changes. You might be planning a big reorg. You might be part of that planning. You might be part of planning a big technical platform change, which is going to impact the kind of code that people are writing on a day-to-day basis. A difficult step for me in this transition to this role, when this planning came up, was to be able to pause on thinking about people as individuals, and to be able to start thinking about what are the right resources, what are the right organizations to solve this problem, to meet our goal. In my early days in this role, I was in a thankfully small meeting with senior leaders about a big future staffing change. It was actually a staffing change and a technical platform change. I could not stop thinking about and mentioning out loud how each individual would like or not like the changes that we were proposing. It was after that meeting that one of my mentors pulled me aside, and he taught me about this concept of people-ing versus process-izing. It's not that you stop caring about people. I never stop caring about people. I can't. You have to be able to take a step back and look at the bigger picture, and to strategize, and think, and problem-solve on an organizational level. You need to be able to think at the level of your whole platform, of your whole organization. If you can't do that, you're not going to be able to effectively lead at this level. This one was hard to see until someone pointed out to me that I wasn't doing that. That's an important lesson to learn.

You not only need to think at the level of your organization, but you also need to get comfortable acting at that level too. Another big surprise for me was how hard it would be not to just jump in with a team or a tech lead when they're challenged with a specific technical issue or a process issue. I would just want to jump in with the code with them and try to fix it. That's a trap, too. At a certain level, you can't personally fix every team and project problem. You should be looking for patterns of struggle across the platform and proactively identifying ways to prevent them. You are there to inspire, to align, to support, to coach the engineers and team leaders and tech leaders, they're actually doing and leading the work. Make it easy for them to do the right thing in their role. It's like they're the actors in the play, and you become more like the director. When you're a team lead working within a large organization, you're handed a roadmap, and to a certain extent, the rules of the road. It's your job to rally your team to get them to do what's needed, to execute on their plan. That's like an actor who's given a script and staging instructions. It's up to the actors to really excellently perform the parts. There's a lot of creativity in that. That's what the role is like. As a platform leader, you're like the director. It's a much more challenging role, because in some ways, not only are you off the stage, but you also have to come up with the plan in the first place. What are those rules of the road? What are those staging instructions?

There are infinite directions you could go into as an engineering organization. There are times when everyone's going to look to you to decide. Also, leading at this level is a lot more about influence than even I originally expected. You're going to work with engineers and team leads and managers that don't report to you. You will also need to partner with leaders across many different departments: design, product, marketing, IT, operations. It's not possible to achieve your goals at this level without being able to build alliances and influence others. You got to get other platform leaders, other executives, other VPs on board with your ideas. It's like, if you're the director of the play, but the lights and music and costumes people, they're not accountable to you, and they have different agendas, which makes it really hard. Again, the advice I gave myself as a platform leader, and that I would give to you, is to focus on growing great tech leads, and team leads, and let them focus on the day-to-day execution, so that I can bring all of my energy, and creativity, and experience to planning out and influencing the technical, organizational, cultural, and operational changes that we need to really nail our goals.

Summary

You've heard a lot of my stories. You have a model for thinking about your career, for thinking about the careers of those that you're mentoring, as they go from trusted contributor to feature leader to team leader to platform leader. Now you know there are things you're going to have to let go of, and that is really hard. You'll go from follower to leader, from player to coach, and then from actor to director. At each transition, letting go of what you're good at, and growing others to be good at that instead, is what gives you the time to grow into your new role. As you grow in your career, you can think about expanding the breadth and depth of your responsibility and expertise. If you aren't sure which direction to grow in, you can think about, how can I add depth to my expertise? Or, how can I broaden my responsibilities? Growth can be so painful, but it can also be tremendously rewarding. As an engineer, even as a trusted contributor, I love fixing a gnarly bug or writing beautifully expressive code, or shipping an important feature all by myself. I was even more deeply satisfied when I finally realized I could be a great team leader. I could create exactly the kind of team culture and healthy engineering practices that led to a sustainable and robust and flexible architecture just like I always dreamed of.

As a top engineering leader, as a platform leader, I was deeply satisfied to create a culture and an architecture and establish cross-team processes and a roadmap in which dozens of engineers and leaders were able to grow and do satisfying work, and add tremendous value to our business. If like me, you like to build technology that delivers tremendous value and you love to build culture that makes people's jobs and lives more satisfying, you can do that more as you grow others and grow yourself. That's what you get. As you grow, you influence more of the technology and people and shape the world around you. Focus on doing what only you can do in your position. Everything else, coach, delegate, support your teammates to take care of too. Don't deprive them of an opportunity to grow.

See more presentations with transcripts