October 4th, 2014
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: firstname.lastname@example.org
But my objection to the advice that management should not contribute technically is actually deeper than technical conflict resolution. Software is so hard that it becomes like child birth in that we have an overwhelming bias to forget the pain: the second you stop writing software, you start rewriting your own history. So as far as you can remember, it was all pretty straightforward, you always hit your deadlines, etc. And with this, you have started down the primrose path in which you just can’t understand why this is taking so long and can’t you guys just get all of the bugs fixed?! I (like many — if not most — software engineers) have seen this first hand: one of the most technical people I’ve ever worked with ventured into management, stopped writing software entirely, and — with astonishingly short latency — forgot over a decade of experience of pain. He forgot the inifinite complexity of software, and instead assumed that bugs were due to a lack of urgency, laziness, or worse. At one point, we were getting crushed by a very nasty issue, and he called a meeting to spend an hour telling us how important it was (oh, thanks!) and that he “didn’t want to hear details; just get it fixed”. If he had only asked “what I can do to help?”, I was ready with: “You are — or at least were — a damned good engineer; you can help us debug it.”
This brings me to a slightly broader point: as technical leadership, I believe that direct contribution is essential, but you do need to be very careful about how you contribute. The last thing you want is to be on the critical path of some feature and have the team blocked because you’ve been called into a board meeting (or a customer visit or an off-site or a planning meeting or any of the other of zillions of ways in which organizational leadership must spend some portion of their time). For me personally, the answer this is particularly easy because it dovetails with what I love to do anyway: my way of directly contributing to my team is to debug. By picking up bugs that no one else is looking at, you’re out of the critical path, but you are helping the team, staying technically current, and reminding yourself — constantly! — of the brutal complexity of software engineering.