One of my favorite things about the life journey that I find myself on is that I’m always learning. Every. Single. Day.

Some days I learn something new… most days I learn something new, actually. But then there are the days when I am reminded of something I learned years ago but have somehow forgotten for a time.

The Mythical Person Month is one such topic. It is a distinct and important lesson that I have learned many times now it seems.

So what exactly is the Mythical Person Month, you ask? Since I like to tell stories, I’ll start there.

The Calm Before the Storm

When I was early in my career as a budding software engineer, back in the early 2000s, I worked for a railroad company. Actually, it was a subsidiary of a railroad company.

I was pretty green at this stage. I had a good idea of what software engineering was all about, but I had a lot to learn. I was engaged with my team, contributing to standards, architecture, code, and testing procedures. The project was exciting with regard to both the tech stack and the business problem.

The team was under a lot of pressure to deliver. We were building seniority software to replace an aging legacy mainframe system. To call this legacy system antiquated is an understatement. Daily chest compressions were necessary to keep it going. It was dead in the water, and it needed to be replaced ASAP. There was no time to waste.

As we clipped along, sprint after sprint after sprint, building the new platform, one thing became obvious. We were going to miss our release deadline.

We were so close, yet there was much left to do. There were unfinished features. We didn’t have a QA team. Automated testing had sputtered out as the focus turned to building products. “We’ll add more test coverage later. Let’s focus on getting the product released. The release is priority #1. Testing can wait. Hustle!”

Things were going south, and we all knew it.

We all had trepidation, and it wasn’t only my team; it was the entire company! Our survival hinged upon this release and wowing our sole customer. Without wowing this sole customer, we wouldn’t receive our next round of funding. And when I say that, I mean our jobs were 100% on the line.

The Fallout

Sipping coffee on a rainy Tuesday morning in the spring of 2008, I remember reading my email. Our CEO at the time had sent the team a meeting invite about an impromptu gathering that afternoon. The product and QA teams were invited as well.

We all sat down in the south conference room, bracing ourselves for the news. What exactly were we in for?

The CEO walked into the conference room. He was sweating and visibly flustered. He paced around the room. After a long pause, he spoke, “If something does not change, we will miss our deadline. If we miss our deadline, we will not secure the contract with our client. If we do not secure our client, this project may come to an abrupt end. My job is on the line right now. And so is yours.”

This news was, of course, not surprising.

Our CEO then proceeded to tell us that he has a plan. His plan was this, “We will hire 5 more engineers. Five more engineers will allow us to increase velocity, and effectively pull our schedule in. We can hit the June release date! We can secure the next round of funding!”

I wanted his theory to make sense. Even more so, I wanted it to work.

If we could pull the schedule in, we could deliver on time. If we delivered on schedule, our client would be wowed. If our client was wowed, we would get funding. If we got funding, we would all get to keep our jobs. It seemed like a good plan.

I’ll spare you the details of what actually happened, but we did not hit our deadline, and the CEO got fired.

The Mythical Person Month

That story perfectly demonstrates the fallacy of the Mythical Person Month. So what is the Mythical Person Month exactly? It’s the idea that by adding additional resources, velocity will increase, and deadlines can be pulled in.

Based purely on math, this theory seems reasonable. It takes X number of hours to complete a feature. Divide X by the number of resources available, in work days, and you can figure out an approximate delivery date. Add additional resources, and you pull your date in. Simply put, you can get more done in less time, with more resources… right?

Wrong. Well, at least not in my experience. In the world of software, I have found it to be quite the opposite. Thus the use of the word “Mythical.”

Why It Doesn’t Work

Here are four reasons why the Mythical Person Month is just that, “mythical.”

First, it takes, on average, 6 months for a new engineer to actually become effective enough to be an asset. The reason for this is simple. Software is complex. Architecture is complex. Processes are always different from those you are used to. Things are always changing.

Simply put, it takes time for a new hire to adjust, to learn the business, to learn the technology stack, the QA process, infrastructure, tools, and the list goes on…

Second, throughout my career, hiring takes up a ton of time. Growing a team by simply adding anybody doesn’t make sense. Skilled and experienced people who can execute are necessary, and they usually are not easy to find on short notice.

Third, it takes a LOT of time for senior engineers who are already acclimated (and productive) to coach up new hires. Even when the code is clean and the documentation is current, you can’t make a rock star out of a new hire overnight – or even in a month, for that matter. Not that it’s not physically possible, it’s just not probable; it almost never happens.

Fourth (and finally), adding resources, especially multiple new resources, almost always slows down velocity, at least for a period of time. There. I said it.

What We Can Take Away

I have seen this happen a dozen times, and it always shakes out the same way. So, what are my learnings from these experiences?

Every time I have experienced the Mythical Person Month, I’ve asked myself a few questions. How did we not see this coming? What should we have done differently? What could we have done differently?

It’s not a simple question to answer. Why? Every team is different. Every product is different. Every business is different. Every architecture is different.

So what do we do with that? Although I don’t have a silver-bullet answer, I do have some ideas from my learnings.

First, have foresight. Plan better. (I’m a sucker for planning. Just ask my better half.)

Second, keep your eye on the prize. Always. The business should always be #1, and the business doesn’t care how great your code and test coverage are (even though we “coders” do).

Third, don’t hesitate to pivot. And when the need arises, do so, and do it quickly.

Fourth (and finally), always, always, always keep in mind the business goals. No matter how great the code is, if the project fails, the code doesn’t matter.

Tying It All Together

In the case of the story I talked through above, we didn’t pivot soon enough. We got caught up in the day-to-day. The engineers had tunnel vision on the code. The CEO found out too late in the game that the deadline was in jeopardy. Our eye was no longer on the prize, and ultimately, we had lost focus on what mattered: the success of the business.

I’ve taken this lesson to heart more times than I care to remember. It’s always painful, even if the project continues. And as painful as it is to constantly plan, pivot, and keep your eye on the prize that is the success of the business, it should be the norm.

At the end of the day, it’s always better to say to yourself, “I love it when a plan comes together,” than it is to make excuses. Plan. Pivot. Course correct. Execute. There are no silver bullets.

I hope my story and tough experiences can help you moving forward. Software isn’t easy. Business isn’t easy. Coordinating a perfect world where the engineers, product managers, and the CEO are all on the same page isn’t easy.

What I can tell you, however, is that when it all comes together, it’s 100% worth it. The taste of success is sweet and winning is a LOT of fun.

PS – if you enjoyed this topic and want to learn more, it’s worth noting that Frederick P. Brooks Jr. first published The Mythical Man Month in 1974.  You can find his book, The Mythical Man Month here.