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.
To become a senior executive at a large company you have no choice but to stop doing real work and devote your time 100% to internal politics, because you are competing for a limited number of promotions with people who will do that. The real work skills of a “heavy hitter” atrophied long ago... and all the politics of their former employer won’t help them in their new job unless they can import all their cronies too... basically there is NO reason to ever hire one of these types.
Yes, that's basically the same as having a lot of cronies. But alas the market is what it is, it pays off to sometimes hire one of these. (Look how Google hired their CFO a few years ago.)
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.
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?
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.
Was it a company valued at $100M, or a company generating $100M in revenue? My guess would be the former - usually if the founding team has figured out how to reach $100M revenue, they're smart enough to avoid hiring the kinds of idiots you're describing.
At $100M valuation however, it happens all the time. I've seen it happen too, and it's very sad to watch.
$100M valuation means ”we have four founders with PhDs from MIT, and our product uses both blockchain and ML”. Valuations are almost meaningless nowadays, with liquidation preferences and other tricks.
This. Random useless blockchain projects have valuations in billions on paper these days. The only think that matters is how much revenue your company is doing, valuations are completely random based on buzzwords these days.
One of you is saying that valuations are meaningless because companies will accept punishing terms in exchange for a face-saving valuation. The other is saying that valuations are meaningless because investors are dumb and will throw money at buzzwords.
So which is it? Are valuations meaningless because it's too hard to raise money, or too easy?
And as a follow-up question: how does this contribute to the conversation about "heavy hitters"?
The company made $100M/Year in revenue. Unfortunately I think the founders felt they where in over their heads or got bored and where convinced to take on a new CEO. I met him, he was clearly not a good choice in my view. I have no idea how he was selected. He brought in people from his old company. It was downhill from there.
This is a really good summary of how it tends to play out in the real world.
In particular it is the readiness aspect. When time has come to actually think like a business, and be less of a passionate founder of your own little baby.
Lastly, on the last point, I'd offer a slightly different pov in that these people will drive out cost that you might have overlooked, or have some sort of personal opinion on. These people will be ruthless on empty costs and you need to be okay with that.
In your opinion, where are the guys who did help build other companies during critical junctures? Do all of them stay with the companies they've helped build? I'm sure they're senior level too, perhaps being described with the same keywords (and thus indistinguishable) from the "carry-on heavy-hitters" you described?
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.
Spot on and I just escaped a company that hired a junior dev as their lead. It was horrendous. I don't want to call out the junior to management because he has kids but he's really screwing up their product and they don't even realize it because they know nothing about technology
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
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.
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?
Some people just "get" software architecture and some don't.
Part of it is indeed experience, but another part of it is just being able to visualize the entire application (domain experience helps with this) and see it as a series of interconnected modules. Think of the parts individually and what downsides they have and than as a whole.
An example of this is if you have a module that does something very GPU heavy or very bandwidth heavy. On an architecture layer you want want to give it it's own server outside of the main server (in the case of a web app).
In terms of code you need to think about how some modules will need to be updated in the future (want to support multiple payment methods) - and also to think what modules need to be secure or performant. If two modules will always exist together they might be something you can couple if it saves you a large amount of developer time. But if they might be re-used in the future they need their own API's and no close coupling.
By working with people who know how to do it, and learning from them.
There aren't many shortcuts one can take in that area -- the big difference between junior and senior developers is that the senior developers have experienced what can go wrong, often learning from their own mistakes and the mistakes of their employers, so they are better able to make design/architecture decisions.
If you're a junior developer and you don't have good senior people to learn from in your job, it's time to start looking for another job.
The specifics are highly domain-dependent, but at a high level, you need to be able to identify every resource and process in your system, how those processes utilize (or should utilize) those resources, where the bottlenecks might be, and have a plan for how to resolve the bottlenecks given the capabilities of the resources and processes. That is, you need to be thinking at a level of system components, not code.
Unfortunately, most of the above knowledge isn't taught in schools and comes mostly from experience.
So if I'm someone who doesn't really have the patients or attention span to sit down and write lots of code, but I think I'm pretty good at figuring out what all needs to happen from a macro perspective.
An analogy would be I don't have the foggiest on how to play the violin, harp, or flute, but I know how they all need to play together to not sound like a train-wreck.
I don't know if I'm being extremely naive or if I'm actually going to turn out being better at system architecture than actual coding, or if that's even possible.
Is it possible to get good at software architecture without having a lot of personal experience with many subcomponents of said architecture? Sure.
Is it likely? Not at all. This area is even more experience-driven than other senior-orchestration-type roles in other fields, and most of those roles--even the literal example of an orchestra conductor/director you mentioned--very often start with someone with immense personal experience playing a lot of metaphorical "instruments". All the other people in this subthread saying "build things and see how they fail" are right--and you have to be intimately involved of the building of a lot of things to start to see the patterns and move closer to an architect role.
I wouldn't bet the farm on being able to conduct the orchestra without knowing how to play an instrument.
EDIT: I don't think parent should be downvoted. They're highlighting important distinctions and seeking advice early in their career. Just because y'all disagree with their approach doesn't mean their comments lack substance or are bad. And if you think the down arrow will teach some kind of "punishment" for having a disagreeable outlook . . . well, I hope you don't raise kids, 'cause that tends to backfire.
Thanks for the reply and the edit. And you're right, I'm just trying to figure things out before I get to place where the consequences are more real. I could have worded the original comment better, I think it came off as arrogant.
If I can find projects that are open source with public documentation of pain points would it be beneficial to read through their discussions etc, to get a sense of the issues these projects faced with scaling, with the goal being to glean some insight into what went wrong and maybe avoid common pitfalls and save myself time trying to reinvent the wheel.
Writing something that horribly fails to scale, then learning from your mistakes. :)
Seriously, though, come up with a hypothesis about how your system will scale, then devise an experiment to test the hypothesis. If the hypothesis fails, figure out why, fix it and repeat until you get the behavior you want.
The next important piece is monitoring and measuring the performance metrics important to you, then figure out how to change your architecture when the system grows enough to have new bottlenecks.
Having a good load test tool, for example, can be invaluable in learning how your system actually performs.
Nothing can replace many, many years of experience.
Some skill in general optimization-thinking is key. The ability to visualize how the entire system works is key. Aptitude for API and general architectural design is key.
And even when you get it all right, _something will fail._ At which point profiling and having the right metrics in place so you can see what's failing is key.
Mess with stuff in your free time. Most of the time people won't want to hire you to lead implementation/designing things unless you have experience doing it which can be a pretty nasty catch-22. Having some side projects side steps that and puts you ahead of a lot of your peers.
Also have a clear sense of direction of where you want to be going and what you want to be doing. Without that management and mentors won't know how to push you along and might come to expect you to remain in the same position for longer than you expect to.
I'm not actually really suited for programming but I love tech and problem solving, like I do write stuff in my free time, I just take forever to get anything done. I've taken up going to as many hackathons as I can, I've attended 2 this semester and know of at least 2 more I'm going to be at. However when I'm at these things I rarely find myself writing any actual code and more of just making sure everyone is on task and finding resources for everyone to leverage. I find myself acting as a project manager most of the time. I don't know how that's going to look to an employer, but the teams I'm on build stuff that apparently the judges like.
Idk if these events count towards experience, but I feel like I'm getting better and better at getting people to the end goal.
Those are really valuable skills too. There is a slant for engineering here since the site is for, by, of engineers. I recently joined a new team and we have a totally kick-ass technical product manager we work with pretty heavily. He is an absolute boon to the team when it comes to interfacing with different parts of management and being able to walk to the talk of the specifics of certain technologies.
For your last point, I'd be cognizant of being able to measure your value objectively somehow. It can be easy to get left behind if the value you provided didn't get tracked because people were only paying attention to lines of code.
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."
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.
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. ;)
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.
Yeah plus following a few links to his other posts, the guy rants about arrogant jerks while constantly using arrogant jerkish language. It seems like a lot of his criticism might be projection.
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.
'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.
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.