Mike Acton (of the Insomniac Games fame, now working at Unity) came up with a memorable metaphor describing what it means to optimize a computer program. It goes something like this:
“When you try to race a car, your problem is not how good the car’s engine is, your problem is not how streamlined the car’s body is, your problem is that there are a dozen clowns sitting in it, holding it down.”
And so, when optimizing a program, your primary focus should always be on removing the said clowns from the car. Any further concerns are a luxury that you can afford later, once the clowns are out of the car.
For those not familiar with Mike Acton’s talks, the clowns in this metaphor are the obvious, glaring performance problems in a program. They are the pieces of code that were written ignoring the reality of what modern hardware can and cannot do fast. And so when a program is executed, the hardware, instead of doing the actual useful work, is forced to complete an endless series of arduous bureaucratic tasks that have very little to do with the ultimate goal.
The more I thought about this metaphor over the years, the more it struck me just how well it applies to other areas of life. It fits especially well when talking about project management.
Usually, you first get interested in effective management when you are put in a position where you have to actually manage a team. And inadvertently, what you will find in your google searches and the books you read is a number of management methodologies. The usual suspects: your Kanbans and Scrums. Your waterfalls and your Teal Organizations. What is, however, not stressed nearly enough is the absolute necessity of removing the metaphorical clowns from the car.
Sure, if your organization really commits itself to implementing a modern management methodology, some clowns might get out of the car as a sort of side-effect. After you hire a couple of Scrum process gurus, you might even convince another clown or two to kindly move aside and maybe take up as little space as possible. But it never seems to be the centerpiece. In my own experience, most problems in project management are really obvious and really serious. That by no means makes them easy to fix. Fundamentally remaking the very core structure of a computer program to get rid of the clowns is not easy. Neither is remaking the structure of an organization.
But what are the clowns in the realm of project management? First, let me be very clear that I’m not talking about any single person or persons. Rather what I’m talking about are the glaring, obvious problems that an organization has that are apparent to anyone working in it. They are the processes that ignore the underlying reality of how humans think and behave. They are the very things that cause organizations small and large to make a series of nutty decisions that no single sane human being would ever make.
Clowns come in many shapes and forms. Making an exhaustive list of all of them seems like an impossible task. Instead, I will tell you about a couple of clowns that I got acquainted with especially well while working in the game industry over the years.
Clown #1: Too Many People Involved
Even digging a trench becomes a complicated task when enough people get involved.
More people always mean more communication.
More people always mean more conflicting interests. After all, each person on a project has an inherent interest in not appearing completely useless, especially if put in a decision-making position. Even within a top-down hierarchical structure, most of the fine-grained decisions are not made at the top. The people who decide are the ones doing the actual work. And the more people there are, the higher the chance that those small decisions will not fit well together.
It’s understandable why under time pressure, sometimes the “all hands on deck” approach is adopted. However, once the dust settles, once the unmissable deadline is finally missed, the disastrous consequences of too many people getting involved become apparent. The once well-organized code structure has become muddled. The once consistent art style has become eclectic. The once clear project vision seems to have drifted off the road.
To make things worse, once the project gets labeled as in trouble, even more people get involved. The outside consultants, the new project managers. And so now those new people feel the need to exert their influence over the final product.
The reality is, nothing will hurt your project as badly as getting too many people involved in it. Too few people will make you miss a deadline. Too many people might kill your project for good.
Clown #2: The Outsider VIP
People enjoy feeling important. And important people have to make important decisions. After all, if they are not making brave decisions about important topics, maybe they are non-essential to the project, or dare I say, even useless? But important people are also busy people. They don’t want to read your 10-page exposition of the problem. They want the executive summary.
This simple dynamic creates a situation where the people making the most long-lasting, consequential decisions are also the ones who do not work with the team on a daily basis. We are led to believe that those super-human super-intelligent people can dedicate a small portion of their time to the project and somehow develop the same level of understanding about its intricate inner workings as the people actually doing the work. That pretty much never happens.
The especially egregious manifestation of this power dynamic is what I call the outsider VIP. Sometimes, the person in charge of a project needs to win over someone’s sympathy. It may be an investor or an important higher-up. And so this VIP gets invited to look over the progress being made. Any comments that the VIP makes are to be treated as gospel. That is especially true if the visits are recurring. After all, the VIP might feel offended if none of their feedback gets incorporated into the product. If the courtship is accepted, soon enough, what once were occasional visits, become regular bi-weekly meetings. The VIP feels encouraged to speak their mind more and more, even on the topics they once felt they had no clue about. Their opinions and remarks become fixed parameters in an ever more complicated system of equations that need to be solved in order to ship the final product. Where once was flexibility, now there is a set of predetermined decisions that the team needs to work around.
But if leaders are not supposed to make important milestone decisions in a project, what are they supposed to do? In my experience, effective leaders are the ones that mostly listen to their team members and help them come up with solutions. They may suggest areas for the teams to explore. They are reluctant to override teams’ decisions. They are self-conscious of the disproportion between the power they hold and the knowledge that they have. They get involved heavily at the beginning to assemble the team and put the project in motion. However, once the ball is rolling, they shift to a role where they look for structural problems and intervene when authority is actually needed.
Clown #3: Low-Quality Decisions
Project management is so much more exciting in the domain of software development than something last century, such as construction. Those old-school construction companies have to prepare a complete, exhaustive project of the entire building in advance. And they have to calculate the total amount of materials used. And even measure their weight and perform physics simulation to figure out if the building will hold up under heavy wind. And once the construction begins, those decisions cannot be undone. This is so un-agile. Why can’t we just start building right away and see how high we can go?
The softness of software is its biggest upside. But it can also be its undoing. The relative ease with which decisions can be overturned even very late into the development cycle paradoxically makes it harder to make good decisions early on.
We know we should pinpoint our target hardware so that we can measure our progress against minimal specs. But it never seems urgent, and also, didn't a wise person once say that premature optimization is the root of all evil or something like that?
We know we should develop a playable prototype of a game before we actually decide to scale our efforts to a team of tens or hundreds of people. But the iteration on the prototype takes lots of time, and those employees are sitting idle so let’s start doing stuff right away!
Making decisions feels good in the moment. It’s like ticking a task off the to-do list. But early low-quality decisions can easily be more harmful than outright admitting that a decision cannot be made at this time. After all, if there is a hugely consequential decision still pending, your first instinct is to find more data to convince you and your team to go one way or another. If the decision is “made” then your instinct is to move on and never look back.
There are many more clowns in the car waiting to be noticed. After all, the unsuccessful projects are not unlike Tolstoy’s unhappy families: each unhappy in its own way. Tell me about the clowns that you have met in your professional life. Or even outside the professional life.
