There are two types of engineers. Be both

A while back I listened to this talk. It's by Michael Lopp-- an engineering head who worked at companies like Netscape, Apple, Pinterest, and now works as Engineering VP for Slack. Pretty bright guy. At any rate, in his talk, he broke engineers into two basic archetypes: the stables and the volatiles.

Stables-- the Vogons

He gave a description of stables as follows:

• Happily work with direction
• Appreciate that there appears to be a plan
• Like schedules
• Play nice with others
• Value efficiently run no-drama teams
• Calmly assess risk
• Carefully work to mitigate failure (however distant or improbable it might be)
• Tend to generate process because the know process creates predictability and measurability

If I were to give a caricature of this type, it would be the Vogons from Hitchhiker's Guide to the Galaxy.

Volatiles-- the cowboys

And here's how he described volatiles:

• Prefer to define strategy rather than follow it
• Cannot conceive of failing
• Find thrill in risk
• Often don't build predictable or stable things, but they sure build a lot
• Often are only reliable if it's in their interest
• See working with others as time-consuming and onerous
• Prefer to work in small, autonomous teams
• Could care less how you feel

Think of Mark Zuckerberg's old mantra, "Move fast and break things." The term Ive heard most often in the industry to describe volatiles is "cowboy developers."

The inevitable conflict

With such differences in ways of thinking, there's bound to be conflict. Lopp points out that stables and volatiles really do hate each other. "Volatiles see stables as slow, lazy, and political bureaucrats." I think of Stables on the other hand "see volatiles as holding nothing sacred, do whatever the *^#! they want." Both are invariably chafing under the burden of having to work with the other.

But Lopp points out that "this conflict is a good thing."

Don't be overrun by one side. You need both

Lopp pointed out that startups usually start out with just a handful of volatiles-- quick-thinking innovators who can crank out a working 1.0 product really, really fast. They do the absurd, achieve the impossible, and blow everyone away with new ideas. But once the company starts gaining traction, these volatiles who poured their lives into the 1.0 turn into stables. When a new hotshot comes in and want to start pruning and building the next dangerous, amazing thing, the old stables push back and protect their well-running product from disruption from the new generation of volatiles.

"This," he said, "is how companies die." They transition fully from volatiles into stables. They start defending the well-running, reliable product from disruption from haphazard "innovation" by a new generation of volatiles. Newly hired volatiles join but quickly leave. They feel weighed down by the rigamarole. They smell the death and stagnation. This is what happened with Apple years back. it's why Steve Jobs was brought back on-- because he never became a stable. He always remained a volatile, and because of that, he saved a dying company.

It is critical to make sure volatiles and stables both feel comfortable and at home in your company. Without volatiles nothing exciting or new happens, and without stables, nothing stays working long enough to build a business. "Volatiles," he said, "are there to remind you that nothing lasts. They consider it their mission in life to replace that which is inefficient, boring, uninspiring." You need that. "Stables," he added, "are there to remind you of reality and to define processes. They bring predictability, credibility, and repeatability to your execution." You need that, too, and in equal representation once you reach scale. The challenge for companies, he said, "is to "create a world where [volatiles] can disrupt, and everyone is clear about the value of their disruption," with an equal appreciation for stables and volatiles for "the other side of the fence."

The best company has both. The best developer is both

Lopp presents the archetype of the stable and volatile developers as a spectrum, with most engineers tending towards one side or the other, some few finding a balance in the middle. I would, however, disagree a bit with this. The best developers I have worked with have not been just "in between" the two extremes-- they have been both at the same time. Volatiles don't look at them and see a good dev who's a bit too process-heavy, and stables don't see a restrained cowboy. They fit all the good qualities of both archetypes at once and fully. They are bold, brave, and willing to do something crazy and new. But they also maintain a healthy respect for the product and the cash cow that got them this far. They innovate, but they innovate smart.

I'm still trying to figure out which archetype I fit best in this "developer personality test." Early on, my coworkers would have probably, nay, definitely say I was out leading the camp of volatile cowboys. But over time, I feel I have definitely started gravitating away from that a bit. And when there's a rushed project, a changing deadline, or no time to put due diligence into unit testing, design, and refactoring, I find myself pulling back on the reins and balking at the breakneck speed that ecommerce development requires. Maybe I'm moving towards center. But better if I was becoming both.

So, where do you stand?

---

This post first appeared on Another Dev Blog