When to bring in the heavy hitters (2017)
mfbt.ca
mfbt.ca
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.
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.
At $100M valuation however, it happens all the time. I've seen it happen too, and it's very sad to watch.
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"?
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.)
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.
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
(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?
Huh? Neither part of that is true.
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.
Unfortunately, most of the above knowledge isn't taught in schools and comes mostly from experience.
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 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.
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.
[1] https://ocw.mit.edu/courses/electrical-engineering-and-compu...
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.
Idk if these events count towards experience, but I feel like I'm getting better and better at getting people to the end goal.
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.
The system architecture really isn’t part of the project manager’s role. Leave that to the programmers.
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.
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.
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.
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."
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. ;)
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.
A lot of insightful gems on how to be better at leading in tech.
Also, their new book: https://www.amazon.com/dp/0995964300
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.