If you’re a developer who’s worked with project managers before, I can say with 99 percent assurance that, at one time or another, you’ve been frustrated with them. While you’re tackling a complex feature head on, here the PM is, with the nerve to ask you when you think that might be finished. While you’ve spent hours dissecting a deep, mission-critical problem in your code, here the PM is, nudging you to get that trivial button label fixed. And here the PM is again, asking you whether you can get that new client feature request that just came in out of the blue completed today.

You know the feeling. Deep inside of you, you believe the PM isn’t doing much. He’s simply asking you when, how, and if you can. You’re the one sweating the details, doing the real labor, and earning your keep, right?

As developers, when our jobs get difficult, it’s usually because there’s a complex problem to solve in our software. We buckle down for a few hours and fight through the pain. We ebb and flow between spurts of frustration and ecstasy. For us developers, the hard work is in managing the product. We know everything about the application, and as discussed in Essay 40, ​ Define the Goals of Your Application ​, the application is what we should all be concentrating on.

Project Management Is Primarily People Management

But for a project manager, the goals are different. While good developers are the experts in the domain of the application, good project managers tend to be the experts in the domain of the client. They’ve developed an intimate working relationship with the guy on the other line or at the other end of the email. They know when they can push back or when there’s something that’s really important to the client—even if we might disagree. Client work can be an emotional struggle for the PM.

The Double-Edged Sword of Project Management

In a restaurant, it’s the waiter who takes the heat for a soup too cold, a steak too raw, or an order too slow. If it’s one of those particularly bad nights, the customer usually asks to see the restaurant manager to complain about “the worst meal they’ve ever had.” As for the chefs in the kitchen? They tend to get off easy.

Yet, on those particularly good nights, the ones where a table has had the best meal of their lives, who gets thanked? Not the waiter. Not the restaurant manager. It’s the chefs! Every now and then, they’ll even come out for a bow.

It’s the same story in our industry. From the client’s point of view, the project manager is the company. In a team of other designers and developers, only project managers are the ones responsible for everyone else’s actions. If one developer is pulling his weight but his fellow developer next door isn’t hitting the mark, it’s the project manager who usually has the lone, unenviable job of relaying the bad news to the client and then taking the heat.

But launch a beautiful app on time and on budget, and it’s the developers who share in the praise. We’re the ones who get the free pizza and beer lunches from a happy client.

Project management is important in ways that go beyond just the application, and it’s oftentimes a thankless job. So, the next time one of your PMs asks you to implement a client’s new feature request, don’t immediately go whipping out your iron sword. Find out what’s really driving the request. You might be able to recommend a simpler alternative. You could come up with a well-spoken argument against it altogether.

The more ammunition you can give a project manager to take back to a client, the more you empower them to do their job well.

In this chapter, we’ve seen the delicate nature of client management. In the end, good client management is often achieved through our own self-worth. When we’re enthusiastic and engaging, clients get a vicarious taste of what makes this vocation great. When we’re transparent and personable, a moment of potential conflict becomes a time to revisit the original goals of the application.

In the next chapter, let’s get back to the nonhuman. There’s an equally important relationship we must maintain between ourselves and our code.