On: The engineer manager

Published

Engineers are amazing tools of society. In a puristic world an engineer essentially offer solutions for real problems. But realistically speaking engineers are masters at consensus.

One of my engineering school teachers use to say that “There aren’t really solutions, only compromises.”. For most of my professional life this has has been true. Getting information systems that actually benefit people and societies comes down to compromises, getting the common done, the most agreeable agreed. People aren’t available to chasms of change, and sometimes improving 5% can have huge beneficial improvements

Because engineers need to be managed, as every single person of society, they tend to see this task as a annoyance, or a problem needing to be fixed. It is quite trendy today to say that to say that engineers are great managers. I have a dissenting opinion.

Management does needs fixing. I, has a engineer, have zero patience for things like casual Fridays or team building exercises. I do recognize that teams (even in the army) come out of effort and respect, not from silly activities. I wish I could end this silly activities.

Engineers tend to see management as a problem. The types is activities I’ve mentioned are common because they have effective results. Statistically speaking, if you do these activities in large sets of people they tend to have x% of effect.

I’ve been purview to a lot of engineers middle to upper management. My observations tend to conclude that engineers take the same approach on management that they take on problem solving. They don’t see management actions as definitive but more as compromises. E.g.: We do X now because all stakeholders agree this is the best option.

The problem is that management doesn’t work the same way. The reasoning behind management is more akin to military thinking. Sometimes you do Y now, screwing A, B and C, because you know that in the long run your are getting what you want. Even if this is suicidal. This is different from Cost/Benefit analysis. You don’t always get value for your actions, not even in a predictable future.

Aereo wouldn’t exist in a pure engineering approach to management. It is a stop gap solution to a problem, that has zero diversification chances, and clearly was created to open a breach in the Network control of media on the Supreme Court. This company makes zero sense on the short or long run. However, everyone can see the potential of positive verdict from the SC.

There are more examples as this. See the Apple vs Samsung approach of getting shit done. Apple, doesn’t give you what you want. It gives you what it thinks you may find enjoyable and it finds is best for Apple. Samsung tends to reach a compromise, giving everything that everyone may want, or get attracted to.

More examples, Eric Schmidt vs Larry page. Eric had a engineering approach to problems. It did lots of concurrent products, lacked focus and tried to get everyone on board (vide Android). His management style never seemed defiant, always consensual. Larry’s inheritance is a fragmented company (android and chrome), a bunch of useless products, and lacking core products for the next decade (E.g. Google Plus or if you will, an identity product).

Management, for better or worse is a different beast of engineering. And the same way you can’t ask a bean counter to do your job, an engineer cannot expect to have the same tool set than a manager. Your reasoning is biased to think in another way. There are counterexamples of course. But asymptotically both approaches are clearly incompatible.