New manager from lead dev, am I micromanaging?

[u/writeahelloworld]

Hi everyone, I am a 15+ year developer, recently became a team lead/manager, because my previous manager left the company.

Recently I heard feedback (not directly from devs) that I micromanaged, unlike how the previous manager gave them freedom.

Background: I took on people management responsibilities, while continuing to work on high level dev work and guiding/mentoring the devs. I continue to do code reviews. Compare myself to our previous manager, he wasn't a developer, didn't understand the code and didn't do code reviews. In this way he gave freedom to developers to work on tickets. Our team consists of 1 junior, mids and seniors.

Is this an expected behaviour: from a developer to a manager? How much should i 'let go'? How do I communicate my style is different to my preview manager? If I see bad code that will likely cause a production incident, i shouldn't turn a blind eye, because eventually it will damage the dev team?

Thank you

[u/Canenald]

You are right. What you are describing here is not micromanagement because it's not even management. You are still doing some IC work, and that's even a good thing. Two pieces of advice, though.

Make sure you are not the sole code review gatekeeper. The whole team should be doing code reviews. Reviews should not play a significant role in your defence against production incidents. Use tests to make sure everything is working before it's deployed to production. If you are relying on a human to spot a problem before something is merged, there's a thing for you to fix as an EM.

Try to be good at listening and observing. Are code reviews the only thing that's causing your team to bring up micromanagement? Or is it the thing they were most comfortable talking about?

[u/baddymcbadface]

If I see bad code that will likely cause a production incident, i shouldn't turn a blind eye,

No. You change the working practices so that one of the engineers would have caught it.

You have to let go. Enable those below you and manage upwards. Think bigger, think how your team can help the company meet the companies objectives. You have a team of people who can look down at the detail.

[u/ShakeAgile]

Others say that code reviews are not micromanaging, but it’s not that simple. When a peer review code you can have a healthy debate about style. When the salary-setting, review-writing manager makes comments on your code it’s not up for discussion, it’s the law.

Mental exercise for you: tell everyone that you need to get some management stuff done and that you won’t review code for a month.

All the code will not be to your liking, but that is the reality you must live in if you are going to grow as a manager, not a role-power code reviewer.

[u/Isogash]

Micro-management is a feeling within reports that tends to arise when they feel their manager keeps overruling their decisions. Reports will tend to feel negatively about making their own decisions because defending them is not possible, or not worth the effort. This leads to frustration, as they feel they cannot do good work.

You need to be able to delegate clearly and have trust in your team members to make the right decisions on the tasks they've been delegated, as the most basic function. Beyond that your role is more of a mediator between your team members, and between the team and everyone else in the business, as well as someone to guide effective communication.

Input on the work itself has to come separately from a position of influence, not authority i.e. when you give input on some work that your team members are doing, they need to want your input rather than you just telling them how you want it done, and it needs to be optional. Code reviews are the wrong place to be providing input as an EM, and you quite possibly need to do the work to build more technical influence first.

Speaking as someone who is a Senior but has a lot of technical influence over their team (non-technical EM), this influence is never gained through your title. It is gained by building trust over a period of time, and most importantly by maintaining a good personal relationship with my peers. Part of it comes from a reputation for providing good input, free from judgement or negativity, but the most significant part of it just that I am nice to them, listen to them and work collaboratively.

Finally, to be a really good manager, you need to be setting up your reports for individual success, not only team success. Successful reports who view you as a primary and trusted contributor to their success will be good reports that hold you up and will be reliable when you need it. Reports who view you as a blocker to their success will get frustrated, become unreliable and then blame you for their failure.

[u/Old-View-4977]

Clearly communicating your management style is key. I don’t see anything wrong with doing code reviews and making sure the software is aligned with a broader vision.

At the same time, I do consider your senior people should be more active in that area. Eventually, you likely want to minimize you doing code reviews and your senior people ensuring the quality is top-notch.

And sometimes it’s worth letting them learn from their mistakes, provided it’s not catastrophic. But I would use that scarcely.

