When it was five of you sitting the same room, it was easy. When someone needed to know something, they stood up in the middle of the room and asked, "Who broke the build?" When a decision needed to be made, you looked up at Phil and said, "Phil, this needs to scale from day one, right?" and Phil nodded. In a nod, you defined the entirety of your product performance plan. When someone was struggling or was blocked, you could tell because they were swearing profusely at the monitor - directly across from you.

I should help him.

But now it's 105 of you. You're spread out over two floors of the building, you're working on two products, and you're approaching the dreaded moment where you don't know the name of someone on your team. This is the first of many warnings that the team needs to evolve.

I want to make the argument that it's time for project managers.

WHOA WHOA WAIT RANDS WHOOOAAAAAAAAA. We've got a self-starter engineering culture, we're flat, and we're not about to dilute that culture with... project managers.

I've run into this response a lot. When I hear this knee-jerk reaction I hear the following:

• Most engineers don't know what a project manager does, and if they do, they usually don't know what a good one looks like.
• Crap project managers have ruined the reputation of the gig.
• By suggesting you don't need project managers, you're saying that you, an engineer, want to do this work and my question is, "Do you or do you not want to be an engineer?"

The Project Rules

First, some definition. Project manager, product manager, and program manager. Let's clear that up. A project manager is responsible for shipping a product, whereas a product manager is responsible for making sure the right product is shipped. A program manager is an uber-mutated combination of both that usually shows up to handle multiple interrelated projects like, say, an operating system. Different companies use the names differently, but for this article, project = ship the product, product = ship the right product, and program = ship many interrelated products, usually at the same time. Got it?

Second, a rule: the addition of each new person on your team increases the cost of each of the following:

1. Communication. How much effort is required to get Idea A and make sure it travels to all the necessary people?
2. Decisions. How quickly can a group of people best choose Path A or Path B?
3. Error Correction. How long does it take to detect and fix when something is going wrong?

Think of it like this: when it was five of you and one of you wanted to do a new feature, how'd it happen? Well, you did it. You wrote the feature in the morning, tested it after lunch, and then checked it in before dinner. The update to the team that a new feature landed was the check-in notification sitting in everyone's inbox and the silent nods as they read the check-in... Sweet, we needed that feature.

How does it happen now?

After the latest release, there's a feature review meeting where the team sits down and scrubs JIRA and comes up with feature nominations. Then they vote internally, and then they vote with the business development team. After those votes are counted, we do a prioritization pass before we send the list to the VP of Engineering, Phil, who takes the list and prioritizes it against his vision for the product. That takes two days and, invariably, we argue about prioritization.

Now we've got an initial list, but who is going to do the work? ASSIGNMENT MEETING! More debate about who should do what. Further arguments occur because there are cool features and not-cool features and features must be assigned carefully to fairly dish out the coolness. Sweet, features have been assigned, but first, we have to write a feature spec, which will then need to be vetted with the rest of the team to make sure we're writing the right feature. I would like to point out that a single line of code has yet to be written and I'm already exhausted.

Take a look at the work in the prior paragraphs. If you're a lead on a growing team, you have your unique version of this process, and to me, a huge chunk of this work is for the project manager. You already have a project manager and it's you. You're a full-time engineering manager, you're the leader of the people, and you're also a project manager. My guess is that on a growing team you're likely doing at least one of those jobs half-assed. Which means you're officially part of the problem.

A good project manager is one who elegantly and deftly handles information. They know what structured meetings need to exist to gather information; they artfully understand how to gather additional essential information in the hallways; and they instinctively manage to move that gathered information to the right people and the right teams at the right time.

There are humans who are really good at this. They thrive on it. Engineers have difficulty believing this - it's the same issue they have with managers. They see these strange humans focusing furiously and scurrying hither and yon and they wonder, "What are they actually building?" They're right. Project managers don't write code, they don't test the use cases, and they're not designing the interface. You know what a good project manager does? They are chaos destroying machines, and each new person you bring onto your team, each dependency you create, adds hard to measure entropy to your team. A good project manager thrives on measuring, controlling, and crushing entropy.

You did this easily when you were a team of five, but if you're going to succeed at 105, what was done organically now needs to be done mechanically.

The Project Concerns

I've heard a litany of concerns about the introduction of project managers. My response is a good starting point to understand who I believe the role fits on the team:

I am worried about project managers influencing product direction. Two points here: first, remember you're no longer in a world where everyone is doing everything. You miss the world because it made you agile, but you're just too big. You need role definition and that means being clear with everyone: Bob owns this, Frank owns that, Percy owns the other thing. What does "own" mean, Rands? Glad you asked.

