One of my favorite jobs was managing about a dozen Python programmers for 3 years…because I don’t know a lick of Python and it forced me to focus on the team more than the tasks.

I got a lot of joy out of helping everybody develop, find their groove and helping them coordinate and learn from each other.

The business demands I was shielding them from were extremely stressful though. A million things that everybody wanted done yesterday in wildly different directions.

At some point in trying to make concessions on the business side I started losing the support of a couple of senior guys on the team though. After a couple of months it was pretty clear there was no getting that confidence back. When the demands from both sides became too high to resolve, I didn’t have any choice but to move on. Really frustrating too because I gave so much to that job and team, but you can tell when you’ve lost people and there’s no easy fix like refactoring the code to make it all better.

As a manager, trust is the only thing that allows you to be effective; when your team knows that you are really looking out for them.

It sounds like you were trying to be too nice and were trying to appease both sides; that’s a losing proposition. You are working with adults, and adults should be able to handle bad news (if handled properly), and a good manager should be able to bring the bad news but at the same time give enough context so that everyone understands.

In a perfect world you would be right, but spend some time with a bunch of clueless executives who don't know how clueless they are (or are trying to pretend they do have a clue) and you'll realize there's no amount of context that will help them realize why there's bad news.

Maybe. It was my first time being full time management only. Balanced it effectively for the better part of 3 years. There were a lot of unique challenges (in the non-exaggerated sense) and learning experiences in that job.

The alternative is you give yourself the low priority low probability work. The 'noodle around this nasty thing nobody wants to touch' work that delivers tech debt reduction or a velocity win. It can be very fulfilling, but no critical path, no OKR or delivery date etc etc

this is right. no, you don't get the big win. but you do get to put in that cleanup that everyone is always talking about. and you get to actually write the tests that no one else has time for.

you kind of have to do this. idk how I could function effectively if I didn't have a reason to be looking at the code all the time.

yep, The self-assign for many managers should be boring spikes, documentation and execution tasks. You will need to get your tech fix somewhere other than your day-to-day.

I pick boring tasks that have been sitting on the backlog for a very long time usually .

And you are a hero.

There's been times where it's the right thing to get involved, and other times when it's not. For example, we had an issue with full ticket completion: sometimes 3 of 5 requirements would get complete, and then the work was merged. I wouldn't review line-by-line, but I would cross-check the features and note if I found something missing. To be clear, I would not dictate how to do the work. In the meantime, we instituted processes to ensure work was completed in full, and once the team norm'ed around the new process, I stepped back.

Why did you feel that making direct technical contributions was micromanagement?

Not the person you replied to, but it's because manager's will never truly fit into a project. Most people don't want to go against the manager, or question decisions made by the manager.

Even if the manager specifically says "Hey everyone, give me some feedback. Be open and honest" - That's a trap. No one will ever actually do that, because if you bruise your manager's ego, they have the power to make your life a living hell.

As someone who has worked with managers who did tried to get too involved in projects, they just become a dictator. Since the manager will play an oversight role in the project, any small issues will be visible to them at all times. Normally, the team could work out small roadblocks on their own to keep stress low. If the manager is involved, they'll often try to "make themselves useful" and slow things down. Let's not even mention manager statements like "Hey guys, let's keep a note of this so we can work on restructuring our processes in case this happens in the future"... (Because everyone loves redrafting SOPs every 2 months, right?).

A good manager is one that stays out of the way and lets you do your job. Having a manager on a project kinda feels like that episode of The Office when Michael comes to Jim's party and everyone was just kinda standing around awkwardly.

I've been a hands on contributor and manager for long time. I do three things that seem to make this a lot more functional:

1) I pick what I'm going to work on after the rest of the team picks their tickets.

2) I fix one bug per day, not matter what.