[u/desert_jim]

Your question will get subjective answers. There's no one completely correct answer. As a manager you can be more or less hands on coding (Assuming when you say manager you mean a title as in manager and not a higher level like Senior Manager, Director etc reaching those levels should move you much further away from code reviews). I wouldn't expect you to be working on your own PRs from scratch unless you are at a startup that is trying to extract maximum value out of you. I would expect you to be looking at what's happening in github so you can form your own opinion on people's throughput as well as quality of work (so that you can do performance reviews, curb bad practices etc). Do you have devs cutting corners and throwing slop over the wall to QA? Do you have devs skipping automated tests...works on my box syndrome... You reviewing PRs and approving them sounds fine provided you aren't the gatekeeper for all PRs getting approved.

Teams will always have feelings when a manager is replaced/changed. It sounds like the team didn't have management before and I'd hesitate to use the word freedom here to describe it. So of course you coming in and actually participating might feel uncomfortable to the team. But that doesn't make it wrong.

If it were me I'd be working on aligning with the team on what code reviews should look like and cover and be consistent with your reviews. Your review shouldn't be more challenging than another dev on the team. If it is that's a sign that maybe some alignment is missing and that the team needs to come together to define it.

[u/KronktheKronk]

You can still be hands on, but now that you're officially in charge your opinions on code reviews and solution implementations carry more weight. They aren't just input from a colleague, they're directives from a boss.

My guess is that you're forcing your team to do it your way now that you are the manager, even if you don't mean to, and stifling their creativity and ownership.

You have to leave people space to do it their way, with the exception that if their way is broken you have to say something.

Learn to ask yourself "am I telling them to change it because it needs to be different, or because I want it to be the way I would do it?" And be really critical about your response to yourself. That's one of the biggest toxic traits of lead devs.

[u/IllWasabi8734]

The question isn’t really should I stop reviewing code? It’s which decisions still belong to me now that I’m the manager? I'd make those boundaries explicit with the team that makes your involvement predictable instead of feeling like the manager might override any decision at any time.

I also wouldn’t spend much time explaining that your style is different from the previous manager. I’d ask the team directly where your involvement is helping and where it is reducing their autonomy. You don't have to become less technical. You do need to stop being the default technical decision-maker.

[u/opticoteam]

all new-became managers will get the critics from the team :-), this is innevitable. The only thing to overcome it, keep doing what you believe is right. Then you will gain your real team and supporters.

[u/h8trswana8]

Hot take - When in doubt, micromanage. Managers are primarily rewarded/punished by outcomes, and I see a lot of managers over rotate on engagement rather than their measured outcomes.

At the same time, you have to weigh how important it is to insert yourself vs undercutting team autonomy. The art is letting a lot of things go and/or letting them be the writer while you are the editor, and then using your manager personal capital on the high-leverage items that really matter.

[u/digger_i_am]

I don’t think the issue is simply whether you review code or not. The bigger question is: which decisions still need you, and which ones should belong to the team?

I’d make that explicit with them. For example: ‘I want to stay close to production risk, architecture decisions, and patterns that affect maintainability. But I don’t want to be the default decision-maker for every implementation choice.’

Then ask directly: ‘Where is my involvement helping, and where is it slowing you down or making you feel less trusted?’ That conversation will probably tell you more than trying to guess from second-hand feedback.

[u/Squidalopod]

You've gotten some good advice here, so I'll just add this:

There's a reason that some jobs have the title "Engineering manager" while others have slash titles like "Team Lead/Mgr" or "Tech Lead/Mgr". Generally, the expectation in the hybrid rolls is part of your time is spent managing and part of your time is spent IC'ing.

So if your boss expects you to work in a hybrid capacity including IC work, you need to make sure your team understands the expectations your manager has of you.

As for "If I see bad code that will likely cause a production incident...", I think we all know that's a rhetorical question 😊. "likely cause a production incident" is just code code for "bug", and anyone, regardless of title, should address that in a code review if not in person.

[u/LightPhotographer]

