One of the side effects of working in a matrixed consulting organization is a pronounced lack of permanent teams. It varies a bit — there are long-running projects at 18F that may as well be permanently staffed — but I am rarely teamed up with folks I’ve worked with before. It forces me to stay on my A game when kicking off projects.
I’ve built up my approach to project leadership over the years, from organizing classmates in college to corralling Awesome Foundation volunteers to heading up formal product development teams. Here are a few habits that have served me well:
1. Find the value proposition.
I focus my project kickoffs on my people. In order to do that, I have to start with the problem. I need to understand what we’re trying to achieve, why it matters, what skills the project calls for. And I can’t lead a team effectively towards an outcome I don’t care about.
- At Microsoft the development process naturally included planning cycles that I spent reading through research, poking around the edges of the problem space, and refining feature proposals. I never had a team before the value proposition was identified.
- At 18F I do my best to talk to my partners during the business development phase (before a formal agreement is signed) to understand their high level goals. I also ask them to spend a little time roughing out a framing document (see: rule 2 in Building things that last). It’s very important to me to understand the product before we start pulling together a team — I particularly need to know what specialized skills we’ll need to bring to the table.
Either way, I need to know what direction we should be going in before I’m ready to lead a team there. This becomes the core of every interaction I have with the team. After all, it’s the reason the team exists.
2. Get people excited about the possibilities.
Once I really understand the problem space, I can start to build out a story around it. Finding opportunity is a critical product management reflex; it helps you deliver value instead of polishing existing features indefinitely. It’s also an important part of recruiting great teammates.
I start socializing my projects well before we’re ready to kick off. I start with managers and staffing leads, letting them know what’s on the horizon so that they aren’t caught flat-footed by my requests¹. Then I start talking about the upcoming project with anyone who will listen to me. After all, at this point I’ve found something in it that I’m really excited about. Why wouldn’t I share that with my coworkers? Even if the project isn’t a good fit for their interests, I’ve found that it’s pretty good for morale to hear your peers talk passionately about their work.
This spreads the word about the project, and people begin to get curious. Then they come talk to me. When my current project kicked off, three of my four teammates had informational chats with me and then asked their managers if they could be assigned to my team. The fourth had already worked with me on the precursor to the project, and had opted to keep working on it.
3. Talk to each teammate, individually.
I can’t stress how important it is for me to win the trust of my teammates. If something about the project isn’t working, I need them to tell me about it. That means they have to feel safe talking to me. Identifying and escalating problems is work, and for many people it’s very uncomfortable. People won’t waste their breath bringing up issues if they don’t believe that I’ll help them.
The first step of earning that trust is to just talk to people. Humans are social creatures, and as much as we like to talk about skill and efficiency and professionalism, we also need a casual conversation every now and then. I make a particular effort to talk to teammates I haven’t collaborated with before. What about this project stands out to them? What opportunities are they excited about? What’s their favorite book/movie/TV show? Do they have any pets? The goal isn’t to learn anything specific; it’s for both of us to see each other as people.²
I keep an eye on my interactions throughout the project. Am I talking to some people more than others? If I find myself having lots of 1:1 chats with a subset of my teammates, I reach out intentionally to the others. I tell them I don’t have anything serious to talk about, that I just want to say hi to make sure I’m not unintentionally ignoring them. This sends a message: I’m not playing favorites. I care about each of you. If you’re having trouble collaborating with someone, I’m not going to jump to conclusions before hearing both sides of the story.
This relationship goes both ways. Keeping an open line of communication with my teammates helps me feel confident about letting them work independently. If something important happens when I’m not there, I know that someone will tell me about it.
4. Get the team to listen to each other.
One of my favorite kickoff activities is to do a slightly modified Hopes and Fears exercise. I ask everyone on the team to silently write down their prior experience with the problem space, the skills they bring to the project, their hopes for the product we’re building, and their fears or worries about what might go wrong.
Unlike a group brainstorming exercise, I make a point of making it easy to see who wrote what (usually by giving each team member a different color of sticky note). Then we talk through each person’s answers, and I start to group like answers. This gives the team a visual representation of their similarities, and the unique things that each person brings. It also emphasizes that we’re a team, not a group. We have shared goals, we have relevant skills, and nobody is here by accident.
This is especially helpful when team members come from disparate organizations that may be perceived as having conflicting interests. If our parent organizations do have different goals, we should acknowledge them openly instead of ignoring them. And if we’re all chasing the same outcomes with this effort, we can see that. Either way the team gets a sense of everyone’s motivations, which makes it easier to understand and trust one another. And that trust helps people proactively reach out and collaborate with one another.
I don’t assume that my teammates already know each other. Our first kickoff breaks down barriers for everyone. That really matters when we’re working with a partner from another agency — it’s easy for my teammates to fall into a vendor-client relationship and rely on me to mediate communication with our partner. Sometimes that’s appropriate! But in the long run it’s inefficient and impersonal. If a designer needs to clarify a workflow or a developer needs to better understand the underlying data, I don’t want to make them wait for me. Especially in a distributed team, where many of my teammates start working hours before I’m even awake.
5. Embrace different working styles.
Everyone works a little differently, and it’s best to acknowledge that. I ask my teammates some structured questions: Are you a morning person, a night person, or somewhere in between? What’s your favorite communication channel? Would you rather pair with people or work alone and review after? Do you prefer open-ended or highly structured tasks? What should we do if you’re having an off day?
Then we use that information to shape our workflow. It helps me define when standup should be, how many team meetings we should set, how work gets tracked, and other bits of process. It also sets expectations with the team: if you tell me something, I’ll listen to you, and I’ll act on it. This plants the seeds for productive retrospectives, strategy sessions, and 1:1 conversations.
Takeaways
There are three major themes to my approach. First, understand the vision. You can’t inspire and organize effectively without it. Second, invest in relationships. Teams are made of people, not machines, and trust is key. Finally, empower individuals. If you set yourself up to micromanage your team, you’re losing the benefit of having other people involved. Fortunately, this is pretty easy to do if your teammates have a clear picture of the vision and strong relationships with one another (and you).
¹ In a matrixed organization, it’s critical to connect with whoever is in charge of staff allocation. Talking to staffing leads early helps them understand the project better, so that they can confidently find people with the right skills and personalities. It also builds trust — because I talk to them frequently about upcoming projects and explain my staffing requests in detail, I’m a known quantity. They know that the project is well-defined, that their people won’t get asked to do unfulfilling work, and that there is a stable point of contact who is taking responsibility for the project.
² I find myself heavily influenced by Ren et al’s Applying Common Identity and Bond Theory to Design of Online Communities, which postulates that people in groups are generally driven either by their bonds with the other members of the group (imagine a group of friends, who all have direct relationships with one another) or by their identity as a member of the group (imagine fans of a sports team, who don’t know each other but love their team). My approach is to plant the seeds of both types of attachment, and to try to create both a shared team identity and foster individual social connections. It’s worked for me so far.