3) HIPPO (HIghest Paid Person's Opinion) is not an acceptable reason to make a decision.

It's worked well for me, your milage may vary.

At least that's what you think. I'm sure your direct reports have a lot of opinions on that setup that they'll never reveal. I say this with 100% confidence.

> I'm sure your direct reports have a lot of opinions on that setup that they'll never reveal.

Then I'll never know how to make things better. It's dysfunctional when you can't communicate safely and equally dysfunctional when problems are hidden for fear of a manager's ego.

Yup, but unfortunately the world is filled with dysfunctional people. Functionality is the exception not the rule :(

Because you either manage people / goals / interactions with other teams or do front line work.

If you cross the barrier the people in your team will be put under pressure having to do things like for example disagreeing with technical decision or debating something in a code review with... the same person that has the power to promote or fire them.

It creates a power gradient in every day activities.

That's "stealth" micromanagement regardless of the good intentions and technical skills of the manager.

It sounds like you're saying that even reviewing code of subordinates is micromanagement? If you have a team of junior developers, who should review their code? Someone from another team?

Each hour put in as a manager is many times the return of you as an IC (for better or worse). As technical work is an endless pit of time, it’s very difficult to be a hands on manager that’s effective.

Very entertaining to read a thread of managers telling themselves they shouldn't do any work, and then simultaneously describing not doing any work as "many times the return of you as an IC" (presumably counting themselves not interfering with the people doing the actual work as equivalent to doing the sum of that work).

If you think "hands on keyboard coding" is the primary/only form of work that matters, then you've missed out on a lot.

Of the best managers I've worked for, one of the most obviously important things they did was keep other teams off our backs. Constant interruptions, shifting priorities, "just a quick question", and the like do more to destroy a team and its progress than anything else. Their name doesn't get attached to lines of code or completed items but a lot more things get completed as a result.

If you want that then hire someone to stand outside your office with a stick and reply rudely to emails. We don't need to give them hiring/firing/promotion/rewards authority.

As an IC you can't tell other teams managers or higher ups or PMs to fuck off if they call you directly and tell you they think what you are doing isn't good. Or if they ask for unreasonable stuff. At least without fear of getting fired. A manager needs to prevent this from happening

So the problem managers solve is the problem of there being other managers?

Don't forget sales/marketing overpromisers and nosy executives who get in the developers' hair.

Completely alarming this comment is being down voted. It's 100% true.

I guess it depends on what the person is doing. A guy with a stick won't be negotiating timelines and requirements, explaining why things can't / won't / weren't done, dealing with fallout or shifting the requirements / timelines of others based on teams productivity.

Do they need to be the one with hiring/firing/promotion/rewards authority? I don't know.

I don’t especially care what people think of the job I did, or how I did it. I made enough to be where I am, today, and I like it.

It was what it was, and it is what it is.

I just wrote about my own experience, and my own feelings about that experience, as opposed to rendering judgment (look through my posting history, here, and you’ll find very little judgment of others. I am too old and tired to fight. I have better things to do with my time, other than TCP/IP posturing).

Your imagination is very far from the reality of what managers do. I’ll give you a run-down of my day:

1) reading emails. These emails generally consist of a few categories of things — stuff I need to be informed about, questions, asks for permission (a special form of question), documents (generally decision and decision docs, or stuff from Product), and meeting requests.

2) meetings. These meetings generally consist of stuff that couldn’t be handled over email, but is a lot of the same stuff. It’s also status updates, not from my staff, but with my peers. 1:1s and staff meeting (mine and my manager’s) are the balance.

3) There is no 3. Really, it’s a full time job to do 1 and 2. Every now and then I will carve out some time to write a document myself, but in general that gets delegated because I will do it more slowly than someone who doesn’t have a pile of time-sensitive email and meetings to deal with.

You are mistaken, this is literally - word for word - my imagination of what managers do.

Well then you are mistaken in your characterization of this not being work.

Replying to emails and sitting in meetings thinking of the best way to tell other people how to do the actual work isn't work, no.

Oh I forgot - we give the people who do this control over the employment of the people who do the actual work. Very weird system.

I'm not sure what's more unsettling to me: That we have managers here who believe that reading emails and sitting in meetings is considered contributing and making an actual difference... Or that HN has this many managers on it who apparently really cannot code or directly contribute alongside their team; yet are posting on a more technical forum, on a regular basis. Strange. Guess it's like a hockey fan who watches every game but has never laced up skates themselves.

Former manager here - you'd be very surprised at how much effort it takes to act as a human shield for your developers to keep the interruptions to a minimum and keep their roadmap stable. It's work, and it can be delicate. Try running interference with a company president who wants to bother your developers when they're trying to get something out the door, or trying to make sure stupid ideas die before they become your team's problem.

Why do people keep saying that managers solve the problem of existing in the same company as other managers as though that’s a compelling point?

