12 Valuable Lessons I Have Learned Leading an Engineering Team
In the past years working at our startup as a Platform Team leader, I’ve learned a tremendous amount. Obviously, not all of these things can be distilled down to a list of a dozen items, but I thought it would be valuable to share just some of the insights I’ve gained doing this work. I hope you find them useful.
You work for your engineers, they should feel that you are their advocate. As a Team Lead or Manager, you find that you are no longer spending as much time as you used to in front of code or wading deep into troubled technological waters devising technical solutions. Instead, you attend meetings, make plans, create spreadsheets, and work with other Team Leads to come up with business solutions that bring the most value to the company. This puts you into a situation where you know more about the tactical and strategic decisions that your company is making than your team does. We all know what it feels like when decisions are made “above your pay grade” and you feel powerless to affect the course of the projects that your company has taken. That’s why it’s so important that your team trusts you to go into these planning sessions knowing that you will look out for their interests. That means a couple of different things.
You advocate for the completion of existing projects. As an engineer, there is nothing worse than getting something almost done and then dragged off to chase after the next shiny object that Management or Product is interested in pursuing. This leads to technical debt, unmaintainable systems, and a deeply personal sense that you as an engineer have not been allowed to fulfill the tasks you were given. Actually getting something to work in an elegant and complete form is what engineers live for, and if you fight for this as their leader, you will earn their trust.
You protect your team from mentally “shifting gears”. You are 2 hours into untangling a thorny problem, you have a dozen different mental solutions marked out, the pieces are finally starting to assemble, and suddenly, you have to drop all of it to start over with some new issue. This is extremely mentally taxing and can lead to hours, if not days of lost effort. As a manager, it is important to make sure that the members of your team are allowed the mental space to keep working without interruptions. This means that you have to plan adequately and delegate clearly who is responsible for dealing with problems. Something like a rotating “Firefighter” who handles emergencies can go a long way toward allowing your team to get work done in peace. Most importantly, as a manager, you can budget your projects such that your team will have the breathing room they need to think and work effectively.
You know the limits of your team’s capacity. Sometimes issues come up that just don’t have clear boundaries. It may not be clear who should be the proper owner of a problem like this. However, the words “this isn’t my problem” should not pass the lips of any manager who expects to keep his or her position for long, so how do you protect your team from getting overloaded with problems that are outside their core competencies and without expecting pizza-dinner overtime? As their leader, you should know how much work your team can reasonably do, what their skill-sets are, and how to back it all up with data. If you need to take on an edge-case problem like this (and you will), you need to be able to communicate the costs to your fellow Team Leads and your management. You’ll need to show what this work will cost in terms of training, planning, and lost opportunity to complete other prioritized tasks. “That product release we expected in Q1? It’s pushed to Q2 if we take this. We need to budget x amount in time and money to adequately prepare. Here are the effort estimates to back this up.” Your team is composed of professionals, and they will understand that changes in priority are part of the job, but they will trust you more if they know that you are presenting a realistic picture of their capacity to the company, and working to secure adequate resources for them.
Have a Plan. The best weapon you have to keep your team sane and happy is to have a very clear understanding of how much work your team can get done in a sprint. This means that you have to know how much work things will require, and how much work you can get done.
On my team, we spend precious time each week grooming our backlog, and assigning sprint poker points to tasks. I really think this works. If you’re not familiar, grooming the backlog and assigning points means that you go through all the tasks that have been assigned to your team and giving a point value to each task. A task done easily is 1 or 2 points, a more complex task maybe 5 or 8. These don’t correspond to hours or days but are more of a “gut-check” estimate of how much work something will be. When your tasks are pointed, you can prioritize which tasks are to be completed in the coming sprints. Once your team has had some practice pointing tasks, you’ll be surprised by how accurate your guesses will get with time. If your task is larger than 8 points, it’s better to break it down into smaller tasks. What is the result of all this guestimation? Your team’s capacity. If your team gets, say, 40 points of work done sprint after sprint, this is actionable data that will allow you as a team lead to show exactly how much work you can accept and under what time-frame. The point is to really get this right. Getting the balance of work-in and work-out will be one of your principal tasks as a Team Lead or manager and can make or break the effectiveness of your team.
People come up with better solutions in groups. When I worked in Tech Support, 75 percent of the time I didn’t actually provide a solution to the engineer at the other end of the phone line, all I did was to ask questions and give the caller someone to explain the problem to, and, in the telling, the caller figured the problem out on their own. People naturally solve problems better when they talk things over and “get out of their own heads”. Many (not all!) engineers are introverts and like to work alone. However, there are lots of ways you can encourage your team to work on problems together. You can have senior members serve as mentors and work on problems with new hires, you can “swarm” groups of people to work on a particularly thorny issue together, you can schedule whiteboard sessions to architect new designs, you can have pairs work on code and the resulting code review and merge. The goal is to get people talking and working together on a problem, which in my experience almost always results in more robust, secure, and complete solutions. The added benefits of team cohesion, morale, and comradery are also incredibly valuable.
Don’t give solutions, describe problems. General Patton once said “Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” This is absolutely true of engineers. Even though you came up through the ranks as an engineer yourself, and you doubtlessly have ideas as to how things should be done, your will need to allow your team to come up with those things on their own. I’ve been consistently amazed and delighted by the ideas members of the team have come up with, and I’ve learned to be a better engineer myself in the process.
You delegate success and own failure. It’s important to shine a light on your team’s accomplishments and to do so by name. Send out an email every sprint or two and highlight the contributions that individuals have made. Explain in non-technical terms how this work adds value and benefits. Engineers don’t get lots of recognition, so it’s important to make sure that people understand the value of their work.
On the other hand, if there was a problem, a bug, an outage, a delay, or just a mistake, that’s on you to explain, document, and mitigate for next time. Errors like this rarely happen in a vacuum, instead, they arise as the result of a series of events and circumstances in a chain that lead to failure. As a leader, you will be the one tasked with owning the problem, identifying the links in the chain that lead to the failure, and mitigating those issues so you don’t have the same problem again.
Suggest, then listen. The best way to get a long, awkward pause is to say to a group of engineers “what should we do?”. In my experience, this question is too open-ended and leaves people wondering what you expect them to say next, or who should speak first, or a bunch of other introvert-y over-analysis. It’s better to just start by tossing something out. Suppose you are having an intermittent network issue and you are all stumped about what is causing it. Instead of asking what to do, open the conversation with something like, “Maybe we could write a cron job that tests the bandwidth every five minutes”. Now, this may not be the best idea, but the goal is to get people talking. “Well, we already have Grafana dashboards, lets just make one that records network activity”, replies one engineer. “I like the cron job idea, let’s do that, we can make it more customized.” says another. The result here is not that people need to follow your suggestion, it’s that you are providing a concrete issue to discuss rather than open-ended abstractions which are harder for many engineers to speak about.
Get people talking. In some cases, simply asking “Do you have any questions or concerns?” is not enough to actually get the kind of feedback that you need. One technique I have used in one-on-one meetings is to say to my team members “Please ask me three questions about anything”. Another way to phrase this is to say “What are your concerns?”. Sometimes people simply don’t feel qualified to voice their opinions, or maybe they just don’t like meetings and want to move on, but in any case, it’s important to convey that giving feedback is necessary and important, and these little tricks can keep the conversation moving
Think of all the things that can go wrong. Engineers want to say yes. If you ask an engineer “is this possible?”, there is a good chance that the engineer hears “do you have the mad skillz to do this hack?” and the answer will likely be yes, because who wants to say no and admit that you lack the previously mentioned “skillz”? It’s your job as a manager to protect your team and your business from this well-meaning hubris. As much as it is your job to come up with successful plans and architecture, it is also your task to think of all the reasons that something will not succeed. We are not always used to this kind of skeptical or pessimistic thinking, but anticipating blockers and preparing for the worst is a crucial component of leading a successful project.
Positive feedback is positive, let’s do more of that. I recently read a case study of the coach of an American football team who turned his failing team around by playing game films to his players, but not of errors or failed plays, but instead, he showed films of each player doing something really clutch, something really amazing. The result was that players focused on doing more of what they are good at, and the team as a whole dramatically improved. People are so used to hearing negative feedback, they are numb to it. On the other hand, people are not used to being told how good they are, and the impact on reinforcing their behavior by highlighting their successes is dramatic. Everyone has a different version of excellence and helping people find this excellence is a valuable skill. Singling out each contributor and pointing out his or her successes in a visible fashion really does result in greater motivation, a happier team, and better results. Positive feedback is probably the most powerful and undervalued tool a manager has.
