[gravlaks]

What kind of micromanagement did you experience / E.g. do you have an example?

I'm in the position where I as tech lead don't fully know if I can trust my team (yet) to do the right decisions. One of the reason is that our product is quite new, and we haven't discussed developing principles yet. And some people tend to over engineer stuff all the time. But I also don't want to micromanage.

[jraph]

Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do seem like to have this kind of daily routine so your mileage may vary obviously.

Having to fit tasks in two weeks periods was a problem too, with all these ceremonial meetings where we end up having to make things up and which actually take a lot of time. Being able to give feedback is good, but I don't like to be polled every two weeks on this in a far too long meeting, and waiting the end of the sprint if something is actually wrong is not ideal neither. We ended up merging shit code if the tasks actually needed more than two weeks and artificially splitting those tasks into smaller ones is a lot of overhead and can have deleterious effect on the code architecture. I think we were also not very good at planning a bit ahead so decisions needed to be taken and validated by the boss too often, which can feel like micromanagement too.

Trusting your team about taking the right decisions is probably not an issue, if you have meetings where you make the general "big picture" (design) decisions all together. It'll probably help you notice that your team can make the good decisions too. But if you do have the big picture, it's a good thing you participate in this. I think small decisions should be left to the developers though.

Not trusting they will do their job would be an issue.

Good luck :-)

[yakubin]

> Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do like having this kind of daily routine so mileage may vary obviously.

Same here. I used to be in a team with daily stand-ups, reporting to the manager what work I did the day before, and they killed my will to work, consequently causing me to work ~3 times slower, which presumably is the opposite of the intended effect.

[ido]

The problem is that a lot of developers (especially junior ones) make shitty decisions and/or just work slowly without the accountability of having to say what they worked on (and having to explain why what they said they will “finish today” 4 times already isn’t yet finished for the 5th time).

They are not necessarily bad developers, just need the need the external motivator.

If you have 10+ years of experience and you repeatedly make shitty decisions or keep drastically underestimating your work instead of introducing accountability via daily standups you can simply be fired.

[roeles]

I have seen this happen to junior developers.

In hindsight I think it is much more effective to pair them up with a senior developer instead of waiting for a pattern to become apparent during the daily scrum.

[ido]

Ideally yes, but it’s also not that easy to find senior developers and a lot of them don’t like having to hand-hold juniors.

[BurningFrog]

The standups I've been in are about reporting to the rest of the team what you're doing.

This way, everyone has a clue what's going on, and can also chime in with advice and questions.

[yakubin]

I'm not against stand-ups per se, just against daily stand-ups. Currently I'm in a team which does three a week. That's at least tolerable, but if it was up to me, I'd opt for once a week. Daily made me feel that I had no agency over my work, that everything to the tiniest detail needed to be negotiated with someone, most often the manager. Less agency means lower engagement in work. At least for me. I do know that there is plenty of other people who are different.

[BurningFrog]

We must mean very different things by "standups".

My standup messages are mostly "I'm working on adding feature X, it's going well", or "I'm fixing bug Y, and I wonder how to handle Z".

Usually that's it. Sometimes there are questions or discussion about details. It serves to keep the team aware of what's going on.

If your team is argumentative it can drag out and be a drain. That's when it is up to the manager to break it off and move any needed discussions somewhere else. If your manager is the argumentative one... you have a bit of a problem.

[jraph]

This is also what I mean by stand-up.

These stand-ups get in the way. I'm bored when I need to listen to what people have to say, or worse, what they are making up. I'm stressed by what I need to say or make up. They take time. They often happen at a time where my productivity would be the best / when I'm in the middle of something, or else I need to rush to get on time. Or to watch for the time when we are close and interrupt everything I'm doing. This, every single day. It's fine for meaningful meetings solving real problems, but stand-ups are not this kind of meeting for me.

I very much prefer not having a daily synchronization point, and instead give status to relevant people when needed, or give my status when asked for (which is not too often, we can see what tasks is left for me in the bug tracker). If I'm blocked or if I have a question, I'll ask. If colleagues have a question, they'll ask. We have flexible hours, not at exactly the same timezone, some people are already full of important meetings. Not having a standup to babysit, to schedule, to watch for and to be stressed about is one less problem to handle.

I'm thrilled to be able to start my work day when I'm ready and not having to interrupt for this daily thing that does not seem to bring much value in the end. I'm happy to be able to have an unproductive day and make up for it the next day without nobody noticing it and without me lying about it, because in the end, it's none of nobody's business and it doesn't matter. And the day is just a bad unit of time for development tasks most of the time.

When I had to attend daily stand-ups, indeed standing-up (wtf!), I just had the impression we were (treated like) a bunch of children not able to be autonomous for a few days.

But then, it seems everybody in my current team is wired for working efficiently without this kind of things, so it works for us. We are also good at knowing what people are on to by the reading the stuff they are discussing on the chat, and the big picture, fast, weekly status update we have anyway. I don't need the details brought by the stand up, unless I do but then I will get them via efficient communication anyway.

[powerhour]

> Having to report every day during the daily stand up felt like micromanagement to me.

Agreed, and some teams go even further than that. I have to update statuses multiple times a day. If I don't, I get nagged about the status of this or that (as though I can do more than one thing at a time). I wish I could just say "I am doing A because I am waiting on B just like I was yesterday" and have it stick.

[dvtrn]

I almost want to make that painfully hackneyed “did we work together?” Joke because this was my last job. It was status update overload.

Standups daily, then we’d have weekly all hands that I had to prepare status updates for, then a weekly 1:1 with my boss that needed status updates, and then each week my team would have to type out what we accomplished at the end of the week so the Director could send it to the execs for the weekly reviews.

The result? I am giving the same status updates to the same people upwards of four to five times in a single week. There were moments when I legitimately wanted to ask my boss in a very flippant way about his note taking abilities but that wouldn’t have done much but get me in the management dog house probably.

It was a source of annoyance with every other dev I talked to about it.

[Juliate]

This is not just you.

That's a very valid and shared perception of DSMs and even Scrum in general.

For some types of projects, and for some people, it just does not work.

And when it is nonetheless forced onto them (because for some others it works, or because company policy/management dictates it) it is actually failing and working against its own principle: agility.

[kqr]

Can you prove that their "overengineering" makes things worse? And not just in the short term, but also for maintainability down the road, accounting for their developer experience and job satisfaction, etc? Otherwise maybe it's just a healthy level of engineering, knowing the details that person knows.

The management advice I was given is that if you don't first trust people, they will never get a chance to show you that they are deserving of said trust. And showing that is allowed to take some time.

Another thing I try to keep in mind is that I might not always trust each individual in their decisions, but I always trust a team decision over my own. So when in doubt, involve more people on the team.

[hallway_monitor]

Of course you can't prove that these four extra layers of abstraction will never be useful, but they aren't right now. That's why people with over 10 years in the industry are valuable - they have the intuition to see this coming.

The dev took twice as long to build the feature as they needed to, and updates to the code also take twice as long. I have seen this over and over, and GP is correct - there are some engineers who need to be coached out of overengineering.

[kqr]

My point is not that overengineering doesn't exist. My point is that if Alice says Bob is overengineering and Bob says Alice is underengineering, you don't have any evidence either way. You need to loop more people in and let both Alice and Bob air their concerns.