
When to bring in the heavy hitters (2017) - mooreds
https://mfbt.ca/when-you-should-bring-in-the-heavy-hitters-947f35cb96e6
======
tc
There's only one real answer. It's when you're ready to be a big company. But
not just because you _want_ to be a big company.

Heavy hitters (i.e. former executives of big companies) bring big company
expectations. They expect to hire a big team. They expect that your product is
ready to scale, and in B2B, ready to be packaged and sold down a channel. They
expect that you know how to sell your product in a repeatable way, a way they
can copy, optimize, and teach to new hires. They expect to move at a big
company pace, and expect you have some semblance of big company processes.

These people, in general, do not know how to, and do not want to, live the
kind of startup life you've been living -- the hours, the apparent chaos, the
extreme frugality, the wearing of many hats. They won't love your product like
you do. This will be a job for them.

Remember that they're almost always from big companies, but much less often
did they help build those companies at the critical juncture -- the time
before everything was working. The time before it was clear the company would
succeed if it could just expand on what it was already doing.

These heavy hitters mostly expect that your company already works,
fundamentally, and that you're hiring them to do more of it. If that doesn't
sound like your company, you're not ready yet.

And if you hire these folks before you're ready, it will probably destroy the
company. It's a one-way function. By their nature, they'll drive out your
early hires and scale your costs. If your revenues don't scale comparably --
because you didn't actually have product/market fit -- then those heavy
hitters and the teams they brought on will leave when they see the writing on
the wall. Leaving you, alone, back at zero.

~~~
bjelkeman-again
I have seen that happen with a $100 million s/w company. It was very
depressing. Not only where the people they brought in thinking of themselves
as “heavy hitters”. They where also poor at their jobs. They wouldn’t have
done particularly well even if the company was ready to scale. That of course
didn’t help. It was sad.

~~~
dexterdog
Those were not heavy hitters then. They just convinced the board that they
were. I've worked with many of these people. They are terrible.

~~~
yourapostasy
What kind of people would you search for to retain to help sniff out red flags
the board might miss in situations like this? I know that it’s in the board’s
job description, but who can you hire as a sanity check for such a big
decision?

~~~
ggg9990
Someone who has done it before at slightly smaller scale. To grow a business
from $50m to $200m in five years hire someone who grew a division from $10m to
$50m in five years, ideally at a company where not every division grew at that
rate.

------
SomeCallMeTim
I think you need senior _technology_ people from day one, if you want to build
to scale, and you don't really want to pay to build everything twice _and_ pay
for extreme server costs _and_ pay to migrate from the old to the new system.

Maybe this means something different than "Heavy Hitters". I've never run a
huge company division; I prefer to work in a startup environment, and except
for a short stint at Amazon, that's where I've stayed. But I have been able to
step into small companies as an interim CTO and turn their technology from a
mess that won't scale and that was written by junior developers into something
that will scale cleanly from day one.

