This post was published to my weekly Q&A mailing list. Ask your hard questions. Get my honest answers.

As a team lead/manager/senior person on a software team, what are effective ways I can help/nurture/grow the team to become more effective?

As a leader, how you spend your time is critical. You have an incredible opportunity for impact because your decisions directly affect the output of your entire team. That makes investments in the team’s effectiveness particularly valuable and high-leverage.

The good news is that you can get really far by spreading the same best practices that make people effective engineers. Beyond that, you also have many tools available to help your team grow.

Here is a starting point.

Gather input as to what’s hard or frustrating.

As an experienced person on the team, you’ve probably built up a wealth of knowledge about how to be effective, but that knowledge may have also left you numb toward the pain points that may exist for others. You might have a powerful debugging or development workflow — but it relies on cobbling together an undocumented set of tools that must be used in a particular way. Or you might be able to quickly navigate around the codebase or internal tools — but others lack the same mental map of where things are. Or you might know which key stakeholders need to be consulted when for a project — but it’s non-obvious to everyone else on the team. Your team would be much more effective if you could bridge those gaps.

To learn what gaps exist, you first need to gather data. You can learn what’s working and what’s not informally through one-on-one meetings. Or, if you want a more systematic approach, you could also run an engineering survey like we recently did at Quip. We had all 26 engineers on our team fill out a ~30-minute, anonymous survey. Generally, things are going really well! But we also learned about certain tools and parts of the codebase that people dreaded and some things that were hard that people thought should be easy. These learnings have then fueled subsequent discussions and initiatives on how we can make things better.

Explicitly design how to align someone’s growth goals with what creates value.

Have an explicit conversation with the people on your team about where they want to grow and how you might become an ally in supporting that growth. Sometimes, tech leads shy away from conversations around career growth, believing that their core responsibility lies in project execution and that career growth is best left for managers.

That limiting belief leads to a missed opportunity. When someone’s career goals and dreams align with what they do, that person ends up being more energetic and enthusiastic and produces higher-quality work. Why wouldn’t we want to find creative ways to both support their goals and create value for the business?

Maybe someone wants to improve their public speaking skills – what opportunities for talks might you be able to create to increase knowledge-sharing and also further their communication skills? Or maybe someone wants to be challenged with more technical responsibilities – what might you delegate that could free up your time to focus on higher-leverage activities? Or maybe someone wants to develop a better understanding of the business – how might you facilitate those conversations and use any new insights to better shape your product roadmap?

If we’re open to it, there are often creative ways to find alignment between what people want and what the business or the team wants. To unlock that value, start with an explicit conversation about what you each want.

Give and request frequent and honest feedback.

Do people on your team know how they’re doing? Sometimes we hold back on giving feedback because we assume it’s obvious or because it makes us or the recipient uncomfortable. What if the feedback isn’t obvious, and what if they would have actually appreciated knowing what they’re doing well and where they need to improve?

When feedback comes from a good intention (e.g. you want that person to succeed) and when you explicitly share that intention (e.g., “I want to support you in succeeding in your role”), the intention frames the feedback, and the feedback is significantly more likely to be appreciated and valued.

Schedule a one-on-one with people on your team and exchange feedback. Ask each other:

• What’s one thing you would like to see the person do more of? less of?
• What do you see as possible for that person?
• What assumptions do you have about each other?

Leverage your strengths to level up the team.

What are the strengths that make you an effective engineer or engineering leader? How might you use those strengths to give the engineers on your team a competitive advantage in their work?

For example, if you have a strong systems background, how might you ensure that the systems being built are engineered to meet their goals? If you have strong product intuition, what feedback might you be able to provide on ongoing projects to increase the likelihood of success? If you consider yourself a productivity guru, what tools might already exist or might you guide the team to build to increase everyone’s effectiveness?

Personally, I’ve developed a passion and skill set around leadership coaching and development. I ask myself how I might raise the bar for technical leadership, and I focus a lot of my energy on coaching engineers to achieve what they want, on teaching leadership skills, on facilitating group discussions, and more generally on identifying the growth opportunity in a given task, project, or situation.

Reduce sources of complexity.

Complexity is the enemy of execution. It brings many hidden costs that engineers ignore and becomes a growing tax on our mental energy and on our time. Actively fight it.

In a conversation the other day, some folks on my team at Quip observed that the number of commits we’ve made in the past few years hasn’t grown at the same pace as our team. Our engineering team has more than doubled since I joined, but we’re nowhere close to doubling the rate of commits. Of course, commits aren’t a great measure of productivity — we’re closing bigger deals, working on more ambitious projects, and building better tooling so that we need fewer code changes to get things done.

That said, one big culprit that slows down the commit rate is complexity — there is more code for new engineers to ramp up on, more systems to maintain and scale, more surface area and context in the product for new projects to integrate with, and more people to coordinate with to make things happen. Therefore, anything that we can do to reduce code complexity, system complexity, product complexity, and organizational complexity will pay off huge dividends as the team continues to scale.

Create more opportunities for collaboration.

Because we want to get so much done, there’s a tendency to divvy up tasks and then have people work on them individually because it’s more efficient. The downside is that one-person projects can make work less motivating.

Introducing more ways for people to collaborate as part of their normal workflow can be a powerful way to increase motivation and enthusiasm.

For example, at Quip, we started a Pair Programming Roulette program where every two weeks, we randomly pair up engineers who are interested so they can pair program for an hour. The program creates a fun opportunity for people to work together, and it has also increased the dissemination of best practices within the team. More importantly, it’s had the side effect of normalizing pair programming as a collaboration tool — mentors use it to onboard new team members, team leads use it to spread knowledge, and engineers use it to make boring tasks more fun.

There’s certainly a lot that can be done to make our teams more effective, and these ideas are just a starting point. Experiment and see what works well, and double down on strategies that you find have the most impact for your team.