Hacker News Reader

Comment by Jormundir | Hacker News Reader

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.

View on HN

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