All Great Tech Leads Know This One Weird Trick

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.

Being a Tech Lead 101

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.

Managing Projects

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.

Managing a Project

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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!

Decision Point: Stay on the Technical Track or Become a Manager

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.

Good Manager, Bad Manager: The Process Czar

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.

How to Be a Great Tech Lead

Great tech leads have a number of characteristics, but these are the most important.

Assessing Your Own Experience

• 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?