Hacker News new | ask | show | jobs
by jimejim 2785 days ago
"We don't let managers code where I work."

"...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"

There's a connection here. A technical manager can't make reasonable tech decisions unless they do some tech work, but perhaps we just need to be more clear that what you want is a pure project manager to check off boxes.

I think a good tech manager still respects a bottom up approach most of the time, but should have enough experience to push back when the group is steering in the wrong direction. A generic project manager isn't going to do that.

4 comments

I've had a primarily technical career so far and am working on switching to engineering management in the foreseeable future.

Once I'm done with that switch, I don't want to be frequently making technical decisions, rational or otherwise - that should be the job of the tech lead on my team, with input from everyone else.

I will, of course, need to remain technical enough that I can understand whether my tech lead is making good decisions, as you say. I'll also need my team to respect my credibility enough to know that I relate to what they're dealing with, and to be able to effectively keep them unblocked.

But none of this requires sustaining continued technical contributions within my day job past the initial transition period, at least not once the company is above a certain size.

One of the best managers I've ever worked under (indirectly) was not technical and didn't pretend to be. What she did know was people and organizations.

When have you ever heard of a large org making a re-org to solve real problems after substantial consultation and with anything close to universal buy-in? She managed that, and well enough that she correctly used arguments from the rank and file to explain the re-org to other parts of the company.

That's the kind of mentor I'll want to learn from as a manager.

> I will, of course, need to remain technical enough that I can understand whether my tech lead is making good decisions, as you say

A lot of stress has been created for teams I'm on by semi-technical managers chiming in. By telling yourself you'll remain technical enough, I'd encourage you to define what that actually means. Thinking you know stuff that you actually don't is going to be a huge pain in some one's ass.

I once had a boss who kept pushing for us to to do things in a certain way using a remote API, but the API client didn't support the features needed to do the things my boss insisted we use. The boss wouldn't allow for a discussion on extending the API client because he was 100% certain he was correct when he was in fact 100% wrong. I started looking for a new boss after that.

Completely agreed. Knowing the limits of one's knowledge and accepting feedback when one is misinformed are important skills. I believe I already do that and I certainly don't plan to stop.

If I have a competent tech lead under me, I wouldn't be pushing for a certain technical way to do things except if the requirement came from some external constraint like the business or another team, and I would accept the limits of technical possibility.

I might share my technical input if it happened to relate to my area of expertise in a way that wasn't otherwise sufficiently present, but I want my team to know their stuff, not to defer to my technical knowledge out of some personal need to be the expert. Also my input != final decision, with respect to technical decisions, if I'm not tech lead on the task.

Even if I had to push for or against something, I'd do my best to defer to my tech lead (i.e. not me) to actually come up with and lead the solution. It's not a manager's place to prevent a tech lead from conducting a discussion on technically how to achieve the goal within the applicable constraints.

> One of the best managers I've ever worked under (indirectly) was not technical and didn't pretend to be. What she did know was people and organizations.

I don't mean to create a debate around sexism in the workplace, but could this be because in general in the US, we expect males to have a big ego while for women its OK to be not have one? As a male, I've had trouble with my ego getting in the way pretty often but I try to recognize that and be better about it.

You're right about the general pattern in the US, but that isn't the explanation in this case.

She made sure there were plenty of technical managers under her (she was a VP). The problems that really needed fixing were organizational, not technical, and she did something that a manager with a more technical skew of skills might not have known how to.

The managers in that company who tended to be good and well liked didn't have a big ego regardless of gender, even if (as in her case) she was appropriately aware and confident of the areas in which she was strong.

> "We don't let managers code where I work."

That leads exactly to the situation you described below.

> "...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"

I recently left my job at a respected social network over my new manager lacking the proper technical skills yet not accepting more reasonable solutions.

Case in point: imagine you have an API endpoint you normally hit with your service, periodically. We make a GET request to this endpoint but it also supports POST. The parameter sent is q=<some_long_string>.

It comes to my attention that this long string can get over 1MB long, at which point it causes issues with our service.

I bring up in a meeting that we should just POST to this endpoint instead of doing GET at all times because the data could be larger than 1MB at times. Makes sense, right? Well, my manager without the proper technical awareness basically pushed for us to check if the query is larger than 1MB and POST if and only if it is larger than 1MB.

I gave my two weeks a week after that and made it very clear to the upper management that this manager was the reason I was leaving and I felt like I was being stifled by having a manager like this.

But your manager was doing what I said he shouldn't do which is butt in on technical decisions. You should have talked to your skip and your team mates about your manager stepping over the boundary. You should have also told your manager you wanted to switch teams. There are plenty of other managers who don't work like that.
While that would satisfy the immediate problem of not having to personally work for such a manager, it doesn't solve the problem that the company has such managers.

Better to leave.

As long as the company has clearly defined the roles in the way I've described there is no reason to leave. There will always be outliers who are not working as intended. That's human nature for you. The real solution is to try and help those people understand their role better, and if that fails, then get rid of them.
There is at least one bad egg almost anywhere.

I mean no disrespect, but if you quit every time you have to work with a bad/obnoxious/egotistical/incompetent/delusional manager (or project manager), you'll never remain long in one job.

yes, to you and the other sibling, i didn't mean one bad apple ruins the bunch. i assumed reasonableness of the GP in that he didn't experience once bad interaction and bail, and that he left out all those details for the sake of brevity. because you know, most people are (by definition) reasonable.

i thought it would have been too much to qualify my remarks but i see i should have.

i only meant, if this is the norm for a company, leave post haste.

thank you for challenging my comment, it was well deserved.

As others have said, a good manager shouldn't have got involved at all with this discussion beyond "figure it out!". Technical decisions aren't their job anymore. They are there to solve people and organizational problems now--not technical problems.
We don't want managers steering anything. That's either the job of the group or the tech lead. The manager is supposed to manage the team the same way a managers manages a baseball team. You get the right people, give them the right tools, and let them play the game.
Exactly, this feels right to me. A manager's job should be to keep track of things but without micromanaging too much (a good example was checking being able to build your team's code on occasion etc.) and also providing the tools and protection they need from upper management so that the team can play the game.

In my previous team, I essentially had the tech lead role in the team but that role wasn't acknowledged with a title, although the entire team was very aware of it.

Ended up getting too much friction with the new manager and I left.

I got a job almost simultaneously as I left. It is much shorter commute, it pays more and it is more exciting. However it is unfortunate I had to exchange 3.5 years of rapport I've built at a place for these.

The role of a project manager is to have someone who can represent the user. The project manager should be talking to users, soliciting product feedback, getting bugs filed, and feeding this to the team.

The role of a manager is to manage the people on the team. That means helping them grow their careers, help them switch teams if they find something that would be a better fit, promote the teams work, unblock people, give feedback on how team members are communicating, manage meetings and fill in for team members so they can spend more time coding that sitting in meetings.

Basically a people manager is like a boxing manager. He gets the champ into shape, puts him in to the ring, and cheers him on. When the champs not fighting he makes sure the champ can focus 100% on training.

I think you mean "proDUCT manager" – a project manager usually focuses on schedule, balance of work, bottlenecks, and maintaining (but not defining) priorities.

It's pretty common for an engineering manager to do project management, and to some degree it's necessary: people management and priority management are closely related.