Comment by tjradcliffe | Hacker News Reader

Comment by tjradcliffe | Hacker News Reader

Parent Full thread

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.

My best experience with a manager so far has been one that generally delegated all technical tasks but was available to solve them should the need arise. It's 9am and no one else is around to help a blocked QA fix a broken build? It can be 'fixed' or at least reverted in a sane way. Or (esp. with a large company) some other team's service/lib is behaving unpredictably, get the right people in the chat/room/phone to make sure an engineer can get things working.

Managers should empower teams to do their best work, not get in the way or do their work for them.

Based on my current experience, I would avoid joining a team that had a manager partaking in programming / devops.

All different types of managers can be good or bad, my personal experience has just been that managers who dive into technical tasks, even just bug fixing and devopsy stuff, tend to neglect their managerial responsibilities just enough to be a chronic frustration to everyone below them.

Having only been in the industry a few years, it's also extremely frustration when a manager does not delegate responsibilities you're interested in taking on. So my view now is that if you're a manager taking on technical tasks, you're denying your employees opportunities to grow professionally. It certainly depends on mood at the time, but in a negative cycle, this can feel like a vote of no confidence from your manager.

I find it strange that there's a debate about this. When it comes to cooking, medicine, law, architecture, hairdressing, design or sales, the best people manage a team and continue to practice themselves.

When a dev team manager doesn't understand the architecture of the systems and exactly how everything works, they cannot be in full control of the team.

Businesses need crossover people. People who can code AND who "get it" at a commercial boardroom level.

I think the larger the team, the larger the managerial workload. We're so small, if our client app manager stopped doing dev, we'd have to hire another person. At a global company I started with after college, working with with a team of 10, my boss split his time between managerial busy work (expected of him by upper management, not self-imposed) and being as involved as possible. He was always able to speak intelligently about the product and its code, and was able to contribute in ways that set an expectation of quality. He always had the respect of the team (and when not, someone got fired). I consider him to have been a mentor - he got it right.

If you're managing a team of 40, being involved directly in code/execution is likely impractical and perhaps even detrimental, but at any scale up to 15 people or so, direct involvement seems both practical and necessary to retain the respect of your team, and assure a quality product in the end.

I've never been on a team larger than 12 people, and they still needed someone solely doing managerial work. I think it's easy to say "my team doesn't need a full time manager". Though the problems I've seen arise as a result of lacking management are slow and quiet. Grouchiness slowly creeps its way in until a group of good (usually the best) people quit with little warning. I can't emphasize enough how much I think a good full time manager is vital to a team's performance and endurance.

The role that's being described above is one I would consider a "lead engineer", not a manager. The healthiest role division I've seen so far is when a team has a full time manager, and also a lead engineer or two who are ultimately responsible for making sure the needs of the business are being fulfilled by the engineering team.

Yes! You are a manager first. Your job is to direct the actions of the team, your technical expertise needs to only go far enough so you do not commit your team to a death march.

Even worse if you use your position to cherry-pick projects away from your team because they "sound fun". Talk about a morale buster.

Reply on news.ycombinator.com