Management Do you want to be an engineer?

Entropy Crushers

When it was five of you sitting in the same room, it was easy. When someone needed to know something, they stood 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?” 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 display – 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; 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 ensuring 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 simultaneously. 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 ensure 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, 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 will 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 dish out the coolness fairly. 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 want 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 massive 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 collect additional essential information in the hallways, and they instinctively manage to move that collected information to the right people and the right teams at the right time.

Some humans 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 building?” They’re right. Project managers don’t write code, they don’t test the use cases, and they’re not designing the interface. Do 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 too big. You need role definition, which means being clear with everyone: Bob owns this, Frank owns that, and 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 project’s health, 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 project’s health because it’s their job to see the entire machine. It seems like they would have an informed opinion regarding the product.

I am worried about losing insight into what is happening. Tough news. As I’ve already mentioned, this is happening as you add each new person to the team with a new set of opinions, values, and experiences. 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 every week.” The project manager will take this request and do their damnedest to find that data (and the people creating it), 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 a poorly defined artifact. Gantt charts are great at showing the order of operations for building software, but never in the 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. I’ve seen this screwed up 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, need 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 a 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 call them) must 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 will kill creativity and innovation on my team. This isn’t 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 in 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 the 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 creativity. However, 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 leader, 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 great people to 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 you not want to be an engineer? If this is what you love, even as a lead, this is where you should spend your time. You’re never going to code like you did when you were an individual contributor. Still, 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. Like each new person, each new role has a unique ability to affect the culture in ways you’ll never predict. You must design around your specific pain carefully, but once you hire and land the first person, you must also pay careful attention to 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, I guess 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 protect this time viciously.

Leave a Reply

Your email address will not be published. Required fields are marked *

