The Biggest Temptation of a Software CEO

Listen to This Blog Post

In his book, The Five Temptations of a CEO, author Patrick Lencioni discusses five areas in which CEOs tend to inadvertently prioritize the wrong things. These “temptations”, as he calls them, can lead to poor decision making at best, and can risk the very survival of the company at worst. They are:

1. Prioritizing status over results
2. Prioritizing popularity over accountability
3. Prioritizing certainty over clarity
4. Prioritizing harmony over productivity
5. Prioritizing invulnerability over trust

Though these temptations tend to present themselves within CEOs operating across all industries, my experience leading a software company taught me that there is a sixth temptation, unique to software, that seemed to present itself on a near-daily basis. More specifically:

The biggest temptation of a software CEO is to throw bodies (specifically engineers) at problems.

Consistently missing release deadlines? Hire a few more engineers to expedite the process. Missing key features that your competitors have in their products? Hire some more engineers to build them. Having trouble maintaining your existing code base while your sales team complains that they don’t have any new products to sell into existing accounts? A few more engineers should fix that. Do you have more good ideas than people to execute on them? Add some capacity by bringing on a few more engineers.

…One can see how slippery this slope can become.

Though I likely succumbed to each of The Five Temptations above, it is this sixth temptation that I struggled with most frequently. With the benefit of hindsight, I’ve come to a few realizations that I’d like to share with fellow software CEOs, in hopes that they’ll do a better job of managing this temptation than I did.

The Mythical Person Month

In his seminal book, The Mythical Man Month, (I’ve used poetic license here to rename it The Mythical Person Month), Dr. Frederick Brooks, Founder of the Department of Computer Science at the University of North Carolina, said: “When schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster”.

One reason, Dr. Brooks speculated, why 1 plus 1 doesn’t necessarily equal 2 is because communication channels grow non-linearly as team size increases. You may be familiar with a graphic similar to that which is presented below, which shows how various team sizes (in this case, teams of 3, 7, and 11 people) create exponential growth in the lines of communication that must be maintained between team members. Time spent explaining, debating, updating, questioning, and educating is, by definition, time spent not coding. And at the risk of perpetuating an overgeneralization, in my experience, engineers aren’t ones to shy away from expressing their (often very specific and deeply engrained) opinions, which does indeed tend to lead to much discussion and debate if not managed properly.

More recently, Rich Mironov published a hugely popular four-part blog post (The Four Laws of Software Economics), within which he states that a company’s development team will never be big enough. He attributes this to “an unquenchable thirst for more software”, and the fact that “development can never build as fast as we can dream up new things”.

Though he never explicitly mentioned this, Rich was indirectly referencing a principle called Parkinson’s Law, which states that work expands to fill the time allotted for its completion. In other words, the more capacity that you add, the more work you’ll find to fill that capacity. And likely in very short order. For this reason, a unit of additional capacity often doesn’t produce a unit of additional output.

Are You Solving the Right Problem?

All of the above is to say that the solution to whatever problem you’re trying to solve may not be to add more engineering capacity, even though it may seem like the logical solution in light of the circumstances. For example, consistently missing release deadlines could be an engineering problem, but there is an equal chance that it’s a problem with scoping, project management, and/or lack of clear product requirements. Having more promising ideas than developers to build them could be an engineering capacity issue, but could also be symptomatic of a company-wide lack of focus and prioritization. Missing a key feature could be attributable to an engineering team that’s too small, but it could just as easily be caused by poor or nonexistent company-wide customer feedback mechanisms that caused the engineers to build the wrong things in the first place.

Often, the problem that is seemingly solved by adding engineers is actually just a symptom of a much deeper problem, to which the solution is rarely that simple. In other words, by adding more developers, we’re often attempting to solve the wrong problem, hence the frequency with which this strategy does not work. In my experience, what often first seemed like an engineering capacity problem was actually a problem that fit into one of the following three categories:

1. A Product Management Problem: Product Management decides what products and features a company should build and why they should build them. Engineering then decides how to build them, and goes about the process of actually doing so. If engineers are productively working on the wrong things, then even a team of infinite size won’t help to move the company any closer towards its desired destination. Before any software company significantly increases the size of the engineering team, they must first be confident that their team is working on the right things, often via a highly functioning Product Management operation.

2. Strategy/Focus Problems: When companies first start out, many take business from wherever they can get it: Customers who don’t fit the ideal customer profile are sold to, features that are non-core get built, and functionality specific to a single customer is maintained to ensure continuity in that relationship. Though this is understandable – maybe even expected – for bootstrapped companies just looking to make their next payroll run, this approach simply does not scale, and creates downstream problems that compound and get worse over time. High velocity within the engineering team is often less a function of what a company agrees to build, but is more a function of what a company declines to build. If a company’s strategy and focus aren’t crystal clear, the question of what to build and what not to build will be endlessly debated, and time spent building product A is, by definition, time not spent building product B.

