4 ms·

I had the same reaction to this as many others have, in that I think much of this stuff is good/fine, but the advice that engineering leadership shouldn't actua

I had the same reaction to this as many others have, in that I think much of this stuff is good/fine, but the advice that engineering leadership shouldn't actually directly contribute in a technical fashion is wrongheaded. I have elaborated on this in the past[1], but in particular, I don't think it's reasonable to expect to be the "tie breaker" in what is (tautologically) a sharp divide on an engineering team when you no longer contribute: as a non-contributor, you will be relying on what people are telling you instead of your own engineering judgement. 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. [1] http://www.slideshare.net/bcantrill/surge2013 http://www.slideshare.net/bcantrill/surge2013 video: http://www.youtube.com/watch?v=bGkVM1B5NuI http://www.youtube.com/watch?v=bGkVM1B5NuI

lifeisstillgood 12y ago
I liken software literacy to "real" literacy - and see enormous parallels with software organisations and newspapers. Even once in management, the managing editor still was expected to read the more important articles, and if they were not good enough reject them. And if he was to write the leader, it still had to meet the deadline like everyone else. So I agree with never stop writing software - but it is also important that management learns to "let go". The article will never read as well as the one you imagined Ou would write. And somewhere there is a difficult balance between code that is not to your taste but still good enough and code that is not to your taste and not good enough. I still have not worked that one out.
snowwrestler 12y ago
Unless the proponents of competing ideas are actually lying to management[1], there should be distinguishing characteristics that allow a reasonably savvy manager to make a decision. One does not need to check code into the repo regularly to understand the conceptual differences between two different architectures. In the case where there is not enough data to make a reliable decision, the proper management move is to instruct both teams to collect more data, through load testing, user research, beta trials, etc. A well-known example of this was the early iPhone software development, in which one team built off the iPod OS and another off the Mac OS, until the best way forward became clear. If the disagreement is not likely to be decidable with data, then it's probably a matter of opinion anyway, and a quick decision that sticks is better than agonizing. [1] If you think your staff is lying to you, there are bigger problems than technical competence.
- deleted 12y ago
  [deleted]
tjradcliffe 12y ago
Managers should be able to build and run the application (assuming its an application) and fix minor bugs, including going through review and check-in. The size of the technical issues they should touch with their own hands scales at least linearly with the size of the team. On a small team there is no problem with the manager being deep in the code. On a team with more than five people the size of things they should be dealing with starts to drop pretty precipitously, and by the time they are up to 15 or 20 people they should be doing not much more than the odd cosmetic tweak. The reason for this is that life is a personnel problem, and as the team gets larger than 5 you just don't have that much room in your brain to accommodate the different modes of thinking required for dealing with people and code (or maybe you do: I don't, but my brain is particularly small, or so I've been told.) With regard to the manager you described: they are simply a bad manager. Good managers are always working to facilitate their team's progress. Doing things like calling a meeting to harass over-worked people into working harder is bad management, and no amount of technical hands-on will change that. So my prediction is getting a person like that into the code won't help.

lifeisstillgood 12y ago

I liken software literacy to "real" literacy - and see enormous parallels with software organisations and newspapers. Even once in management, the managing editor still was expected to read the more important articles, and if they were not good enough reject them. And if he was to write the leader, it still had to meet the deadline like everyone else. So I agree with never stop writing software - but it is also important that management learns to "let go". The article will never read as well as the one you imagined Ou would write. And somewhere there is a difficult balance between code that is not to your taste but still good enough and code that is not to your taste and not good enough. I still have not worked that one out.

snowwrestler 12y ago

Unless the proponents of competing ideas are actually lying to management[1], there should be distinguishing characteristics that allow a reasonably savvy manager to make a decision. One does not need to check code into the repo regularly to understand the conceptual differences between two different architectures. In the case where there is not enough data to make a reliable decision, the proper management move is to instruct both teams to collect more data, through load testing, user research, beta trials, etc. A well-known example of this was the early iPhone software development, in which one team built off the iPod OS and another off the Mac OS, until the best way forward became clear. If the disagreement is not likely to be decidable with data, then it's probably a matter of opinion anyway, and a quick decision that sticks is better than agonizing. [1] If you think your staff is lying to you, there are bigger problems than technical competence.

deleted 12y ago
[deleted]

tjradcliffe 12y ago

Managers should be able to build and run the application (assuming its an application) and fix minor bugs, including going through review and check-in. The size of the technical issues they should touch with their own hands scales at least linearly with the size of the team. On a small team there is no problem with the manager being deep in the code. On a team with more than five people the size of things they should be dealing with starts to drop pretty precipitously, and by the time they are up to 15 or 20 people they should be doing not much more than the odd cosmetic tweak. The reason for this is that life is a personnel problem, and as the team gets larger than 5 you just don't have that much room in your brain to accommodate the different modes of thinking required for dealing with people and code (or maybe you do: I don't, but my brain is particularly small, or so I've been told.) With regard to the manager you described: they are simply a bad manager. Good managers are always working to facilitate their team's progress. Doing things like calling a meeting to harass over-worked people into working harder is bad management, and no amount of technical hands-on will change that. So my prediction is getting a person like that into the code won't help.