I’m currently reading Managing Humans by Michael Lopp. He shares a collection of war stories in his book about engineering management with lessons learned from places like Apple and Netscape. It’s a great book if you want to dip your toes into people management and what it looks like.
I’m not a manager, but I’ve always been interested in the IC-MGR relationship and different management styles (especially having worked with 7 managers so far in my career).
One of the early chapters that caught my attention was Stables and Volatiles. A chapter that talks about two opposite types of engineers and why having them constantly arguing (with an eventual peace treaty) is a positive sign of strong engineering culture. I’ve worked with stables and volatiles (and admittedly been both), and I’ll share why learning this form of conflict resolution is useful for all engineers.
What are Stables and Volatiles
Lopp introduced two groups of engineers he used to manage working across different organisations, stables and volatiles. He shared the pros and cons of each one and when/where they best thrive in the business.
Stables are the engineers who keep-the-lights-on (KTLO). They are process-oriented individuals who value predictability and doing things right at the cost of speed. They enjoy working in a system: requesting access to services/tools, weekly design reviews, and building artifacts from templates (like JIRA tickets).
Lopp described them as engineers who:
Happily work with direction and appreciate well-defined plan and schedule.
Play nice with others because they value an efficiently-run team.
Calmly assess risk and carefully work to mitigate failure, however distant or improbable it might be.
Tend to generate a lot of process because they know process creates predictability and measurability.
Volatiles are the opposite. They move fast, challenge everything, and get things done at the cost of stability. They can be viewed as cowboys compared to stables.
Lopp described them as engineers who:
Prefer to define strategy rather than follow it.
Have issues with authority and often have legitimate arguments for anarchy.
See working with others as time-consuming and onerous tasks, prefer to work in small, autonomous groups, and don’t give a shit how you feel.
Often don’t build particularly beautiful or stable things, but they sure do build a lot.
I’ve seen (and been) both archetypes at work. You might dislike one more than the other. However, these personas are common and exist for a reason. They are valuable to the business, just in different ways.
For example, companies with well-established product(s) and customer trust require standardised process for ensuring stability and predictability, which are often designed and operated by stables. They might want to launch a new feature or scale existing services, but they prefer to have it operated by stables.
On the flip side, companies that are innovation-driven (e.g., launching new products) and/or startups often require volatiles for making pivotal changes for the business. Volatiles can parachute in different organisations and help solve technical challenges to grow the business. Their methods might be chaotic, but they sure get things moving.
I worked on projects where I was a volatile. One of them because I had to do whatever it takes to get something tangible into customer’s hands in less than a month. In other projects, I operated as a stable because there are customers using our products and we owe them accountability (e.g., 99.99% uptime per service-level objective), even if new rollouts were relatively slow.
Engineers on both sides sometimes are unable to comprehend the value of the others’ positions. Sometimes decisions are viewed as right and wrong or good vs evil.
Lopp said the following:
Lastly and most importantly, these guys and gals hate — hate — each other. Volatiles believe Stables are fat, lazy, and bureaucratic. They believe Stables have become “The Man.” Meanwhile, Stables believe Volatiles hold nothing sacred and are doing whatever they please, company or product be damned. Bad news: everyone is right.
I agree. Some might think volatiles are reckless because they like to “move fast and break things”, but they also build innovations that define new markets. Others might think stables like to “play nice and follow the rules”, but they guarantee predictability and maintenance at scale.
Organisations need both for a sustainable long-term business.
Companies that stop innovating will stagnate and eventually die.
Companies that don’t stabilise will eventually fall under its own weight.
Businesses can expand in the market either vertically (new features to live products) or horizontally (launching new products). Both groups are valuable, depending on the direction. I believe it’s important to identify the types of challenges your company is facing, which will help you match with the right engineering profile (stable/volatile).
🗣️ From my experience, scaling vertically requires stables. Scaling horizontally requires volatiles.
Forming a peace treaty
Individuals who can form a peace treaty with volatiles and stables are great at conflict resolution. Because they see value in both of them sitting at the table.
One of the challenges I learned as a lead is to resist the temptation to referee between stables and volatiles. Sometimes great conflict resolution stories come from an epic battle between these two groups. I’ve been to many design meetings where both groups argued that the other proposal is “dumb” and went on to explain why. They weren’t completely right, but they did make some solid points.
Forming a peace treaty doesn’t mean merging them into a single archetype for conflict-avoidance. It’s about creating an environment where both can do their best work without disrupting each other.
That usually means a few things:
Giving volatiles the freedom to explore within the business scope. Could be translated into a series of spikes, prototypes, or time-boxed experiments. Allowing them to find opportunities and introduce an idea worth following.
Giving stables the freedom to own and define the “path to production”. In other words, designing the deployment/roll-out process, the production-ready checklist, and how documentation should look like.
The manager’s job (and sometimes the tech lead’s job) is to maintain the rhythm without picking sides.
Working with Volatiles
If you’re a stable working with a volatile, your instinct is to slow them down. Resist that. Instead, ask them to explain the problem they’re solving, not the solution they’ve already built. Volatiles often skip the “why” because they’re already three steps ahead. Pulling them back to the problem gives you common ground.
If you’re a manager or tech lead, give volatiles ownership of the ambiguous, high-risk problems. That’s where they thrive. Putting a volatile on a well-defined maintenance task is a recipe for them leaving or causing chaos out of boredom.
Working with Stables
If you’re a volatile working with a stable, your instinct is to dismiss them as slow. That’s a mistake. If you present a problem and invite them to solve it with you, they’ll add the guardrails you didn’t think of.
If you’re a manager or tech lead, don’t confuse a Stable’s calm with a lack of ambition. Many Stables want to grow but express it differently. They won’t pitch a radical rewrite. They’ll propose a migration plan with rollback steps. Over time you’ll notice in 1-1 meetings how stables and volatiles think. They won’t be thinking about the same things for sure. And that’s fine.
Conclusion
The longer you work in engineering, the more you realise that the person who frustrates you most is probably the archetype you’re not. Stables think volatiles are reckless. Volatiles think stables are slow. Both are right, and both are necessary.
The leadership skill isn’t picking a side. It’s knowing when the team needs speed and when it needs stability, and making sure both have room to operate.
Have you worked with volatiles and stables before? Let me know your thoughts below.