To me, ownership means that a person is responsible for all decisions for the thing. They are accountable. At Apple, we called them Directly Responsible Individuals. You will likely call them something else. In this world of delicious new ownership, a good project manager owns the execution of the machine that makes sure everything is getting done. It's no more or less important than any other role, but it's essential to starting a project, understanding the health of that project, and deciding when you're done.

Second point: what kind of douchebag manager doesn't want every single person on the team to have an opinion about the product? Good project managers have a unique insight into the health of the project because it's their job to have visibility into the entire machine. It seems like they would have an informed opinion regarding the product.

I am worried about losing insight into what is going on. Tough news. As I've already mentioned, this is already happening as you add each new person to the team with the new set of opinions, values, and experience. An effective project manager instinctively creates artifacts of insight. It's their first question when arriving on the scene: "What... the fuck is going on here?" Your first conversation with your new project manager sounds like this: "I want to be able to measure X, Y, and Z and I'd like to be able to measure them on a weekly basis." The project manager will take this request and do their damnedest to find that data (and the people creating that data), efficiently mechanize its collection, and eventually present you the artifact. Given the chaos factor on your team, the work necessary to build this artifact varies wildly, but if you haven't seen a draft of any valuable artifact in two to three months, something is wrong.

There is no crap work on my team. This is a concern raised by someone who doesn't understand the role of a project manager or has been burned by crap project management. It was probably this meeting: you were sitting there meeting with the entire team where a project manager showed a Gantt chart on the wall and presented a partially informed opinion as fact. "We are three months from shipping." Everyone thinks, but does not say, "Bullshit." This partially informed person rambles for another 30 minutes, the meeting completes, everyone shuffles out, and the reputation of project managers as shovelers of bullshit is furthered. This was a crap meeting based on crap work.

There are a couple of memorable screw-ups in this meeting. First, you've got the a poorly defined artifact. Gantt charts are great at showing the order of operations for building software, but in the never in history of ever have they effectively been used to measure when to ship that software. Second, you've got the whole team staring at this useless artifact and the person presenting it - both of which are losing credibility by the second.

One of the easiest ways to screw up the landing of project managers on a team is not to be painfully aware of what you need out of the role. The way I've seen this screwed up is when the guy in charge says, "Well, this looks bad. You know, at Apple, we had engineering project managers. We should have engineering project managers. Go hire them."

Incorrect approach. You are not and never will be Apple. What your team, and your culture, needs out of a project manager is entirely dependent on the people, the team, the culture, the projects, and this moment in time. Top down declarations of necessity without deep understanding of the situation within the team are a terrific way to set up a new role for failure. The arrival of project managers (or whatever you end up calling them) needs to coincide with a clear and present danger to the product or the team. They are here to help with X because if we don't solve X, we are screwed.

I am worried that process nerds like project managers are going to kill creativity and innovation on my team. This isn't actually the issue that folks fear. What they're really saying is that they don't want to give up control, and again, I think this comes from prior awful interactions with project managers. See, the reputation of a project manager grows over time because of their penchant for knowing, well, everything. It can be intoxicating being the only person who knows you have the best assessment of the situation among the chaos, the person that everyone goes to because you have the information. There are project managers who go crazy with this power and become political. They become information brokers, which means they're precisely the opposite of the job. They're using information to control rather than to illuminate. My advice: fire these people as quickly as possible.

A good project manager's job is to decrease chaos by increasing clarity. I understand that chaos can be an essential ingredient in creative, but I guarantee you -- I promise you -- even with the best project manager on board, you still get to run around like a crazy person because the sky always unexpectedly falls. Chaos in a complex system is a guarantee.

The Question

As a lead, you have three jobs: people, process, and product, and you get to choose how to invest in each of those roles. As a demographic, you're likely best at product followed by process, and finally, by people. What's weird is that you seem to be spending all of your time working on the people part of the gig, right? You should hire a great people lead, right? Maybe, but perhaps the situation is that you're constantly talking with the people because the process piece is broken. You're serving as a person who moves information so that we're all on the same page, so that the people are happy and efficient. Do you love this job? Probably not.

My question remains: do you or do you not want to be an engineer? If this is what you love, even as a lead, this where you should spend your time. You're never going to code like you did when you were an individual contributor, but your company and your team will get disproportionate value from the work you do that best approximates engineering.

As with any evolutionary change on your team, you need to be paranoid. Each new role, like each new person, has a unique ability to affect the culture in ways that you'll never predict. You need to carefully design around your specific pain, but once you hire and land the first person, you also need to pay careful attention for unintended side effects. The irony of the arrival of crap project managers is that you're effectively punishing inefficiency with useless bureaucracy, which, wait for it, creates more inefficiency.

A great project manager is rare, but so is any great hire. However, my guess is that you want to be an engineer. You want to focus on the satisfying act of building, and I think you'd be crazy not to viciously protect this time.