Building Great Software Engineering Teams: Recruiting, Hiring, and Managing Your Team from Startup to Success

by Josh Tyler

You’re trying to build a team of people you can trust to do great work, which is why recruiting and hiring are so critically important. To achieve scale and speed in your organization, you simply must hire people you can trust, and then give them as much autonomy as possible. These people don’t work for you; you work for them.

The typical workday of a manager is different from an engineer’s in a few important ways. First, it’s full of interruptions and context shifts. Whenever someone has a problem, you’re there to help, no matter what you were already doing. Second, a manager usually talks to more people, more frequently, than an engineer. The job is largely about communication. Finally, a manager is a pressure release valve for issues building inside a team. By coming to you first, people can head off more destructive outcomes that interrupt the workflow of the larger team.

Being effective with career development requires many skills. Chief among them are: Being a thoughtful listener; possessing and being able to discuss relevant experience; and attentiveness to peoples’ goals and potential opportunities.

Being a manager means constantly trying to match people with the correct opportunities and projects. You’ll never make perfect choices, but in order to make the best ones possible, you must remain attentive and mindful of your people at all times.

If you’re only able to talk about career growth, but never able to follow through on it, you’ll eventually lose your team’s faith. Career development isn’t just a discussion of an abstract set of goals—it’s the realization of those goals through real-world projects and responsibilities.

As a manager, it’s your responsibility to handle problem situations. You shouldn’t be looking for confrontations, but neither should you run from them. Your team is counting on you to know when and how to correct incorrect behavior.

An effective manager must be able to delegate responsibilities and tasks to others. In some ways, your effectiveness as a manager is the sum (or product) of the actions of your team, so the more you can delegate, the more leverage you get.

The seeds of your garden are the people you hire. The soil is the team structure, process, and culture you instill. You must regularly water your garden with one-on-ones, discussions of how to improve things, and events that build team relationships. Every day you should be looking for signs of disease, over- or under-watering, or any of the myriad other dangers that can befall your team. And the harvest, when you ship your product, is a time for celebration that your diligence and hard work have paid off.

Your priorities have shifted, and your primary responsibility is now to get the best results out of your team—not to be buddies.

As a leader, you now represent the company to the people on your team. Your actions reflect the culture, mission, and goals of the company, and your people will see you more as a company representative than as an individual. This loss of identity can be difficult to accept.

In some ways, becoming a manager means losing a lot of friends. No longer can you commiserate with your team about decisions with which you disagree or make jokes at the company’s expense. You always have to be “on” in front of your team, showing your best and most prof...

genuinely enjoy enabling the accomplishments of others, are willing to speak up in difficult or controversial situations, and have a tireless attention to details and organization. If you’re not naturally this type of person, people management may not be the ideal role for you.

At that point, I knew I had to choose—be an engineer or be a manager. You can’t be both at the same time.

Your team is confident that: You have their best interests at heart. You give them the timely information and tools they need to succeed. You help them grow as people and professionals. You protect them and advocate for them, insulating them from the distractions of corporate politics. Your manager is confident that: You get good results from your team. Your team acts and behaves consistently with company goals and practices. Your team is happy and satisfied with their situation. You provide adequate career development for the people on your team.

Here some important ways to foster honesty and openness: Don’t judge ideas when you first hear them. Listen and encourage sharing. Be honest yourself and open up about important topics. Remember details from previous discussions, to show that you take them seriously. The same is true for team meetings, especially those with senior or more trusted staff. Your internal leaders should be your early warning system—they have the experience to detect issues before others and the willingness to inform you about them.

As a manager, you’re the chief problem-solver for your team. If you’re not accomplishing that, and your colleagues don’t believe you can do it, you have a serious problem. When there’s a major bug, service outage, or customer complaint, are you the first person to be notified? If someone on your team is facing a crisis, do they come to you first for help?

People should see you as an indispensable ally for solving tough problems.

One of your reports goes directly to your manager for assistance. Your own manager (possibly an executive) prefers to contact people on your team directly. People in other parts of the company go directly to your team with questions or requests, skipping you.

A common mistake, made by companies everywhere, is to reward top engineers by promoting them into management positions. Though this may seem like an appropriate reward for your most productive people, it often backfires, for a variety of reasons: Great engineers love writing code. Changing their job in a way that takes them away from writing code may ultimately decrease their happiness with their work. Once you’ve turned an engineer into a manager, it may be difficult to move them back to an individual engineering role without it feeling like a failure. This transition can be made successfully, but often is not. Management is hard. Unless someone is truly committed to training themselves on the skills required and building up years of experience, they probably won’t be highly effective. The risk, therefore, is that you take a productive, happy engineer and unwittingly turn them into a mediocre, frustrated manager who feels locked into a dead-end position. This characterization may sound extreme, but all too often it ends in people leaving a company to find a fresh start.