21 Responses

  1. Aw, come on.

    Everybody knows all you need to manage a project is learning MS Project. Put Gantt charts in Powerpoint, and create color coded dashboards. Then upgrade to Primavera when things get too far behind. right?

    Seriously, thank you for the articulate clarification and definitions of terms. It’s true that generations of bad project managers have ruined the term. I am a former developer, system architect, and I manage projects, but I would call myself anything but a Project Manager.

  2. Andomar 11 years ago

    “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.”

    Seriously? In my history of software development, all measures end up doing the same. They cause engineers to optimize for the measure instead of customer satisfaction.

    I normally love your articles, so perhaps you could write about the kind of metrics that you think are useful to gather.

  3. Regarding Andomar’s statement, deciding useful ways of measuring projects is one capability that separates great managers from good managers.

    In the hypothetical, I think we can poke holes in most metrics/examples – they will vary widely based on project, environment, the company’s capabilities, and their development methodology.

    So if I were to abstract it, generally, metrics must be considered in aggregate, and compliment each other. i.e. if there is a metric that relates to speed of delivery, then there usually would be a metric that relates to quality and/or satisfaction.

  4. Metrics are an incomplete mapping of goals onto a set of measurable facts. That’s all, and the key is “incomplete”. It’s not a 1:1 mapping – your metrics don’t necessarily map onto your goals.

    Any time metrics slips from being “a good enough mapping of goals” to actually being a goal, you have a problem. That happens all the time. And the only cure I know of it is to spend a large amount of time talking about it, recognising that it happens and push yourself and the team away from it on a constant basis.

    This doesnt mean that defining metrics is a bad thing – you need them to know you are going the right way, but you need to be aware of the constant presence of “I need to do A, and I measure A by looking at B, because A maps relatively well onto B, that means I need to maximize B” and correct for it by speaking at length about how B is not your goal, your goal is A, and hey, here are some examples of how we have achieved A recently.

    Good metrics also contain some self-correction, but your goal isnt to set up a game where if you hit all [B]’s, you have achieved all [A]’s – thats way too hard and too expensive, your goal is to set up a group of [B]’s that are closely enough correlated to the set of [A]’s you want to achieve, and to then spend a lot of time talking about your [A]’s, and very little time pushing your [B]’s in people’s faces (you just want to look at your metrics and know if you need to steer, you dont want to steer by looking at your metrics).

  5. An excellent article that summarize the plane-view of the development process with the focus on project managers and the way they steer the project.

    Regarding metrics, the first thing is to understand the development process that you are using in the team, then to get the meaning out of the metrics. For example in Agile development (SCRUM based) the velocity of the team is a good metric that can give you indication about efficiency.

  6. I really enjoyed this post. You say this in a number of ways without having to say it, but I’ve found that being an effective and value-add PM requires that you build cred with engineers. You’ve really highlighted some of the best ways to do that.

    Your notion of efficiently mechanizing the collection of the data needed to power artifacts and inform decisions really illustrates that point. Something as simple as streamlining a few JIRA screens or building lightweight Confluence [Asana, whatever] templates can go a long way in building credibility amongst engineers that you’re here to actually add value to the SDLC.

  7. Charlie 11 years ago

    I really liked your insight into where project managers fit into the software dev lifecycle and your succinct way of explaining it. It’s a concept I have tried to explain to people on a regular basis who just don’t get it!

  8. It seems like most people have worked with a bad project manager in the past, and because they have so *few* examples of project managers they write off the whole field.

    It’s like someone going into a bakery, getting a burnt loaf of bread, and leaving cursing all bakers.

    Because people’s mental models are not well developed about project managers, it’s very difficult to persuade them that project management could be more helpful.

    To that end, I wrote this blog post trying to address what project managers do–where the audience is more IT people in higher education rather than growing companies:

    We will keep fighting the good fight.

  9. Round of applause for this post! I’ve been all three – engineer, manager of engineers, and project/program manager – and I’ve heard and answered those project concerns more times than I care to count. It’s a really good start if the team understands: “They are here to help with X because if we don’t solve X, we are screwed.”

    I will be sharing this post with the PM community!

  10. Vickie 11 years ago

    I couldn’t agree more with your first reason why people react badly to project management: “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.” When I finally worked with a good one, I had to take back all the bad things I’d said about project management all these years. Unfortunately, the really good ones are rare (and very busy).

  11. I’m a PM in the communications/marketing field, and even though the industries are different, there are many parallels here. I’ve been questioned about the value of a PM and whether or not I should weigh in on a project’s design. My answers were similar to yours, but with a little more cursing. I appreciate you sharing these insights.

  12. Robert 11 years ago

    Speaking of illumination, that’s what you’ve given me with this post. I’m a tech writer with several years of experience working on software development teams, but TWs are often a bit removed from the chaos. Thank you for the insight!

  13. I like your explanation for PM task and it role in the industry. Project manager are responsible for project starting to its delivery. PM is the main key of successful project delivery.

  14. I like your article. The problem is, that not many PM’s have experience in an agile environment – and therefore, the good ones are really hard to find.

  15. AlaAla 10 years ago

    Brilliant. I am a project manager and enjoy fiercely protecting my engineers from having to do too much of anything other than build to their hearts’ content. I love knowing everything that’s going on and being more the asset to my team because of it.

  16. Partha Sundaram 9 years ago

    Love your clarification of Project vs Product vs Program Managers! I do agree that a ton of project managers are essentially paper pushers but would love to hear more specific examples of “entropy crushing” that you’ve witnessed.

  17. I liked your explanation, especially the project rules part, many PM’s go half-legged on those rules, something that people should really not keep behind,

  18. I like your article. The problem is, that not many PM’s have experience in a agile environment.

  19. Thanks, This is helpful. Sometimes it leads to overlapping of authority and responsibility between the top management and project management.

  20. Though it is quite usual to become an engineer, but in this article you have surely stirred a hornet’s nest by telling the harsh truth.

    Every engineer or people co-related to this field would always want to improve their efficiency.

    The metrics to measure the goal of a project has been explained greatly by you. Thanks for writing such an insightful content that would help many for sure.

  21. The problem is, that not many PM’s have experience in a agile environment. by the way Really I enjoy your site with effective and useful information. It is included very nice post with a lot of our resources.thanks for share. i enjoy this post.
    please also visit :