When an Engineer Goes “Rogue”
We’ve all encountered them: the developer who simply feels their path is the only path, and their drum beat is the only one to follow. In many cases these developers are very skilled and quite knowledgeable. You want to retain them but their unwillingness or inability to adopt a different approach threatens the integrity of the team or perhaps the organization.
As with anyone whose behavior is in opposition to what you or the organization would prefer, the most important question to ask is “Why is this person acting this way?” Only by understanding the “why” can a manager craft a solution to the situation.
Admittedly, the title of this post is a little misleading. It implies the Engineer transitioned to rogue behavior. More often than not, the engineer’s behavior has not changed, and is consistent with their prior behavior. It’s the company that’s changed and now the engineer’s “normal” behavior is inconsistent with the company’s new vision.
This often seems to be the case with start-ups, where the initial goals were to stay afloat, move fast, pivot as needed, and prove the business concept du jour. Thinking of the company as a small boat, there wasn’t much of the boat above the waterline. Wrong decisions, both by engineering and management, put holes in the hull, and the company took on water. Fast action to patch the holes was required. The engineer who came up with a fast solution, and had the determination to implement it quickly was hailed as a hero. It didn’t matter whether the patch was with bubble gum and baling wire, or a steel plate. Problem “fixed”: time to move on.
Now imagine your company was fortunate enough, through luck, brilliant planning or some combination of both, to actually prove a concept. Life looks promising and instead of struggling to get from Point A to B, now is the time to focus on moving from Point B to C. The waterline of the company boat is different now; the boat is bigger, there’s much more at stake, and there are more customers than before. Many of the methods used to get to this stage are not the same ones that will carry the company forward.
Where does this leave the hero engineer, who up until now had the ability to decide upon and affect operational change at will? Unhappy? Often, yes. Dissatisfied? Often, yes. They continue to soapbox their ideas and approach, but there’s less adoption. Because of this they often break from company policy and do things the way they think best, because that’s what worked for them and the company in the past.
If there is a fix this dilemma, it’s to communicate that the path to heroism has changed a little. The engineer still can occupy the hero slot, but to stay there requires a different approach. Yes, they still need their technical chops. Perhaps the most significant piece of advice is to suggest they pick their battles more carefully. The bigger boat, with a bigger crew, will experience the consequences of some wrong decisions, and as long as those decisions are “above the waterline,” the boat is not at risk of sinking. So unlike start-up mode, some of the less-important decisions should be left to play out. As the boat gets bigger, there’s always some leakage. Accept it. Perfection is not within our purview.
The second piece of advice to offer is that they learn how to present their idea or concern in a way that can lead to adoption of the idea, or understanding of the concern. A big issue for many engineers is recognizing that slowing down a little is not a sign of failure or weakness, but a sign of maturity. Only certain kinds of problems require immediate action. For the start-up, almost every problem was a fire drill. Not so with a larger operation. Pull back on the throttle. Usually only a little adjustment is needed.
If you were running at Mach 3 as a startup, running at Mach 2.5 as you move from Point B to C is not bad. One now can take some time to convince others of a viewpoint, and why a change is needed. With a larger organization the communication matrix is more complex, and the need to get people on board is mandatory. Previously, being on the SWAT team and breaking down doors was rewarded; in a growing operation this behavior often is viewed differently and often as contrarian.
Usually rogue engineers offer their opinions and behave they way they do with the best of intentions: to further the goals of the company. With that in mind, keeping these engineers engaged and contributing is important. Recognizing that they haven’t “gone rogue” and that instead the company has changed is key, and showing them strategies for their continued success will benefit everyone.