I’ve also seen tech leads flounder. One particularly memorable struggle was a person who was an amazing engineer, wrote great code, but hated talking to people and often got distracted by technical details. I watched him go down rabbit hole after rabbit hole, and in the meantime, the product manager took advantage of his absence to railroad the rest of the team into committing to feature delivery that was both poorly designed and way too aggressive. The project was a mess, and what did the tech lead do? He went chasing after the next refactoring, because he was sure that the problems were entirely in the way the code was structured. You probably recognize that story, because it happens everywhere. The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best code, is a common misconception that even experienced managers fall for. Tech lead is not the job for the person who wants the freedom to focus deeply on the details of her own code. A tech lead who does this is not doing her job. But what is the job of tech lead, really? What do we expect from this person?
As with many titles in software engineering, “tech lead” lacks a common definition. The best I can do is draw from my own experience and the experience of others. My job as tech lead was to continue to write code, but with the added responsibilities of representing the group to management, vetting our plans for feature delivery, and dealing with a lot of the details of the project management process. I could be the tech lead, despite not being the most senior person, because I was willing and able to take on the responsibilities of the role, while the rest of my team were more interested in staying purely focused on the software they were writing. When my team at Rent the Runway created our engineering career ladder, we consciously chose to define the role of tech lead as a set of characteristics an engineer could take on at many points on the ladder, rather than a specific level. We took this tack because we wanted to recognize that, as teams change and evolve, the tech lead role may be held by many different stages of engineer, and may be passed from one engineer to another without either person necessarily changing his functional job level. The tech lead may not have exactly the same role from company to company, or even from team to team within a company, but we know from the title that it is expected to be both a technical position and a leadership role, and that it is often a temporary set of responsibilities rather than a permanent title. So, with all that said: what is a tech lead? Here is the description we created at Rent the Runway:
The tech lead role is not a point on the ladder, but a set of responsibilities that any engineer may take on once they reach the senior level. This role may or may not include people management, but if it does, the tech lead is expected to manage these team members to the high management standards of RTR tech. These standards include:
- Regular (weekly) 1-1 touchbases
- Regular feedback on career growth, progression towards goals, areas for improvement, and praise as warranted
- Working with reports to identify areas for learning and helping them grow in these areas via project work, external learning, or additional mentoring
If a tech lead is not managing directly, they are still expected to provide mentorship and guidance to the other members of the team.
The tech lead is learning how to be a strong technical project manager, and as such, they are scaling themselves by delegating work effectively without micromanaging. They focus on the whole team’s productivity and strive to increase the impact of the team’s work product. They are empowered to make independent decisions for the team and are learning how to handle difficult management and leadership situations. They are also learning how to partner effectively with product, analytics, and other areas of the business.
It is not required that an engineer work as a tech lead to progress, but it is the most common way for engineers to grow from senior engineer 1 -> 2 and is required to grow from senior engineer 2 to engineering lead. Realistically it is very hard to grow past senior engineer 2 without ever having acted as a tech lead, even on the individual contributor track, due to the importance at senior levels of leadership and responsibility.
Perhaps a better shorthand for this is the description used by Patrick Kua in his book, Talking with Tech Leads:
A leader, responsible for a (software) development team, who spends at least 30 percent of their time writing code with the team.
Tech leads are in the position to act as strong technical project leaders, and to use their expertise at a larger scale so that their whole team gets better. They can make independent decisions, and they play a big role in coordinating with other nonengineering partners that their team might have. You’ll note that there’s nothing here about specifically technical work. This is a senior engineering role, but it’s a mistake to tie the notion of tech lead to one that boils down to the best or most experienced engineer on the team. You can’t lead without engaging other people, and people skills are what we’re asking the new tech lead to stretch, much more than pure technical expertise. However, tech leads will be working on one major new technical skill: project management. The work of breaking down a project has a lot of similarity to the work of designing systems, and learning this skill is valuable even for engineers who don’t want to manage people.
If you’ve found yourself in the tech lead position, congratulations! Someone thinks you have what it takes to be the point person for a team. Now it’s time to learn some new skills!
BEING A TECH LEAD
Being a tech lead is an exercise in influencing without authority. As the tech lead I am leading a team, but we all report to the same engineering manager. So not only do I have to influence my peers, but I also have to influence up to my manager to ensure we are prioritizing the right work. In a recent role this was particularly challenging because one of the first projects I tackled after becoming the tech lead was to stop all feature development and focus on technical debt. It was clear to me that the “technical debt can” had been kicked down the road for far too long; deploying new code was difficult, operating the existing services was expensive, and the on-call rotation was hellish. I believed that we needed to go slow in order to go fast in the future. However, this was not an easy sell to the other developers, who wanted to write fun new features, or to my manager, who had a constant stream of requests from our customers. I sold the idea by focusing on the different impact this would have on individual team members. For some team members it was about having a more reliable service, for others it was about iteration speed, and for others it was about reducing the on-call burden so that they could sleep through the night. When talking with my manager I emphasized the reduced operational overhead, which meant we could accomplish more feature work as a team in the future.
Becoming a tech lead required me to change my focus. Work is now less about me and working on the most technically challenging idea or the most fun project; instead, my focus is more on my team. How do I empower them? How do I remove the obstacles slowing them down? Working on a rewrite, or some new exciting feature that helped me express the full extent of my technical prowess, might have been more fun, but what the team needed at the time was to tackle technical debt and to focus on operations. In the end the initiative was incredibly successful. The team reduced the number of critical paging alerts by 50%, and in the following quarter we almost doubled the number of deploys we were able to do.
You’re a tech lead, which means you know something about software, and your manager thinks you’re mature enough to be given greater responsibility for projects. Having the technical chops and maturity is nothing, however, if you can’t figure out the biggest trick of being a good tech lead: the willingness to step away from the code and figure out how to balance your technical commitments with the work the whole team needs. You have to stop relying entirely on your old skills and start to learn some new skills. You’re going to learn the art of balance.
From now on, wherever you go in your career, balancing is likely to be one of your core challenges. If you want to have autonomy over your work, if you want the freedom to make choices about what you work on when, you must gain mastery over your time and how you use it. What’s worse, you’ll often need to balance doing things you know how to do and enjoy doing, such as writing code, with things you don’t know how to do. It’s natural for humans to prefer activities they’ve mastered, so when you have to spend less time on your current talents in favor of learning new things, it’ll feel quite uncomfortable.
It can be hard to balance the work of project management and oversight with hands-on technical delivery. Some days you’re on a maker’s schedule, and some days you’re on a manager’s schedule. Through trial and error, you’ll need to learn how to manage your time to provide yourself with appropriately sized blocks to work in. The worst scheduling mistake is allowing yourself to get pulled randomly into meetings. It is very difficult to get into the groove of writing code if you’re interrupted every hour by a meeting.
Even with careful scheduling, you won’t often have the time to focus for several-day stretches on coding problems. Hopefully, you’ve learned some tricks before now to help you break down your own work so that you don’t need to spend multiple days of focused effort to finish technical tasks. You also know that it’s important to get your team into a schedule that allows them to be focused on development for long stretches of time, because they will need to focus for several days on coding problems. Part of your leadership is helping the other stakeholders, such as your boss and the product manager, respect the team’s focus and set up meeting calendars that are not overwhelming for individual contributors.
Let’s say you’re partnering with a product manager and a team of four other engineers on a big multiweek effort to launch a new initiative. The tech lead has a number of responsibilities in this scenario, depending on where you are in the project lifecycle. Sure, you’ll need to write some code and make some technical decisions. But that’s only one of the roles you’ll play, and it’s likely not even the most important one.
Your highest priority as a tech lead is taking a wide view of the work so that you keep the project moving. How do you go from organizing and planning the code you need to write on your own to organizing and leading the overall project?
In the systems architect and business analyst roles, you identify the critical systems that need to change and the critical features that need to be built in order to deliver upcoming projects. The goal here is to provide some structure for basing estimates and ordering work. You need not perfectly identify every single element of a project, but there’s a lot of value in spending time thinking through the externalities and issues related to a project. This role requires you to have a good sense of the overall architecture of your systems and a solid understanding of how to design complex software. It probably also requires you to be able to understand business requirements and translate them into software.
Project planners break work down into rough deliverables. With this hat on, you’re learning to find efficient ways of breaking down the work so that the team can work quickly. Part of the challenge here is getting as much productive work done in parallel as possible. This can be tough because you are probably used to thinking about only your own work, instead of the work of groups of people. Finding places to apply agreed-upon abstractions to enable parallel work is key. For example, if you have a frontend that consumes JSON objects from an API, there should be no need for the API to be completely finished for the frontend development to begin. Instead, agree upon the JSON format and start to code to that format using dummy objects. If you are lucky, you’ve seen this happen before and are simply pattern-matching your previous work. At this stage, you will want to gather input from the experts on your team, and talk to the people who know the affected parts of the software deeply, so that they can help with the details here. You will also want to start identifying priorities as part of this process. Which pieces are critical, and which are optional? How can you work on the critical items early in the project?
Software developers and team leaders write code, communicate challenges, and delegate. As projects move forward, unexpected obstacles arise. Sometimes tech leads are tempted to go to heroics and push through these obstacles themselves, working excessive overtime to get it all done. In your position as tech lead, you should continue writing code, but not too much. Even if you are tempted to pull a rabbit out of the hat yourself, you must communicate this obstacle first. Your product manager should know as early as possible about any possible challenges. Enlist the help of your engineering manager as needed. In a healthy organization, there is no shame or harm in raising issues early. Teams often fail because they overworked themselves on a feature that their product manager would have been willing to compromise on. As a large project nears its delivery date, there will be compromises on functionality. Start looking for opportunities to delegate work, especially if there is part of the system you expected to build yourself that you have not had the time to tackle.
As you can see from these descriptions, in the process of being a tech lead, you have to act as a software developer, a systems architect, a business analyst, and a team leader who knows when to do something single-handedly, and when to delegate the work to others. Fortunately you don’t have to do all of these tasks at once. It may be uncomfortable at first, but you’ll find a balance with time and practice.
ASK THE CTO: I HATE BEING A TECH LEAD!
I thought becoming a tech lead would be awesome, but now my manager expects me to chase down all these details about project status, and tell her when things are going to be done, and I really hate it. Why did no one tell me that the tech lead position was so terrible?
All this new responsibility is hard, I know. I like to call this particular problem the “Stone of Triumph.” (Simpsons fans will get my joke.) The Stone of Triumph is a metaphor for achieving recognition only to discover that recognition comes with a heavy price. While this is true at many stages of an engineering leadership career, the tech lead stage is surely one of the heaviest stones. Very rarely is the tech lead given an increase in salary or a title bump, and first-time tech leads often have no idea how hard the new responsibilities can be. As I mentioned in the definition of the position, many companies consider this to be more of a temporary title, a set of responsibilities you may take and shed several times in your career. It can be a stepping-stone necessary for promotion to more senior levels, but it is not usually a milestone that comes with immediate, tangible rewards.
Why is the tech lead role such a heavy burden? The tech lead has a much wider scope of responsibility than the senior engineer in an individual contributor position. The tech lead is called on to help architect a project, and then to go through the steps of actually planning out the work. The tech lead is expected to make sure the team fully understands the project requirements, the work is planned, and the team is effective and performing well, all without necessarily having any management responsibilities and usually without any specific training. And, realistically, most managers will expect their tech leads to continue to write almost as much code as they did before they took on the lead role. It’s generally a pure increase in responsibility and scope of work. If you’re a first-time tech lead, you have your hands very full.
So, congratulations, they’ve given you the Stone of Triumph! Fortunately, carrying around that burden will eventually make you stronger and give you skills you need to move forward in your career. It won’t always be as heavy as it seems right now.
I remember my very first experience with complex project management quite vividly. I was a first-time tech lead and my team was undertaking a very complex task. We had an existing system that we had scaled to its breaking point. After throwing just about every hack in the book at it, we decided it was time to figure out how to run it across several machines. This was back in the very early days of distributed systems, when most software developers really didn’t know all that much about the best practices of creating them. But we had a great team of smart people, and we felt confident that we could figure this out.
We did figure it out, slowly but surely. We spent a long time thinking about design and the different ways of breaking up our computations so they made sense when computed across multiple machines. And then, one day, my boss Mike pulled me into his office and told me I needed to make a project plan.
It was one of the worst experiences ever.
I had to take this incredibly complicated set of tasks and try to figure out which ones depended on other ones. I had to think of all kinds of dependencies. How would we make it work in the complex testing framework we depended on? How would we deploy it? When did we need to order hardware to test it? How long would integration testing take? The questions just kept coming. I would go into Mike’s office, sit across from him at this big wooden desk, and we would go over task descriptions, dates, and breakdowns. He would help me do some of it, and then send me off with the parts that needed more work.
This was not something I enjoyed doing. It is burned into my memory as a series of frustrating and tedious steps where I had to overcome uncertainty and the fear of making mistakes, the fear of missing pieces, in order to create a plan that would pass Mike’s judgment. Then we had another round of tedious work to put it into a format that we could present to the leadership team, so that they would accept it. It almost killed me. And it was one of the most important learning experiences of my career.
Doesn’t agile software development get rid of the need for project management? No. Agile software development is a great way to think about work because it forces you to focus on breaking tasks down into smaller chunks, planning those smaller chunks out, and delivering value incrementally instead of all at once. None of this means that you don’t need to understand how to do project management. You’ll have projects that for whatever reason can’t be completed in a single sprint, or even two small sprints. You’ll need to estimate project length for your management team, and give some detail on why you believe things will take that long. There are some projects, usually described by words like infrastructure, platform, or system, that require architecture or significant advanced planning. When faced with this kind of project, which includes many unknowns and relatively hard deadlines, you will find it doesn’t fit so well into the standard agile process.
As you move forward in your career, you need to understand how to break down work that has complexity beyond the scope of what you can do as an individual. Project management for a long-running, team-based project is not what most people consider fun. I find it tedious and sometimes kind of scary. I want to be building and getting value, not trying to think about how to break down a project that still has very fuzzy implementation details. I’m afraid that I will be held accountable and that I could miss something important in the process that will make the project fail. But the alternative is the project failing slower, not faster.
Project management isn’t something that needs to happen in detail for every single effort, and it’s overused in some organizations. I don’t even like hiring project managers because they often act as a crutch for engineers to use instead of learning to think through their future work and ask real questions about what they’re doing and why, and their presence means that you have more waterfall-style projects instead of an agile process. Still, project management has to happen, and as tech lead, you should be doing it when it is needed, especially for deeply technical projects.
Ultimately, the value of planning isn’t that you execute the plan perfectly, that you catch every detail beforehand, or that you predict the future; it’s that you enforce the self-discipline to think about the project in some depth before diving in and seeing what happens. A degree of forethought, in places where you can reasonably make predictions and plans, is the goal. The plan itself, however accurate it turns out, is less important than spending time on the act of planning.
Back to my first project management experience. Did the project run perfectly according to plan? Of course not. There were bumps, bugs, unexpected delays, and things that we missed. However, amazingly, we still delivered the project fairly close to on time, and there was no string of sleepless nights required to get there. We managed to make the changes needed to move this complex system into a distributed deployable artifact, all while working against the master code branch with 40 other developers making concurrent changes of their own. All of this was possible because we had a great team, and we had a plan. We had thought through what success looked like, and we had identified some of the risks that might cause failure.
Since that frustrating series of meetings with Mike, I’ve had my own series of project planning meetings where I was the one sitting in Mike’s place, and across from me was Carlo, or Alicia, or Tim. They each felt the frustration of the plan lacking detail, and they each went away and did the uncomfortable work of thinking about things that aren’t code, that couldn’t be perfectly predicted. And they’ve each led complex projects to successful outcomes thanks to this work, and are better equipped to build bigger systems and lead larger teams now that they understand what breaking down a project really means.
TAKE THE TIME TO EXPLAIN
One of the last steps in a doctoral program is the defense. This is where you, the doctoral candidate, after years of research, are presenting the results of your work in front of a panel of experts in your field who will judge if the merits of your results are worthy of a PhD. Years ago, I was fortunate to receive a PhD in mathematics from one of the most prestigious Applied Mathematics programs in the United States. One of the judges on my panel was a renowned mathematician in the field of numerical analysis. Something he said to me after my (successful) defense has stuck with me throughout my working career (not in mathematics!). He said, “Your thesis was one of the most lucid and clear theses I’ve read in many years. Thank you!” I was certainly gratified but also very surprised by his words. I had assumed that he, being a world-class mathematician, would “know all about it,” and just “watch” how my thesis would turn out. In fact, as he explained, he was able to do that, but only because I had taken the trouble to explain the basic ideas of the problem space and the motivations behind my ideas. I have never forgotten this lesson. Since then, after many years working in software and in large organizations, I have come to appreciate those comments even more.
We think our management “gets” what we do as technologists. Just “read the code, man!” The software we live and breathe every day ought to seem obvious to anyone working in technology, right? But it is not. Technology managers hire the best people (hopefully), who solve very difficult problems. But they don’t “get” it all. I’ve always been surprised how grateful senior technical managers have been when I can explain some very basic modern ideas (e.g., what’s this NoSQL stuff all about, and why should I care?) to them in a nonthreatening and noncondescending way.
Recently, a senior business manager at work asked me privately about why it was important for us to migrate our traditional deployed fat-client architecture to a hosted platform. He was under a lot of internal pressure to fund this effort, but he hadn’t a clue why this was necessary. He was also probably too embarrassed to ask publicly. I spent two very fruitful hours explaining (without PowerPoint!). I never hesitate nowadays to take the opportunity to explain basics and motivation to senior or junior members. It educates them without making them feel small, they learn to trust my judgment and advice, and we bring about change. Taking the time to explain is very important.
Project management is the act of breaking a complex end goal down into smaller pieces, putting those pieces in roughly the most effective order they should be done, identifying which pieces can be done in parallel and which must be done in sequence, and attempting to tease out the unknowns of the project that may cause it to slow down or fail completely. You are addressing uncertainty, trying to find the unknowns, and recognizing that you are going to make mistakes in the process and miss some unknowns despite your best efforts. Here are some guidelines:
- Break down the work. Get out a spreadsheet, or a Gantt chart, or whatever works for you, and start breaking down your big deliverable (say, rewriting your billing system) into tasks. Start with the biggest pieces, then break the big pieces down into smaller pieces, then break those down into even smaller pieces. You don’t actually have to do it all yourself. If there are parts of the system you don’t understand well, ask for help from the person who does. Get the big stuff broken down some, and then turn your attention to the ordering of the work. What can start immediately? Hand those tasks off to the people who can actually turn them into ticket-sized work.
- Push through the details and the unknowns. The trick of project management is not to stop when you feel a little bit stuck, or tired of it. It is tiring and tedious, as I said earlier. And it’s not something you probably know how to do well. So keep pushing through it past those points of irritation, boredom, and pain. A good manager will sit with you and tell you where it isn’t good enough, ask questions to prompt you, or even work through some of it with you. We don’t enjoy it either, but it is part of the teaching exercise. Work through the unknowns until you really feel that there is no more value to be gained in spending time on them.
- Run the project and adjust the plan as you go. The value of a good planning process is that it helps you know approximately how far the project has come, and approximately how far it is from completion. As things slip (and they always do), keep everyone apprised of the status. But now, instead of guessing how far you have to go, you can clearly point to the milestones that have been hit and outline the expected remaining work.
- Use the insights gained in the planning process to manage requirements changes. You learned a lot by breaking down the project given the original set of requirements. If requirements start to change midflight, take those insights and apply them to the changes. If the changes add significant risk to the project, necessitate a bunch of new planning, or simply require a lot of additional work, be clear about the cost of those changes. If you’re working toward a hard deadline, knowing roughly the effort required will help you prioritize, cut, and simplify work to get the best compromise of features, quality, and delivery date.
- Revisit the details as you get close to completion. Toward the end of the project, the tedium returns. It is time to really attend to the finishing details. What is missing? What testing? What verification? Run a premortem, an exercise where you go through all the things that could fail on the launch of this big project. Decide where the line for “good enough” is, socialize it, and commit to it. Cut the work that falls below the “good enough” line, and focus the team on the most important final details. Make a launch plan; make a rollback plan. And at the end of it, don’t forget to celebrate!
ASK THE CTO: I’M NOT SURE I WANT TO BE A TECH LEAD
My manager keeps pushing me to consider being a tech lead. She wants me to run a big project. I know if I took the role I would have much less time to write code because I’d have to be in a lot of meetings and dealing with a bunch of coordination. I don’t think I want this, but how do I decide?
I have a strong opinion on pushing people into management roles, which is that you shouldn’t do it. If you’re not ready to take on management-type responsibilities, don’t take them on. There’s nothing wrong with staying deep in the technology, especially if you feel like you still have a lot to learn before you become an expert.
Good managers are looking out for talented people who could be given bigger leadership roles, but sometimes this leads them to push people away from coding before they’re ready. This practice can have a very negative impact on your career, because at more senior levels people who are considered “not technical enough” can find it hard to be promoted into management positions with more responsibility. It’s much easier to stay in a focused individual contributor role and learn what you need to learn there than it is to try to learn all of those skills while also learning management skills.
At some point, to progress in your career, you’ll probably need to do the tech lead job, even if you’re interested in staying on the individual contributor (nonmanagement) career path. That doesn’t mean you need to do it now. If you feel like there’s plenty of purely technical learning for you to do on your team, and you’d rather work individually on this project with someone else running it, don’t take the tech lead role. If, on the other hand, you don’t think the individual work would challenge you technically, perhaps it’s time to push yourself into learning some new skills—and the skills of the tech lead are good ones to try out.
The decision of whether to be a manager or stay on the technical track is a tough one. It’s incredibly context-specific, and I can’t possibly tell you what to do. However, as someone who has dreamed and lived both of these tracks, I can tell you how I imagined the roles versus what I ended up experiencing and observing. So, with the caveats that these are simply caricatures and not set in stone, let me tell you how imagination and reality diverged for me.
Your days are spent in a mix of deep thinking, solving hard problems that challenge you intellectually but are still fun and novel, and collaborating with other deep thinkers. It’s software, so you know there will be some yak shaving, but you get to do some of the most interesting work, and you have a lot of power to choose what you work on. You love writing code, fixing code, making code go faster, and making computers do new things, and you get to spend most of your time doing that.
Because of your seniority, the managers ask you for your advice on how to approach development before it begins, so you know everything that’s going on but you don’t really need to deal with the details of the people building it. You’re invited to just the right set of meetings where the important decisions are made, but not so many as to disrupt your flow. The more junior developers look up to you and hang on your every word, taking your feedback but not imposing too much on your deep thinking time.
Your upward trajectory is never slowed, and there are always new big problems that you can solve to show off your value to the organization. You work hard, but are rarely called upon to stay late or work weekends, because as we all know it is impossible to do quality, thoughtful work for too many hours a week. When you do work late, it is because you are just so caught up in the flow that you can’t wait to finish the feature at hand or fix the bug you just found.
You get to write books, give talks, and create open source work—and with some luck and persistence, you earn a bit of industry-wide fame. No one cares that you’re a bit awkward or shy or expects you to evolve your communication style much, because what you say is so important. Everyone in your organization knows who you are, understands how valuable your work is, and is deferential to your opinions.
In short, you have the perfect balance of engaging work, fame, and accumulated expertise that makes you invaluable and respected, highly paid, and influential.
When you find the right project, and the right lifecycle of the right project, your life is great. You are challenged, and you get to learn new things. You have a lot of control over your day-to-day, and certainly fewer meetings than your management counterparts, but your days are not always spent in a blissful flow state. For every project there’s the period where you have the idea and you’re selling it to people, trying to convince them that it is the right approach. Or you’ve implemented the system, but now you need to get other teams to start using it, so you sit with them for days showing them the ins and outs, explaining why it is useful, and trying to convince them to lobby their manager for time to adopt it.
Your upward trajectory is not as fast and easy as you had hoped it would be. In fact, it is pretty slow. Those big projects that prove you to be an invaluable architect are hard to find. The team doesn’t need a new programming language, a new database, or a new web framework. Your manager isn’t great at handing you plum assignments that showcase your talents to the whole organization; she expects you to tell her where these opportunities live. Discovering good projects seems to be a matter of luck. Pick the wrong project, and you spend months or even years on something that might get cancelled despite all of your best efforts. You are a little jealous of your friends in management who seem to be getting promoted faster while they keep growing their teams.
The other developers are a mixed bag. You’re a nice person, so some of them admire you and listen to your opinions, but others seem to be jealous of your influence. New developers either want too much of your time or seem to be scared of you for whatever reason. There’s definitely some competitiveness with your peers around who gets to lead big, interesting projects.
Your manager is kind of a pain. She isn’t terribly supportive of your desire to open source a system because you think it provides a new twist on logging that the industry needs, and she suggests that if you want to give talks or write books perhaps you need to spend some of your personal time on those efforts. She seeks out your feedback on technical matters, but sometimes forgets to tell you about new initiatives until it’s too late for you to put in your two cents. You suspect that you are missing out on crucial information because you aren’t in the right meetings, but every time she invites you to sit in those meetings you remember how boring and inefficient they are, and how much valuable focus time you’re losing. And she doesn’t have much patience for your desire to be free of tedious work like answering email, interviewing, or responding to code reviews promptly.
Still, you get to build things most of the time. You get to spend your time focused on technical problems, systems design, and engineering issues, and you don’t have to do all that much dealing with people or sitting in boring meetings. You can often choose your projects and can easily move between teams if you want something new. And you just found out that you get paid more than your manager! So, life isn’t all bad.
You have a team, you have control, you can make the decisions, and you can finally get others to do things your way. Your team respects you and is happy to yield to your authority in all matters. You think they should write more tests? You tell them, “Write more tests,” and they do it! You want to make sure that everyone is treated fairly despite their gender, race, and so on? You make sure that it happens, and fire anyone who crosses the line and creates an environment that is unhealthy for the rest of the team.
Because you care about people, they know that you’re always trying to do your best for them even when they disagree with you. They give you the benefit of the doubt, and come to your 1-1s with open feedback for you when you’re screwing up, and eager to receive feedback from you. Dealing with people is stressful, sure, but they know you care about them, so it’s also highly rewarding. You see the impact of your coaching happen quickly now that you are in this position of authority.
When you see another manager doing something that seems wrong, you are free to go give him advice in the same way you would talk to another engineer who needed help on a system design. Other managers are always interested in hearing what you think, and they can see how effectively you’ve gotten your team working, how clearly you care about the health of the organization, and how genuine your interest is in just making everyone better.
Your manager gives you plenty of coaching but rarely steps in to tell you what to do. The minute that you feel ready to take on a bigger team, your manager is open to giving you more people and expanding your organization. She hands you goals that are clear and rarely changes things. Even though you have a lot of responsibilities, you still have some time to write blog posts and give talks, and this is encouraged because it will help your team hire and improve your standing in the tech industry.
In short, you get to make decisions, you create the culture, and your effectiveness is evident to all around you, making your path to promotion quick and your career exciting and lucrative.
You have a team. You have some control, but you’ve quickly discovered that getting people to do something is harder than just telling them to do it. You seem to have given up all control over your own day-to-day. Mostly you spend all day in meetings. You knew this was coming, but it’s not until you live it that you really understand what it means. When you only had a small team you were able to balance things and still write code, but as your team has grown you’ve lost touch with the code. It gnaws at you as something you should be doing, but there’s no time. Every time you snatch a few hours to write code, you realize that it would be irresponsible to check it in and make the team support it, so at best you snatch a script here, debug an issue there. Having the focus to build something big yourself is a distant memory.
You can make decisions—well, some decisions. Realistically, you can maybe narrow down the things that will get decided. You can focus your team on some things, like writing better tests, but they still have a product roadmap to implement, and they have their own ideas for what technical tasks should be prioritized. So, more than making decisions yourself, you’re helping the team make decisions. Your manager gives you goals but then sometimes changes those goals completely, and it’s up to you to explain the changes to the team.
You do set the standards for culture on your team, which is good and bad. It’s good when they take after your best aspects, and it’s bad when you realize that your team is also mirroring your faults.
Your team does not naturally just agree with you, respect you, or even like you. You realize that authority requires more than a title. You find yourself scrambling to motivate them through tough periods when the projects aren’t going well, or when you have to tell individuals that they aren’t ready to be promoted just yet, that they aren’t getting a raise, that there’s no bonus this year. Some of them don’t bother to tell you when they’re unhappy; they just get fed up and quit before you’ve noticed there’s anything wrong. When the company is doing well, and you have lots of money to pay, and there are plenty of exciting projects, life is great; but when things are stressful, you see how little power you have to make people happy. And what’s worse, you can’t even fire people without going through a crazy HR process! Still, you can see that your work matters to some of them, that they are happier and more successful because of your coaching. These little wins sustain you through the tough times.
Other managers are not interested in your feedback. In fact, they find you meddling and get competitive when they think you’re encroaching on their turf. Your own manager does not agree that you’re ready for a bigger team, and can’t really explain why; his coaching skills leave a lot to be desired. Maybe he is just worried that you will outshine him? He definitely does not want you spending all of your time giving talks, though—he gets annoyed when you are out of the office too much, whatever the value the team might get from it. The politics of figuring out how to lead without undermining your peers or your boss are trickier than you expected. But if you can get that bigger team, you know you will get that promotion, so at least your path is clear. When you discovered that the staff engineer who works for you makes more than you do, you almost lost it, so you’d better figure out how to get that bigger team fast. Otherwise, what is the point of all of this stress and nonsense?
My final advice is to remember that you can switch tracks if you want. It is common for people to try out management at some point, realize they don’t enjoy it, and go back to the technical track. Nothing about this choice has to be permanent, but go in with your eyes wide open. Each role has benefits and drawbacks, and it’s up to you to feel out what you enjoy the most.
The process czar believes that there is one true process that, if implemented correctly and followed as designed, will solve all of the team’s biggest problems. Process czars may be obsessed with agile, Kanban, scrum, lean, or even waterfall methods. They may have a very precise idea of how on-call should work, how code reviews must be done, or how the release process has to operate. They tend to be very organized and comfortable with details, and they’re good at knowing the rules and following them precisely.
Process czars are often found in QA, helpdesk, or product management groups. They’re also common in consulting agencies and other places where measurement of specific work progress is highly rewarded. They may be operationally focused, although in my experience, there are relatively few of these folks inside of your classic systems operations teams. They can be incredibly valuable members of a project management team because they tend to make sure that no task is forgotten and that everything is wrapped up in the way it should be.
Process czars struggle when they fail to realize that most people are not as good at following processes as they are. They tend to blame all problems on a failure to follow the best process, instead of acknowledging the need for flexibility and the inevitability of unexpected changes. They often get focused on easy-to-measure things, such as hours in the office, and miss the nuances that they fail to capture when focusing on the things that are easy to measure.
Engineers who believe in the “right tool for the job” sometimes turn into process czars when they become tech leads, seeking out the right tool to solve all issues with planning, focus, time management, and prioritization. They try to stop all work while they search for the perfect process, or constantly push new tools and processes on the team as solutions to the messier problems of human interactions.
The opposite of the process czar is not a manager who gives up on process completely, but rather someone who understands that processes must meet the needs of the team and the work. Ironically, while “agile” is often implemented in a rigid way, the principles of the Agile Manifesto are a great summary of healthy process leadership:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
As a new tech lead, be careful of relying on process to solve problems that are a result of communication or leadership gaps on your team. Sometimes a change in process is helpful, but it’s rarely a silver bullet, and no two great teams ever look exactly alike in process, tools, or work style. My other piece of advice is to look for self-regulating processes. If you find yourself playing the role of taskmaster—criticizing people who break the rules or don’t follow the process—see if the process itself can be changed to be easier to follow. It’s a waste of your time to play rules cop, and automation can often make the rules more obvious.
As the manager of a process czar, help that person get more comfortable with ambiguity. As with many of the manager pitfalls, an obsession with process can be related to a fear of failure and a desire to control things to prevent the unexpected. If you are honest and make it clear that it’s safe to fail and to be imperfect, that’s often enough to get your process czar to relax a little bit and let some ambiguity in. It is very important to keep process czars from spending all of their time seeking out the perfect tool or process, and especially important to make sure that they aren’t punishing their teams for failing to follow processes.
Great tech leads have a number of characteristics, but these are the most important.
If you go into a tech lead role and you don’t feel that you fully understand the architecture you are supporting, take the time to understand it. Learn it. Get a sense for it. Visualize it. Understand its connections, where the data lives, how it flows between systems. Understand how it reflects the products it is supporting, where the core logic for those products lives. It’s almost impossible to lead projects well when you don’t understand the architecture you’re changing.
If you’re doing all of the interesting work yourself, stop. Look at the tricky, boring, or annoying areas of technical need and see if you can unstick those areas. Working on the less exciting parts of the code base can teach you a lot about where the process is broken. With boring or frustrating projects, there’s often something obvious that can be spotted and fixed if an experienced person takes the time to look at them. If you’re only doing the most boring work, stop that, too. You’re a senior engineer who has a lot of talent as a developer, and it’s reasonable for you to take on some of the harder tasks. You want to encourage others on your team to learn the entire system, and you want to give them chances to stretch themselves, but you needn’t always be self-sacrificing in what you choose to work on. Give yourself a fun task occasionally, as long as you know you have the time to do it well.
You’ll be involved in most major technical decisions for your team. Involved, however, is not the same thing as being the person who makes all of them alone. If you start to make all of the technical decisions without soliciting the input of your team, they’ll resent you and blame you when things go wrong. On the other hand, if you make no technical decisions and leave everything up to the team, decisions that could have been made quickly can drag on without resolution.
Determine which decisions must be made by you, which decisions should be delegated to others with more expertise, and which decisions require the whole team to resolve. In all of these cases, make it clear what the matter under discussion is, and communicate the outcome.
Your productivity is now less important than the productivity of the whole team. Often, this means that you pay the price of communication overhead. Instead of having every team member sit in a meeting, you represent the team, communicate their needs, and bring information from that meeting back to the team. If one universal talent separates successful leaders from the pack, it’s communication skills. Successful leaders write well, they read carefully, and they can get up in front of a group and speak. They pay attention in meetings and are constantly testing the limits of their knowledge and the knowledge of the team. Now is a great time to practice your writing and speaking skills. Write design documents and get feedback on them from better writers. Write blog posts for your tech blog or your personal blog. Speak in team meetings, speak at meetups, and get practice standing up in front of an audience.
Don’t forget to listen during all of this communication. Give others a chance to speak, and hear what they say. Practice repeating things back to people to ensure you understand them. Learn how to hear what someone says and rephrase it in your own words. If you aren’t a good note taker, you may need to become one. It doesn’t matter whether you choose to dive deep into technology, or become a manager—if you can’t communicate and listen to what other people are saying, your career growth from this point on will suffer.
- Does your organization have tech leads? Is there a written job description for this role? If so, what does it say? If not, how would you define the role in your organization? How would a tech lead define the role?
- If you are considering becoming a tech lead, are you ready to push yourself? Are you comfortable spending some of your time outside of the code? Do you feel like enough of an expert in your code base to successfully lead others as they work in it?
- Have you asked your manager what he or she expects from the tech lead?
- Who is the best tech lead you ever worked with? What are some things that person did that made him or her great?
- Have you worked with a frustrating tech lead? What did he or she do that frustrated you?