3. Workflow or Process Problems: An engineering team that is sufficiently large can still have problems producing code that is on-time, within scope, and with suitable quality if the processes that they follow to actually do the work are inefficient. For this reason (among others), we’ve seen “waterfall” style development give way to agile development. We’ve seen large, stand-alone development and product management teams give way to small “pods”, which are small teams that feature a smaller number of developers, product managers, and QA engineers, each with a very specific focus. We’ve seen manual quality assurance give way to automated QA tools. In each instance, the exact same number of people are far more productive under the new paradigm than the old one.   

It’s Much Easier to Add Than it is to Take Away

The reality that it’s much easier to add than it is to take away is one observation that seemed to permeate almost every aspect of my life as a CEO. If you don’t believe me, compare the positive momentum created by a hiring spree with the negative momentum created by initiating layoffs. Compare the reaction to adding enhanced employee health benefits with the reaction to their removal (in each case, the latter dramatically outweighs for former). And, to produce what is sure to be a particularly memorable example, see what happens when you try to reduce the commission rate that you had previously paid to a salesperson. Not fun.

Though it’s easy to add new developers when circumstances are favorable, as with any hire one must appreciate the extent of the fixed costs that are being added to the business, and at least entertain the possibility that at some point in the future, the revenue profile of the company may no longer be able to support those fixed costs. Though I suppose one could use this as justification to not make any new hires (something that I’m obviously not advocating for), CEOs would at least be wise to remember that the negative impact of subtracting from the team will likely outweigh the positive impact of adding to it. For this reason, CEOs should be thoughtful about when (and by how much) to add team members, especially if it’s in the pursuit of shorter-term goals.

It’s a Hard Hire to Quantify

As I explain in further detail in another blog post, The CEO as Chief Capital Allocator, if you’re a CEO, then you’re also your company’s Chief Investment Officer, whether you know it or not. This is because any time that you spend a material amount of money on anything (in this case, on new hires), you are making an investment decision. And as with any investment decision, the goal should be to maximize your risk-adjusted rate of return relative to other potential uses of that money.

In my experience, hiring a new developer was much harder to quantify than, say, hiring a new sales person (in the latter case, they either paid for their salaries with new revenue, or they didn’t). Though the cost of hiring a new developer is simple enough to understand, managers often struggle to assign quantifiable benefits to these hires, and (potentially as a result) usually opt for more qualitative justifications like “our current team is too swamped”. Though qualitative considerations like these shouldn’t be ignored, in and of themselves they represent insufficient rationale to justify a major investment like that of assuming a new salary. Remember, because of Parkinson’s Law above, your team will likely always be swamped.

How to Think About “Hiring ROI”

Instead of hiring a software engineer because you have more good ideas than engineers to build them, ask yourself: What am I going to get in return for the salary that I’m paying this person? Will we bring product X to market faster? If so, how much incremental money will that yield relative to the salary that I’m being asked to pay? Will we have enough bandwidth to finally add feature Y? If so, how much incremental revenue will that create, and how does that compare to the salary that I’m being asked to pay? Will we finally build feature Z for our largest customer who is threatening to leave for a competitor if we don’t? If so, how much lost revenue will that save for us, and how does that compare to the proposed salary? And so on.

These aren’t easy questions for many CEOs to answer, so they often don’t answer them at all, and instead point to many of the problems that we’ve already discussed as the required justification for the hire. So, yes, perhaps the addition of an engineer will help your team move 10% faster, but how much is this increased speed worth to your company? At the very least, it should meet or exceed that new engineer’s fully-loaded annual cost.

Once you’re able to quantify (or more likely estimate) the potential return of an engineering hire, CEOs should then compare that ROI to other potential uses of that same capital. For example: A 10% rate of return on a $500K investment in a larger engineering team may sound attractive on the surface, but it may not necessarily be so if that same amount of capital can be used to pay back venture debt currently accruing interest at a rate of 15% per year (all else being equal).

But Leave Room for Qualitative Considerations

Though this may sound somewhat contradictory to most of what I’ve said above, it’s important to recognize that not everything that’s important needs to be quantified, and not everything that can be quantified is important.

For example: Though adding engineering capacity to build a new product may yield an attractive return on your money, you may instead choose to invest those same resources in fixing the shaky back-end architecture of your existing platform (an investment of time and money that is harder to quantify and is less likely to yield incremental revenue, if any) if the new customers that you would have acquired through the release of that new product would crash your entire system.

In Sum

Substantially every software CEO of whom I’m aware is relentlessly pursuing growth, progress, and success, and it can be very tempting for them to attempt to “hire away” their problems, particularly in the form of bringing on new engineers. In my experience, this is the biggest temptation of the typical software CEO, perhaps because the solution to so many complex problems seems so easy.  

Though it should go without saying that engineering teams can and do (and should) grow for very good reasons, it remains important for CEOs to be thoughtful when making these hires, largely in recognition of the realities that: i) Communication channels grow non-linearly as team size increases; ii) Work expands to fill the time allotted for its completion; iii) The development team will never be big enough; iv) One unit of additional capacity often doesn’t produce a unit of additional output; v) When CEOs add more developers, they’re often attempting to solve the wrong problem; vi) It’s much easier to add than it is to take away; and vii) Hiring engineers can be a very difficult hire to quantify.