More Engineers Is Not The Solution
Illustrations by Shaun Miller

More Engineers Is Not The Solution


Since time immemorial, when a CEO asks a PM at Product Review, “what do you need to 10X users/revenue?”, “what will make you go faster?”, etc.

The PM steadfastly responds “We need [N] more engineers”.

The Eng Manager nods approvingly.

A story, with some hard truths to swallow:

“More engineers” will usually not solve your problems. Because the real problem is often a strategy problem, culture problem, interpersonal problem, trust problem, creativity problem, or market problem. More engineers will solve your “I don’t have enough engineers” problem.

When you finally manage to get more eng headcount, things will usually get worse before they get better. Management will now expect your team’s immediate output to be in proportion with this new headcount, not with your current staffing. Not fair, but such is life in product

So your “I don’t have enough engineers” problem is now a hiring problem. Thank goodness you’re not the one chiefly responsible for hiring 10 more engineers. But your Eng Mgr counterpart is. This means s/he will be (rightly) focused on that. The team’s output will usually suffer.

Whereas you previously had a “I don’t have enough engineers” problem, now you have 3 problems:

1) a hiring problem

2) a near-term output & outcomes problem (you have OKRs to hit for goodness’ sakes)

3) you still don’t actually have enough engineers (!)

In the midst of all the exec reviews & hiring activity, your team couldn’t even begin 2 of your high-pri (P0) OKRs (with just 6 weeks left in Q3!)

You huddle with your Eng Mgr counterpart & (reluctantly) decide to put that P1 reliability project on pause, to staff those P0 OKRs.

Yikes, you now have a seventh problem:

7) an optics problem

You wanted to do the right thing for the company, but you decide it isn’t worth the personal risk.

You need to strike a balance.

So you organize an OKR review with your Eng, Design, Data Science, etc. counterparts.

You say:

“We clearly can’t launch some of the feature improvements we had envisioned in Q3. But remember, our OKRs were framed in terms of metrics to move, not in terms of launches (yay us!)

So let’s brainstorm on ways to still hit these metrics before EOQ, some quick wins.”

Your Design & Data Science counterparts propose an idea:

“Remember that experiment in Q1 that increased sign ups by 18%, but we didn’t launch it because of higher churn in that cohort? We can revive it”

Eng Mgr:

“Ah, it can be turned back on with a flag. Can launch next week”

You think to yourself:

<“Hmm… we did see a nice bump in sign ups but I talked to a few of those users and they said that they didn’t actually intend to create an account.

that experiment also isn’t aligned with the sign up flow changes we’ve envisioned for next year.”>

But you say:

“Great idea! That experiment uncovered some quality issues, but lets launch it now & we will identify & fix those issues in Q4. In fact, I’ll make a note to myself to make sure that we add a few follow up quality improvement experiments to our Q4 OKRs”

Decision made!

Fast forward to the promo cycle in early Q4, the promotion committee has a rigorous discussion esp. about the metrics your team moved in Q3. It’s a metrics-driven culture after all! Not everyone agrees, but your promo packet looked very good overall, so you’re now a Sr. PM.

You are ecstatic about the promotion, but now you have another problem: 8) your current product scope on this team is now too small for a Sr. PM. And this is bad because how will you get to GPM with this scope.

So you discuss this with your manager in your next 1:1.

And the decision gets made: you will work on a different product with larger scope because the Sr. PM for that product has just left your company to go to OpenAI (of course).

You say goodbye to your old product team. They say they will miss you. You will miss them too.

You diligently ramp up, and after a few more weeks, are nervous (but well prepared) for a Product Review for your new product’s 2025-26 roadmap with the CEO.

You monte carlo the scenarios, the questions, the pushback.

You get pre-aligned with your Eng/Design/…. counterparts, and stakeholders etc.

And then, 35 minutes into this Product Review, the CEO says:

“This plan looks really good.

Thank you for sharing it.

I have just one question.

What will make you go even faster in 2025?”

You briefly glance at your Engineering counterpart.

You smile.

And you hear yourself confidently saying to the CEO:

“We need [N] more engineers”

My dear PM friend, you have arrived back to the top of this very article:



Credits: Huge thanks to Shaun M. for the awesome illustrations. It is always a pleasure to collab with Shaun 🫡


Natalie White

Principal Enterprise Solutions Architect - Technical Therapist - Builder - DevOps Cultural Transformation

1w

This is the plot of “The Mythical Man-Month,” which was published in the 1970’s, and is just as accurate today as it was then. 

Like
Reply

Too many chefs can spoil the broth Shreyas Doshi

Like
Reply
Garrett Kocher

Technical Product Manager

1w

I received this advice early on from a highly talented and thoughtful leader. He had the patience to step me through the hypothetical scenarios and allowed me to realize that hiring more engineers might result in more code eventually, and in all cases there would still be an engineering shortage. However in very few cases was there actual, meaningful growth. This is a great illustration of one way it can fail. Thanks for the reminder.

Like
Reply
Jawahar Malhotra, PhD

Coaching the journey towards product and engineering excellence. Honored to be back at Yahoo leading the amazing Y! Finance technology organization.

2w

Fully agree! If you are digging a well at the wrong spot, adding more people, digging faster, won’t get you anywhere. Take a step back and find the right spot.

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics