A human can only hold so much in their head at once, and it’s less than you think. Yes, even that one. Yes, even you.
I recently hired a 30-year software veteran. While he was onboarding, he highlighted something I’d done naturally but hadn’t yet articulated as a strategy: I’d built my small engineering team as stakeholders rather than generalists. Most small (under 10) software engineering teams tend to hire senior generalists — folks who can wear many hats and move around as needs dictate.
Generalists solve many early business problems:
- Unpredictable work loads
- Quickly changing priorities
- Flexibility in technology choices
- Maximum redundancy in case of churn
- Low documentation requirements
But… you know what else solves those early business problems? Experienced, skilled management. I believe we hire generalists primarily not because they create maximum efficiency & velocity, but rather to compensate for what we’re not very good at in software: managing humans.
Did you also notice those are all hedges against fears? By imagining failure modes and prioritizing avoidance, you ironically make the team more fragile and likely to fail. In that mindset, you can’t make anyone load-bearing so you can afford to lose them. You need a top-down solution ready if that happens because it would be unseemly to ask the team for help & guidance.
What if you imagined a best case scenario for your team and methodically built in that direction instead? Some people find pride in believing they know more about an issue than anyone else. I find it rather terrifyingly isolating. I’d much rather prioritize hiring people to find challenges I hadn’t considered and offer as many perspectives as possible, so I gain visibility and can make better informed choices. That is a far stronger position than a facade of infallibility.
Here’s what a particular team of stakeholders looked like for our content-driven SaaS product, in order of hiring:
- Principal backend / full-stack (product engineer #1)
- Senior integrations engineer
- Senior frontend / full-stack engineer
- Accessibility & UX engineer
- QA automation engineer
- Data engineer
- Staff backend engineer
As my colleague noted, these are much more specific job titles than you’ll find in most small engineering teams. The only broad technical redundancy on the team were myself & the principal (together also coordinating outsourced devops, security reviews, & compliance work). However, everyone else had strategic overlap with at least two other engineers on the team. This meant anyone leaving for a 2-week vacation wouldn’t cause everything to grind to a halt with reasonable planning. It also meant they had folks to collaborate with so they don’t operate in a silo.
Employing stakeholders solves many overlapping problems:
- Reliable advocacy for core business value creates better communication
- Culturally centering negotiation creates more complete solutions
- Empowering employees creates invaluable intrinsic motivation
- Fostering initiative to fix process prevents accepting it as a constraint
- Clarity in who has vested interest in a decision removes bottlenecks
- Reduced context shifting improves individual impact & efficiency
- Decentralizing authority fosters leadership at all levels of the organization
I could write an essay on each of those points and likely find even more, but what’s most interesting is the emergent behavior this strategy enables.
Would you have guessed that the person who picked up most QA when that engineer was on vacation was the Accessibility & UX engineer? Or, that the senior frontend / full-stack engineer became the anchor of new feature development? Or, that the data engineer would embed themself in Customer Success meetings for a month to help them get the most value from their tools? I didn’t, and I hired most of them. But I did know the core tenant of the model: Hiring stakeholders creates business-changing opportunities you cannot predict because trust fundamentally changes the entire team dynamic.
If you must maximize top-down responsiveness to impulsive executive control, you will never see those opportunities. When customer budgets contract and funding tightens, those opportunities become the difference between success & failure.