And yet one that billions of people participate in. You are either a genius of epic proportions or just wrong in your thinking here. As long as people in coordinated groups get more done than individuals, I believe you are wrong.

People in coordinated groups do not necessarily require someone to sit around in meetings and send emails telling the rest of them what to do.

Btw, I never said “telling the rest of them what to do.” That is a complete misconception of management, at least the way I believe the best managers practice it. I only get involved in decisions that my team has been unable to make themselves. Even then, I rarely find myself having to be the decider. My role is to facilitate a good decision, not to tell people what to do. The team looks to me for prioritization and providing context, not to top-down manage them.

How is coordination achieved otherwise?

The other guy is definitely a bit jumpy and as a programmer I can't agree with him (fully) but that part of your comments stood out to me:

> And yet one that billions of people participate in.

Most of humanity participated in slavery for a long time as well. A lot of Europe's city dwellers enjoyed watching the hanging of criminals at dawn or sun-down, too. People also developed the mass habit of accusing a neighbor they don't like for being a witch and were hoping to have them burned (because the neighbor's chicken pecked your watermelon seeds or whatever; yeah, people are that petty).

Appealing to statistics and what the majority does is missing the point of the big power imbalances that are sadly one of the constants in every human society or system.

It doesn't help that many programmers are rather introverted and prefer passive resistance as opposed to having a good and informative one-on-one meeting, of course. And many managers are stuck in the unenviable position of having to develop skills to extract valuable actionable info from introverted people who prefer to sabotage them behind their backs. I recognize that and I sympathize.

But the inconvenient truth is, and one many managers forget about all the time, is that most of us have zero decision power -- which is quite the shame because we need it in no small amount of situations.

Formulas like Scrum (or anything "agile" really) are a complete and pathetic joke. The process must adapt to the task at hand. The best performing teams I've been in had zero process -- they only had some 10-15 ground rules like "if you are stuck for more than a day please raise the issue with the rest of the team; nobody will think you're stupid, we'll only try to unblock you". Whatever needed to be done, we used our own breed of process that best served it. On the rare occasions Scrum was actually useful btw. Most of the time the schema was more or less "enable your ICs, actively seek to unblock them, then leave them the hell alone, they know what they're doing".

You alluded to (in another comment) that you don't make the decisions; that you facilitate the people to arrive at the right decision. Kudos to you but you should still recognize that you're the minority, sadly.

Most programmers are forced to work with managers whose ego is easily bruised. That's a fact of life, one that can't be fixed by going to another job because the odds are at least 90% that it will be the same there as well.

So yeah, there are problems on both sides, that's unquestionable. I mostly went on to rant about how appealing to statistics is a poor strategy to evaluate if a given system is good (which doesn't at all explain how many companies started getting more bang for their buck after they moved to a 4-day working week btw; among other examples).

I undoubtedly compressed too much into too few sentences. My allusion to genius||wrong is raising exactly this concern. How do you decide which? For me in this argument it comes down to results. Why do people organize in this way? As I stated,I believe groups get more done than individuals and that coordinating those groups becomes the central feature of management. It can be done poorly or well, but if it facilitates the group being more productive than an individual it is superior from a pragmatic perspective.

Managers do work. They decide you what need to be done, when it’s due, they coordinate processes inside and outside the team, they (hopefully) review what gets implemented, make sure the team has the physical things it needs, build budgets and roadmaps, isolate the team from organizational bullshit, work on hiring and more.

It’s quite simple - you as a manager can only do the work of one IC but your are responsible for multiple ICs. If they sit idle, make the wrong decisions, are demoralized or leave the company, you hurt the org much more than help by technical contributions yourself.

I’d put the cutoff at about a team of 6. Below 6 you can do technical work yourself, above 6 you’re better off taking care of your team.

No kidding... We got managers here saying they don't know a lick of Python their "IC's" [1] work on, or they can only contribute by ordering pizza when their team is working hard. Seriously...talk about textbook Dunning-Kruger. It use to be people got promoted to manager from becoming experts in the task they would now manage... Now they are spawned from business school, I guess. It's fine to be a manager and manage a team, set goals, deliverables etc etc... yes, it's a real job. But damn you for not being able to roll up your own sleeves and put pen to paper with the rest of your team to achieve those goals.

[1] This business jargon term has seriously got to go. It's bullshit and oddly demeaning.