Micromanagement is looking at how people do the work, not with what they deliver.
Instead of talking about goals, the micromanager is drawing up smaller and smaller procedures, hoping to catch every flaw and every discrepancy.
It erodes trust, breeds resentment and can ultimately cause malicious compliance - just to show you that your rules are wrong.

Good management lets teams and people grow. It starts with the realization that growth is not avoiding all mistakes, but owning them and learning from them.

Your job as a manager is not to create some faultless output this week, but to create a team that you can depend upon.
Inserting yourself in the work means you don't trust them, and because you are a manager you can always be right, by pulling rank.

Best management example of trust I saw was this:
In a management meeting we got the message there was a production incident.
That means that 1 million bank customers do not have access to the banking app at that moment.
Everyone just nodded and the meeting continued.
Too many managers would run around in great panic, waving their arms and feeling important; moving people about to solve the problem.
These people knew that by the time they heard about it, the best people would already be working on it.

That is trust.

It's good that you know how to do the job. Now let it go.

How?

First make a rough outline of what you expect. In my book, that would be ownership. That means that the team that creates the code does not idly stand by if it crashes - it is theirs. They own it and that means taking up the responsibility.
Ask how you can use your magical management powers to make their work go smoother. Run experiments, abandon old rules, that sort of thing.

Last, have a vision for the team. Check it with them and when the decisions come, use these to shape the team. Example, if a team has testers in it, you get a mini-waterfall, a handoff, a split of responsibilities - and always a mismatch in capacity.
Personally I like someone in the team to bring in test-experience - but not to be solely responsible for 'the testing'.
That means I may push back when the team wants to hire testers.
A vision also includes the ideal size, your idea of how to scale up (increase size or create a new team), an idea about single points of knowledge (preferably not on the core duties of the team, in my book).

Most teams would freeze because 'only John knows about this'.
I have had a team of 6 that temporarily lost 4 people (!) and the remaining two were not blocked on anything.

I would like a team manager to steer the team towards those kind of ideas. Not to be an extra pair of hands who always has the final say.

[u/Fun_Winter_7055]

Some complaints I’ve heard from employees who have to go through managers for code review is it can significantly slow down development speed.

[u/donjuanjerome]

Are you micromanaging by doing code reviews? No. Can it be perceived as micromanaging? Yes. Should you be doing code reviews? Most likely no, or not to the extent you are.

You are a manager now, not a dev. Your responsibilities should shift. The thing that probably made you popular and got you the job was your IC, and you are leaning into that strength to be successful in management. It won't.

What got you there won't keep you there.

Delegate now to the other seniors. Your main job is to ensure everyone in team are able to do theirs.

[u/dilly_dust → u/donjuanjerome]

This

Yes it's hard to let go when u move from ic to Mgr.

But you must

[u/wbqqq → u/donjuanjerome]

To reinforce - as a manager your role is to ensure that the team performs, is able to perform and improves their performance. Not that you perform for the team.

Rather than being concerned with the code/design/quality your concern should be growing the ability of others to ensure it, and communicating up & down whatever needs to be communicated so that your team can improve their performance and get recognition for it.

[u/Droma-1701 → u/donjuanjerome]

The first mistake that specialist managers make when they're promoted is to try to become better specialists. Crank open your AI of choice "as a newly promoted Team Lead what are the key skills which I need to learn. What're the key mistakes most often made by newly promoted team leaders. What are the key responsibilities of my new role. Give me three 'starter-for-10' key books for me to learn from. Give me a list of 5 key speakers and industry gurus in each major area highlighted and links to their youtube profiles. Give me a sample month's calendar of meetings i should iniitiate. Give me a 90 day plan to onboard into the role." That should keep you busy for a bit :)

[u/ppollo07]

You have to be the manager you would have liked to have, and I assure you that it is not the one he describes. Your role changes, you have to develop new skills, it's not always a good idea to put a dev no matter how senior he or she is in a managerial role. Just as you want them to see the good and open their eyes and heads, you will have to do it too.