In every engineering organization, there are archetypes that define the culture and the velocity of the team. We often talk about "10x engineers" or "ninjas," but those terms are outdated and unhelpful.
Instead, I prefer to look at engineers through the lens of momentum. Specifically, the dynamic between two distinct types of senior contributors: the Accelerator and the Brake.
Both are highly skilled. Both want the company to succeed. But depending on the maturity of your company, one will save you, and the other might just kill you.
The Archetypes
The Accelerator
The Accelerator is the engineer who intuitively understands the "Time Value of Shipping." They are technically excellent, but their superpower is pragmatism. They improve the output of the entire team, not just by writing code faster, but by unblocking others, making quick decisions on trade-offs, and keeping the bar for quality high—but appropriate.
They ask: "What is the minimum viable architecture we need to solve this user problem right now?"
The Brake
The Brake is an equally knowledgeable engineer. They often have a deep understanding of computer science, distributed systems, and "The Right Way™" to do things. However, the Brake slows the team down by demanding a level of technical rigour that is disconnected from the reality of the product's stage.
They ask: "How will this architecture scale to 10 million concurrent users?" (Even though the product currently has 100 users and might pivot next month).
The Impact on Morale
The interplay between these two archetypes has a profound effect on team morale.
When a team is led by an Accelerator, morale is usually high. Engineers love to ship. There is a dopamine hit associated with merging a PR and seeing a feature go live. The Accelerator facilitates this flow state. They create an environment where progress is visible and constant.
Conversely, working under a Brake can be demoralizing. The Brake often disguises their obstructionism as "mentorship" or "standards." Code reviews become philosophical debates about abstractions that don't yet exist. Simple features get bogged down in weeks of RFCs (Request for Comments). The team feels like they are wading through treacle.
For a junior or mid-level engineer, the Brake is terrifying. They make you feel like your code is never good enough, not because it's buggy, but because it isn't "pure."
The Lifecycle Paradox: Startup vs. Scale-up
Here is the nuance: You need both. You just need them at different times.
Phase 1: The Startup (The Era of the Accelerator)
In the early stages, the Accelerator is the most valuable asset you have. You are fighting for survival. You need to find product-market fit. If you spend three months building a Kubernetes cluster for a product nobody wants, you go out of business.
In this phase, the Brake is a liability. They will optimize you into bankruptcy.
Phase 2: The Scale-up (The Rise of the Brake)
As the company finds traction and matures, the ground shifts. You have paying customers, SLAs to meet, and technical debt that is starting to accrue interest.
Suddenly, "moving fast and breaking things" isn't a strategy; it's a risk. This is where the Brake becomes essential. They are the ones who spot the concurrency bug that will take down the site on Black Friday. They are the ones who insist on better observability.
This brings us to a critical organizational weakness observed in many growing tech companies.
As a company transitions from Startup to Scale-up, management starts to get nervous. They become risk-averse. They stop celebrating "speed" and start celebrating "stability."
In this environment, the Brake often gets promoted.
Why? Because the Brake sounds "serious." They sound like the adults in the room. When they say, "We can't do X because of Y risks," executives nod. It sounds like wisdom. Meanwhile, the Accelerator, who is saying, "We can build this in a week," starts to sound reckless to a risk-averse management team.
This is a dangerous inflection point. If you promote the Brake to a position of leadership too early, or without checking their pragmatic impulses, they will institutionalize slowness. They will build processes designed to prevent failure, which inadvertently prevent success.
How to Manage the Dualities
Leadership requires recognizing which archetype you are dealing with and deploying them correctly.
Dealing with a Brake
If you have a Brake on your team, do not let them block the critical path of feature development, especially in early stages.
Realign to Infrastructure: Move them to Platform or SRE teams where their rigorous standards are a superpower, not a blocker.
The "Why" Test: Challenge their rigorous demands. Ask them to quantify the risk. If they can't prove that the lack of abstraction will hurt the business in the next 6 months, they are overruled.
Define "Good Enough": Set explicit coding standards that cap the level of complexity allowed for specific projects.
Further Leveraging an Accelerator
Accelerators are your momentum generators, but they risk burnout or creating a mess if left unchecked.
Give Autonomy: Give them hard, ambiguous problems that need to be solved yesterday. Get out of their way.
Pair with "Finishers": Accelerators are great at 0-to-1. Sometimes they get bored at the 90% mark. Pair them with engineers who love polish and maintenance.
The "Clean-up" Tax: Ensure the Accelerator knows that if they cut corners to ship fast, they are on the hook to pay down that debt later.
Conclusion
The tension between speed and rigour is the heartbeat of engineering.
We shouldn't vilify the Brake—they are often the reason we sleep at night during high-traffic events. But we must be incredibly wary of letting them set the pace of innovation when the company is still young.
Recognise your Accelerators. Protect them from unnecessary bureaucracy. And be careful who you promote when the company starts to grow up. You don't want to accidentally pull the handbrake just as you're trying to merge onto the highway.
