I attended the MassTLC Innovation Unconference on Thursday, and it was very interesting. One session I sat in on was about engineers as leaders, and how to help them. I made a few observations there that have been rolling in my head since:

In my experience, there are two particular stumbling blocks for engineers becoming leaders or managers. The first is that they discover that other engineers can behave irrationally. That is, engineers are people. Engineers understand that the whole world doesn’t work they way they do. They know that if they have to deal with Sales or Marketing people, that there will be some cultural friction. But they are surprised to learn that once they become a manager, the engineer in the cubicle next to them is actually kind of messed up, and has emotional issues to deal with, and will not behave like a nice linear white box.

Engineers are most comfortable with predictable systems that they can hack to achieve a desired outcome. People are difficult to model this way. It isn’t impossible, but it’s a lot more involved than most engineers assume at first. Lots of engineers as managers are really good when the people under them don’t need any management. I probably fall into this category more than I’d like to admit. Once the problems crop up, the manager doesn’t understand why “we can’t all be adults,” or where this “soap opera” came from. Tough luck, dude, you hired people instead of robots. They’re complicated.

The second difficulty is with indirect work. As a manager, you often aren’t building something yourself, you are enabling someone else to build something. You’re setting direction, triaging bugs, coordinating groups, resolving disputes, and so on. All of that is necessary to the group building something, but you don’t feel like you are building anything yourself. A common complaint for an engineer-turned-manager is “I didn’t do anything today.”

Of course, you did a lot today, you just have to value it. It can be hard to see the effect your actions have, because they are at a distance. As an engineer, we’re taught to value direct creation. A clear sign of progress is dirt under your fingernails and a new gizmo sitting on the workbench. Learning to appreciate the subtler effect you can have on a group of people building gizmos is harder.

While we’re on the subject of engineers as leaders, a complementary topic is engineers as followers. Too often, engineers are solo creators. They are used to doing things themselves. It can be hard for them to ask for help. This could be because they don’t want to seem incapable, or because they don’t want to bother others, or just because they are fascinated by a problem and want to figure it out for themselves. Teaching engineers to ask others when they need it is a valuable skill that you won’t find on any engineering curriculum.

I’ve encouraged my developers to become “lazy weasels.” Why build something when you can find it ready made, why struggle through reverse-engineering a dense morass of old code when the guy who wrote it is two doors down? Industry and diligence are virtues, “shortcut” is a bad word, sure. But using the appropriate tool is always a good thing, and what if the best tool for the job is someone sitting next to you, or your manager?