11 ms·
As a manager, I quickly realized that trying to be a technical contributor was a subtle and insidious form of micromanagement. Also, I could give myself my pick
by analog31 5y ago
As a manager, I quickly realized that trying to be a technical contributor was a subtle and insidious form of micromanagement. Also, I could give myself my pick of the coolest tasks, which was unfair.
- jzwinck 5y agoWhy did you feel that making direct technical contributions was micromanagement?
- qzx_pierri 5y agoNot 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.
- indymike 5y agoI'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.
- qzx_pierri 5y agoAt 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.
- indymike 5y ago> 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.
- disgruntledphd2 5y agoYup, but unfortunately the world is filled with dysfunctional people. Functionality is the exception not the rule :(
- goodpoint 5y agoBecause 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.
- jzwinck 5y agoIt 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?
- Ntrails 5y agoThe 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
- skeeter2020 5y agoyep, 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.
- convolvatron 5y agothis 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.
- flyinglizard 5y agoEach 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.
- ahelwer 5y agoVery 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).
- gompertz 5y agoNo 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.
- flyinglizard 5y agoManagers 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.
- aprdm 5y agoI pick boring tasks that have been sitting on the backlog for a very long time usually .
- pdimitar 5y agoAnd you are a hero.
- brightball 5y agoOne 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.
- vincentmarle 5y agoIt 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.
- brightball 5y agoMaybe. 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.
- sciprojguy 5y agoIn 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.
- 88913527 5y agoThere'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.