And I typically do this by throwing away most of what was there to begin with
and rebuilding from the ground up. Most junior devs just don't have good
architecture and design in their blood like a strong senior developer. Which
means there's 2-3x extra work to prevent the current system from dying or
failing during the transition process ("Changing the tires while driving at
60MPH").

If instead you have someone like me drive the project from the start, when the
project is _finally_ seeing traction you can focus on adding features your
customers are demanding and pivoting if necessary. And you don't end up
hemorrhaging money by paying for 50x as many servers as you would need if
you'd start with a strong architecture.

And the funny thing? Hiring a strong dev early on will likely get you to a
working product much sooner than several junior devs, and you overall save
money due to launching sooner. So it's a huge win. And a lot of the time,
founders _are_ junior devs (I've been coding for 30 years; anyone with less
than five years is junior, from where I sit, and a decade is bare minimum to
be "senior").

But everyone wants to cut costs and hire the $10/hour developers, or the green
developers fresh out of college. And now articles like this are being written
that imply that you shouldn't even hire a "heavy hitter" until some vague
criteria have occurred...

Well, good luck with that. You might be able to pivot and improve your
technology in time. Or you might end up going the way of Friendster, pissing
off your user base because your site keeps failing, and by the time you have
it working reliably, they've all left. [1] Or maybe the fact that they left
allowed it to work reliably? Hard to say.

[1]
[https://en.wikipedia.org/wiki/Friendster](https://en.wikipedia.org/wiki/Friendster)

~~~
SimbaOnSteroids
As a sub-junior developer, how does one go about architecturing software to
scale?

~~~
jaggederest
Part is just experience. You have to have seen enough different kinds of
people and systems work together to understand what works and what does not.

I think another part is simply nomenclature. There's a joke about the only two
hard problems in computer science: Cache expiry and naming things. It's a joke
because cache expiry reduces to naming the keys correctly if you do it right.

Basically, if the different parts of the system don't have sensible names that
represent what they actually do (and that there are, indeed, different parts
of the system), then there's an architecture problem.

You have to have an effective metaphor for the way that you want the system to
work, and the problems you want each part of it to solve, or nobody will be
able to understand the entire thing.

I run into this often. People have a functional but struggling system designed
with the "big ball of mud" pattern, where you just keep slapping gobs of code
onto it until it does what you need, and then they want someone to come in and
"do architecture" at it. This predictably fails.

So, there's your heuristic: if it has good names, and the pieces do what they
say on the tin, you're on the right path. When something starts to have
responsibilities that aren't under that name, you should move those
responsibilities somewhere else and name them appropriately.

Edit: There's also a second-order level where you start to recognize the way
that cross-cutting concerns happen in different areas and design a piece of
the system to handle that concern in an organized way. You can probably think
of a bunch yourself, but an easy example you want to handle earlier rather
than later is logging, and another significant one is authentication

~~~
SimbaOnSteroids
So a the goal is a bunch of people can have their claws in the code base and
avoid this reaction [0], but not necessarily code optimization, just as long
as everything is highly modular and works independently of other parts you're
kosher.

[0]
[https://www.youtube.com/watch?v=BGpDGJoe6P0](https://www.youtube.com/watch?v=BGpDGJoe6P0)

~~~
jaggederest
Right, the lower level stuff you're still looking for (cleanly designed
classes and methods, good testing, etc), but you can hit all those micro-level
targets without having any architecture to speak of.

(the "pile of classes" design pattern, where everything calls everything else
and there's no hierarchy or anisotropy to it)

The other heuristic, besides "names make sense", is ease of modification. When
you come back into an area of the system, how painful is it to disentangle
that piece from the rest and make a significant change? Is the functioning of
the entire system tied together tightly enough to make that difficult? Are
there good patterns to extend, or is every change invented from scratch?

------
araes
Reading this article I feel like I just got done talking to a C-.

Grand words with strong advice, but at the end I'm not sure if the topic point
"when C-level?" is any more clear in my head.

I apparently need to be:

\- Tired, but not so tired I can't survive the C- interviews

\- Willing to delegate, but know what stuff is OK to let go

\- Honest

Yet these seem more like qualities I just need in hiring. I'm tired of, or not
good at, doing X job. I'm OK with not personally doing X. I tell the truth and
expect new hire doing X to give it back. If all 3: hire someone for job X.

The main version for C- still seems to be, "the VCs are becoming a huge thorn
in my side" whether I admit they have a point or I just want them to calm
down.

Perhaps I'm just far too cynical about C- value these days. "We're strongly
pushing to accelerate our core strengths and metrics while increasing overall
investor value."

~~~
ExactoKnight
We should get rid of this whole "C-" idea anyways. Comes from rigid social
ideas about how to organize companies, that tends to push down the importance
of product and technology roles in favour of giving more social power to roles
that in practice actually contribute way less.

~~~
jadedhacker
"Efficiency in Employee-Owned Enterprises An Econometric Case Study of
Mondragon"

[http://journals.sagepub.com/doi/10.1177/0019793914564966](http://journals.sagepub.com/doi/10.1177/0019793914564966)

Just read this and it was pretty interesting. Appearently in the studied group
of organizations, coops are about as efficient as capitalist businesses but
without lay offs and extreme inequality. There was some lower job satisfaction
possibly due to higher expectations. There was a small efficiency benefit in
some customer service oriented organizations.

Try sci-hub if you don't have institutional access. ;)

~~~
e_b
Mondragon is run as a normal corporation, mostly. It's just named differently.

~~~
jadedhacker
Can you elaborate? Some of that is treated in the linked article. They do
comparisons between the coop, limited coop, and conventional portions of their
sporting goods and supermarket chains.

------
ChuckMcM
Interesting essay. I really resonate with the honesty point, when the CEO
especially has honesty issues the whole enterprise can go to hell in fairly
short order.

I have also been in these conversations where really it's the investors who
want someone "with experience with these things" and the founding staff is
being cajoled along. A couple of times this worked out to an advisory role at
the board level. It lets the founder get advice without feeling compelled to
take it, and it lets the board feel like they have access to another point of
view that might let them see things they are missing.

The key though is that the executive team has to internalize that _they_ and
not their engineers or sales or marketing people are holding back the company.
That can be tough, especially if your CEO is short on self awareness.

------
oillio
If you like this post, the rest of the blog is really good:
[https://mfbt.ca](https://mfbt.ca)

A lot of insightful gems on how to be better at leading in tech.

Also, their new book:
[https://www.amazon.com/dp/0995964300](https://www.amazon.com/dp/0995964300)

------
ExactoKnight
Sorry, but I couldn't take a single actionable thing from that long rant...
Lots of really mushy sentiment instead..

------
rwallace
'Bring in the heavy hitters' strikes me as an odd way to phrase 'the investors
have decided to take your company away from you and put someone else in charge
who may or may not understand the business'.

Surely the correct way to react to that is to start by asking what you've done
wrong, and whether you can fix it? If the investors are just being assholes
for the sake of it, you've got a fight on your hands, but hopefully that's not
the typical case.

Unless it's a case where you don't want to run a big company? But the article
didn't seem to be talking about that.

