People Before Product

"Andres! I need some career advice: I'm trying to lead a team, but I have no idea what I'm doing!"

This is a cry for help I received recently from a good friend of mine. He went on to say:

"I've been taking more of a technical leadership role, trying to coordinate the work other people are doing, make sure we meet our deadlines, etc. It's been tough; I only know how to do things people tell me to do. My boss has been supportive, but when I go to him and ask what he recommends I do, he tells me to think about it myself - on the one hand, it's great that he's giving me more freedom and responsibility, on the other hand, ahhhh I don't know what to do with myself."

It's a common pattern, the skills that made us successful developers don't translate well to being an effective leader. We need to learn a new set of tools to motivate, coordinate, and build a strong team.

This conversation led me to think more about what I've learned throughout my career, leading teams as technical lead and people manager. It boils down to one thing:

People before product. Always.

The concept is simple: People build products, great teams are made of engaged people, engaged people build the best products.

A straightforward concept, the challenge lies in the implementation. Throughout this article, I'll explain how to motivate, structure, and empower a team.

Teams Need a Purpose

Why does our team exist? Teams that can honestly answer that question have an edge, and as leaders, it's our responsibility to give our team purpose.

Lewis Carroll famously wrote that if you don't know where you want to go, it doesn't matter which path you take. A mission statement is the light at the end of the tunnel; once we know where we are going, we can better plan our path.

The team's mission should illustrate how their work supports the larger mission of the company. It helps everyone on the team understand that we don't write code for the sake of writing code, but to support our customers' needs and hopefully make their lives better.

Explaining how to create a team mission statement is out of scope for this article; however, there are many excellent publications on the subject, I especially like How to Create a Team Purpose Statement in Three Steps (and Why) by People's leader.

After defining the mission statement, incorporate it into the weekly work lives of the team. Start every planning meeting by reiterating the team's mission and ensuring that every task relates to the team's mission. In a perfect world, if a task doesn't fall under the umbrella, then it's a sign that you should be working on something else. Do the same with demos, start by reading the mission, then demo how the team has followed it.

Since organizations continually shift and evolve, mission statements should too. It's important to challenge your mission periodically, making sure it's always relevant.

Teams with a clear mission are motivated, but having a reason to work doesn't get you to the finish line, we'll also need structure.

Teams Need Structure

Developers often have a repulsion towards team processes, mainly because we've all had bad experiences: endless meetings, a rapidly-changing focus in daily standups, and pointless estimation exercises. But done well, processes and structure enable us to deliver better code more efficiently.

There is no such thing as a team without a process; even if it isn't explicit, every team has an underlying structure that keeps them together. By surfacing it, we have a chance to question and evolve it.

The team I lead follows three straightforward rules:

1. Limit tasks to three days in length (whenever possible)
2. Never get blocked
3. Keep work-related communication in the team channel, avoiding direct messages at all costs

Simple, right? Here is how these rules make us more effective:

Improve Progress by Creating Small Tasks

We've found that limiting tasks to three days increases our throughput since it means that we have something done every few days and, hopefully, shipped to customers.

This practice is valuable for three key reasons:

• It generates an important sense of progress since stagnation is the enemy of productivity;
• It increases visibility and coordination by informing what each member of the team is working on at any given time; and,
• It creates shorter feedback loops and incentivizes constant iteration.
• Estimating becomes less important since every task is around the same size.

Keeping tasks small is a team sport. Sometimes we aren't able to break things down, and that's okay, but my experience is that we can most of the time. With practice and discipline, our team now maintains a median throughput time of 3.2 days (as of writing).

Improve Flow by Never Getting Blocked

Being blocked is normal, either due to a lack of knowledge, context, or project dependencies. What shouldn't be normal is to wait until the next day's stand up to ask for help.

That's why, on my team, anyone who gets blocked and doesn't find an answer within 10 minutes will raise their hand. We commit to assist a teammate asking for help immediately.

To avoid constant disruptions, there is a goalie rotation where members of the team take turns to be the one who gets all the interruptions, deals with PR reviews, answers questions from other teams, and helps their teammates. Like in soccer, but in our case, instead of defending the goal, they preserve our efficiency and productivity.

Improve Communication by Keeping It Open

I've learned this from participating in open source communities: communication should always be out in the open. By keeping all work-related conversations, even the smallest ones, on an open team channel, we give the entire team the opportunity to participate in the discussion, which improves knowledge sharing and team coordination, since everyone is aware of what we all are working on at any given time. Sharing is caring.

As a result of our practices, we have very few meetings, reducing interruptions and providing us space for deep work. For example Stand ups' main goal is to support, communicate, and remove impediments; they should never be a status report. We get the same benefits by having seamless communication on the team chat, we don't get blocked, and we follow team progress on our board by having small tasks.

Ask your team whether they'd do standups if the managers were not in the room. If the answer is no, it's a clear indication that you have a status report.

Now Find Your Own Voice

The process I just described works for us, but every team has its own dynamics. Three days might be too short of cycle time for the nature of the work some teams do, or others might have too many junior developers and will need more guardrails.

I highly recommend writing a team working agreement, a set of rules that the whole team is accountable to follow and enforce. I really like this guide to team working agreements.

Processes are meant to change and evolve. Be flexible; if something is not working, just stop doing it! During retrospectives, we question our process. Do we want to keep working like this? Can we try something new next time? Retrospectives are the single most important meetings, don't skip them!

Play to Their Strengths

The board is set; we have explicit rules and a motivated team with a clear mission. As leaders, our goal is, of course, to ensure our team wins.

Soccer is a team sport, and it's every player's job to help a team win, both scoring and defending. A soccer manager wouldn't ask a striker to defend as his main role; it's obvious: a sticker might be brilliant scoring goals but lousy at defining them.

In the same way, when we know our team member's strengths, we can set them up for success.

The simplest way to know what people's strengths are is to ask openly. During one-on-one, ask questions like: What is your strongest skill? What are you most interested in? What do you want to spend more time doing?

As leaders, our responsibility is to build effective teams by empowering individuals to perform at their best and not micromanage or do their work. Delegate, give team members autonomy: set clear goals that people can be accountable for and remove ourselves from the equation. Jess Mink wrote about how to delegate: Think about the things only you can do and delegate the rest.

This is something we can't fake: real autonomy, delegation, and accountability are based on trust; trust is the single most important thing that binds a team together.

Use These Best Practices

In short:

• Motivate by creating a team mission statement that gives the team meaning.
• Develop a team agreement to provide structure.
• Empower the team to be the best they can by delegation, autonomy, and accountability.

And overall, just use extreme common sense, which, as leaders, means following uncomplicated solutions. Most of the time, the simple approach is the right one. Common sense and simplicity go a long way.

How has your leadership created a successful team? What ideas do you have to help others be better leaders? Tell me in the comments or tweet me @andresgalante (DMs are open!)