When speaking to members of my team, I sometimes summarize technical leadership as “making other engineers better.”

This role of leading a small group of (typically three to five) engineers boils down to two primary responsibilities: Set a great example for the other engineers to emulate. Make the other engineers better, happier, and more productive.

More specifically, we look for lead engineers to provide mentorship and guidance on all technical matters, to help define engineering best practices, and to ensure that these best practices are being followed in the team. Lead engineers should be thinking a few steps ahead about the technical challenges facing the team, preparing other engineers for upcoming projects or new initiatives.

Countless books have been written on management itself, so I’ll just provide a quick list of the top responsibilities of an engineering manager: Recruiting and hiring great engineers Providing career advice and guidance for engineers Finding ways to deliver high productivity from a team Building a culture that encourages excellent work and high job satisfaction Detecting and resolving performance and interpersonal problems As a manager’s team grows larger, these responsibilities gradually replace technical contributions.

Please let me know if you start to suspect this role isn’t right for you. There’s no harm in moving back to your previous responsibilities, and it’s far preferable to do that than to remain unhappy and frustrated in the leadership position.

Through these years, I’ve created and refined a simple model for evaluating engineer performance. It has four levels: A mediocre engineer does what is asked. A good engineer does what is asked, and does it well. A great engineer does what is asked, looks for possible problems, edge cases, and overlooked issues, and solves those as well. An outstanding engineer does all of the above, but also tells you about problems you didn’t even know existed, and plans for situations you never envisioned.

In truth, promotions are usually given to people who are already fulfilling the duties of that larger role, and haven’t yet been recognized formally for doing so. The promotion is more of a reflection of reality.

Therefore, the best way to be successful as a manager, in the long term, is for people to love working for you. You will get amazing results. These results might not be exactly what the people above you asked for, but that’s where your skill is required—show that it’s better and that they can trust you and your team more than they thought.

Getting people to love working for you, while still making senior decision-makers happy, is a nontrivial skill that requires a lot of study and practice. (You’ll make mistakes.) Here are some ways to earn the loyalty and trust of your team.

You should also apply the same advice and encouragement you share with your team to yourself. Do you encourage people to read technical or business books as a way of developing new skills? Share your own learning from books as you read them. Are you looking for engineers to contribute to open source projects or attend technical conferences? Find a way to participate yourself. Lead by example, demonstrating your own desire to grow, and your team will follow suit.

If you see people suffering, do something about it.

Don’t pretend to have more knowledge or experience than you do, in an effort to maintain authority. Be honest about what you know and what you don’t know, and ask for help from your team whenever needed. They’ll respect your self-awareness and desire to learn.

Write down everything you do. Every day, week, or month, add to a running list of your accomplishments at work. Include as much as you can think of, no matter how big or small.

As much as you might like to think that your manager, peers, and colleagues appreciate and remember all of your wonderful contributions, the fact is that they don’t. They have their own busy lives to worry about, their own projects, and their own interests to consider. It’s not intentional or antagonistic—they simply don’t remember everything. That’s why you need to give them a little help.

Apply things discussed earlier in the interview to subsequent questions or problems. This is a great way to demonstrate that you’ve learned something.

Communicate and have an active dialogue as you work through things. Good communication is an indication that people will be able to have productive work sessions with you.

Talk about projects where you’ve tried to learn things, beyond strictly what was asked. Show that you’re self-motivated to learn, imp...

By nature, being teachable means that you are receptive to testing and trying new approaches.

You didn’t tell us why you want the job. This job. If you haven’t spent any time learning about us and what we need, why should we do the same for you? Every candidate that gets to the interview stage requires us to do hours of preparation, interviews, and discussion. If your introduction is generic, I’m led to believe that you’ve contacted dozens of other companies as well. If we’re going to invest our time in getting to know you, we’d like to know you’re serious about us.

Do: Tell us why you want this job, specifically Demonstrate that you’re interested in our company and products Explain how you would be able to do the job, to the best of your ability Describe examples of past work that would apply

Any interview response that includes we is not useful. We’re not interviewing your whole team. We’re interviewing you. Tell us what you did. Be egotistical! Be self-obsessed! (But don’t lie.) If you’re able to talk only about what we did, it unfortunately sounds like you didn’t do anything. For example: Bad: “Our team refactored the order-processing system to improve performance.” Good: “I reimplemented an existing Python library for order processing in C++ and added multithreading to improve performance.”

I have a suggestion: deep-link to a few highlights inside your GitHub repo — files or changesets that show off some of your best code or design work. Take the reader right to the good stuff.