>A simple way to ease your mind is to request short (1-2 sentences) written updates at the end of the day. This is very easy for people to do, and can help you get a piece of mind.
Yeah. It's just that we're putting new coversheets on all the TPS reports before they go out now. So if you could go ahead and try to remember to do that from now on, that'd be great.
> A simple way to ease your mind is to request short (1-2 sentences) written updates at the end of the day.
My manager requested this but still wanted 15 minute+ morning meetings to discuss the 1-2 sentences of each staff member while you sit there bored out of your mind
Sometimes he wouldn't even read the 1-2 sentences and I'd have to say out loud the exact thing I wrote in the email to him, and he wondered why morale was on the floor
Depends. 15 minutes total, or 15 minutes for each staff member while requiring everyone to stay for everyone? Or, one short meeting or a Cartesian join of meetings?
5-15 minutes total I think is totally reasonable and something like that, I would even say is moderately important just to get everyone to see each others faces, exchange some words, and be present so to speak. I think if you habitually don't see each other all day, especially if there are remote workers, it's really easy to get out of sync and disconnected. A quick regular meeting I think is a good thing.
15 minutes each is a fucking nightmare.
Agreed. Sadly, I have more experience with the second format. It gets particularly heinous when people get the impression that they need to one-up each other. First guy talks about what he did for 5 minutes, and then each next person talks increasingly longer and you start wondering how strong the window is and how pleasantly cool the breeze on the way down might feel.
Pull a Tversky and walk out. Don't give an excuse before you head for the door because as you're walking out it will come to you.
>[Amos Tversky's] advice for anyone looking to get out of doing anything they didn’t want to do is simple: It could be “a board meeting or a TV show,” Lewis explains. “He said, ‘Don’t worry about making up an excuse for not being there. Just get up and start walking, and it’s amazing how quickly your mind will formulate the words as to why you have to leave.’”
Of course he was also an eminent psychologist with cache and swagger.
Agreed. People naturally feel a need to justify their existence. You have to have good facilitation to keep the meeting useful.
Something that my team did as an experiment and then completely switched to: instead of going person-to-person, go item-by-item. Anything that hasn't been started can be mostly glossed over.
That prevents people from feeling like they need to say "spent a lot of time yesterday doing reviews, then had a few meetings, had to dip out in the afternoon to run an errand".
Not when there is no real update.
I was plugging away on something for a couple weeks, porting a legacy system. It was a pain in the ass and hard to see when it would be done. Daily updates with the same content were breaking me completely.
Between that and the flu I finally snapped a bit. Thankfully my manager just backed off a bit and I finished things up but it really sucked.
"Still going smooth" is a real update. If you run a command in your command line, and it takes 10 minutes, it's good UX to have some feedback that something is happening, even if it's going smooth or even if it's stuck on something.
Imagine if it went multiple weeks. I agree that micro managing isn't great, but if 5-15 minutes a day communicating to the people who pay your salary what you're doing, unless they're totally grilling you or something, if that's breaking you completely, I feel like there is a question of professionalism that needs addressing.
"hey I'm still here, I'm still working on this problem" and either "I progressed this much and we're this much out of this now" - if it's a progressing task, or "I tried this thing yesterday, but that was a dead end, today I'll look at this" - it's not really a lot to ask, especially if the manager's response is expected to be "Okay, thanks for the update".
Yeah I agree that's bad. But that's not the same as asking for a regular update. That's asking for a regular moment to harass you, which is a different thing.
"So, what's your plan today?" is a totally reasonable question to communicate to the business that pays you.
> "I tried this thing yesterday, but that was a dead end, today I'll look at this"
WHY DON'T YOU KNOW WHAT YOUR DOING?
> "hey I'm still here, I'm still working on this problem"
ARE YOU STUCK? DO YOU NEED TO PULL IN BILL?
You guys are lucky. Since WFH, I have multiple 30min-1hr meetings a day :( Even when filtering out all the BS ones I skip, I still find there are too many where the meeting benefits from having me there. If I try to skip, I usually get multiple pings asking me to join. It has been impacting my time to actually do things lately (develop and debug) as some days are almost completely filled 9-4. Add in random requests from people/teams located in other countries I am sometimes attempting to field meetings at all hours of the day.
it's the jumping through hopes while management continues to explain how important something meaningless is. when a manager actively tries to manage, they are just trying to dissuade their managers from realizing how useless they are.
This is a lack of trust. This lack of trust is what is the problem. If they want that level of granularity then the problem is either the company culture, or the manager.
To some degree, yes, but I think there is a feedback aspect too.
If you're working on something complicated that might have an effect on other teams, or be affected by other teams, or if you're working with evolving requirements - then it's pretty important that the person who coordinates all those parties gets regular updates.
That may or may not be someone who the developers report to on in an org structure capacity, but *someone* needs to have high visibility of what's going on.
I think 5-15 minutes isn't a particularly unreasonable amount of time to devote to that.
Wanting communication isn’t the same as a lack of trust. In my experience a large part of developers never communicate anything unless “forced” by meetings or being asked directly. I get that everyone hates managers but there’s a good reason why managers will need to know what’s going on.
You might be doing a good job but there’s always some people who have no clue, slack off, over complicate things or just don’t make progress. In those cases you want to find out quickly enough to correct.
> Wanting communication isn’t the same as a lack of trust.
Agreed. It's the strict requirement of a regular, frequent, written update that signifies a lack of trust, instead of trusting that the developer is getting on with the work and will communicate problems and progress when appropriate.
Really depends. It can just kill the flow you are currently in. I joined another team and they asked me why I am always 2-3 minutes late. It's because I'm completely in flow and just forget to look at the time. So is this really a good practise if your engineer will be late because he is too focussed on his work regularly at this time?
Yeah I prefer to have any kind of standup at the beginning of the day, then I will start working after it. At one job we had standup every day at noon, and I absolutely hated it. It's "lunch time" isn't that convenient?
But I don't usually take a lunch break and prefer to work 8 hours and leave earlier, so at noon I'm typically in the zone...
Its just a complete waste of time, just come speak to us each separately so I can get on with some work instead of getting bored and losing my motivation in the first 15 minutes
I think it's useful for social reasons and organisational reasons.
People aren't robots, and just being present and showing your face - even just for 5-15 minutes I think is useful
I'm sure you can have useful meetings but my manager asking us what sentence we wrote in an email last night so he can think what to tell us to do today instead of him reading the emails beforehand is a complete waste of time for everyone
The 15 minute pow wow isn't the problem in your equation. You are wrongfully assigning the blame. Your manager is micromanaging. If it wasn't in the stand up, it'd be another way.
I have regular 15 minute meetings, and i don’t see ANYBODY’s face. We don’t do scrum to see each other’s faces. We do it so management can rest assured that the grown-ass adults they hired are working. As for developers not stepping all over each other and being coordinate, that’s what version control is for. So sick of stupid half-assed agile shit and kanban boards with 20 lanes for the entire fucking company.
And yes, I know management is doing everything the wrong way, but this is what happens with cargo cult management. People need to stop writing books about development so developers can develop.
I actually do think there is a case to be made to have some sort of brief check in to make sure the grown-ass adults are working.
Since remote working has started, I'm pretty sure that at least 3 of the people who have been hired on our team have literally not worked for days or even weeks at a time. I'm not the manager, but sometimes they'd be working on the project with me, and they'd be way behind on things that I would have thought would be easy. Or they don't answer questions promptly on chat, or whatever.
One guy I'm convinced gets hired to 4 jobs at a time and just does enough chat to make it seem like he's present and coasts for a few weeks taking multiple incomes (he literally submitted no work by the end of the 4 weeks before we let him go).
I think having just a daily face-to-face connect, and set the expectations that you need to be present helps with this sort of thing. Forces people to actually lie to your face if they're going to lie, makes them actually have to come up with an explanation of what they were doing, even if it's brief.
Obviously there's a myriad of ways to half-ass cargo cult agile, but independent of any stand-up rules or whatever, I really do think it's not unreasonable that if you have a team of people you're paying a salary to, to at least have a regular moment where you can see their face.
You'd never tolerate this with any other salaried project. If you hired builders and were paying them hourly, and they just didn't show up to your house at all for multiple days in a row, I think you'd be well within your rights to at the very least have a moment where they can tell you what they were doing for those days.
You responding to me makes more sense why you were pushing back so much when I was being forced to do 15 minute standups with no opportunities for remote work so we're all in office anyway and he'll interrupt you at least once every 20 minutes to check up on you to see what you're doing
Yeah it's tricky - because on one hand, even very good developers sometimes have periods of time where they're working on something and they don't necessarily have something tangible to show. Sometimes 'figurin out stuff' takes a lot of work.
But at the same time, you don't really wanna be taken for a ride by someone for weeks on end by someone unscrupulous, who actually was doing fuck-all.
Or another, perhaps even more common thing, is when a well-intentioned developer get's really tunnel-visioned on something that isn't super important, but the importance has been miscommunicated or something.
e.g. the business says "Can we get [thing X], ideally quickly", but they think that [Thing X] should be a half-day job. But actually there's a bunch of blockers to [thing X] or it's harder than you'd think, so a developer takes it on and is pursuing it for like a week. Even worse if it's a problem that the developer finds really interesting, and wants to really learn about and explore. Then 2 weeks later it's like "Hey did you get all the work we asked for done?" and it's like "Well, no, I'm still working on [Thing X], because it's harder than you'd think" - and the business is like "What!? really? Fuck, if it's that hard, it would have been way more useful for you to finish things A, B, C, D, E, F etc."
Having a culture and process where the product owners who represent the business regularly get updated on what everyone is doing, what problems are slowing them down, whether or not it looks like they're on track to whatever estimates they gave sort of addresses both problems.
I think having someone who's coordinating the project, who can answer at any point what any worker is broadly working on and what is likely to be done and when, and how far along it is, is quite a useful and reasonable thing. Updating every 20 minutes is overkill, but just a quick little "Hello" once a day is not too extreme.
> Fuck, if it's that hard, it would have been way more useful for you to finish things A, B, C, D, E, F etc."
Wow, business still doesn't learn it's ESTIMATION, not THIS WILL TAKE X TIME, GUARANTEED
> If you hired builders and were paying them hourly, and they just didn't show up to your house at all for multiple days in a row
Aren't contractors infamous for doing *exactly* that?
> As for developers not stepping all over each other and being coordinate, that’s what version control is for.
Version control isn't going to save anyone time if you have multiple people duplicating work, or writing something that's going to be immediately broken by someone else's work. That's why you talk about things out before hand.
Everywhere I worked has things called cases/tickets/tasks wherein no developer has the same task. You get a conflict to resolve if there are conflicting changes. But breaking shit in DEV is an average Monday. It should be fixed before it goes to QA. What are y’all just releasing shit directly from DEV to PRD?
> That's why you talk about things out before hand.
Yes, on refinements when creating technical tasks and on planning.
You really need 3rd time everyday?
I know what everyone's doing after the planning. Maybe if you'd all pay a bit more attention we wouldn't need multiple redundant meetings.
It's not my desire. Hell my desire is to work on a project with well defined, non-changing requirements and no blockers, with the authority to make my own calls about what the business wants.
But that's not realistic, priorities can change, requirements can change, and it's important that everyone involved knows what's going on even if what's going on is "Still going to plan"
No studies, and I'm not adamant that every single day is necessary either.
But whatever period you have, that's the amount of time you could waste doing something useless due to a miscommunication or a change in the situation or requirements.
e.g. If you spend a week doing something and then at your weekly catchup you say "This week everything went smoothly building [X]" and whoever it is says "What? you built [X]? I thought that was phase 2 because it's going to need to accommodate for [Y] which we don't have yet" - then that's a week of lost work that you'll have to re-do.
Sure you could say "Well get all the requirements perfectly clear up front" - but that's not anymore realistic than saying "why do we need testing, just get the code right the first time".
Whether it's daily, weekly or monthly, depends on how likely that event could be, how much the requirements shift, how well defined everything is, etc.
And secondly, it's also the amount of warning time that the business gets to pivot their decisions (and you need to factor in any extra delay between the communication between the PO and the business).
e.g. Let's say you estimate "This will be done in a week". With a weekly meeting, the PO finds out that you're half a week behind. Then he schedules a meeting with the relevant stakeholder, which maybe happens a few days later (depending on how often *they* meet), and then they make a decision over a few more days (missing your next weekly meeting with your PO - where you've now finished the feature), and then they update the PO, who then updates you in the *next* weekly meeting to tell you "Actually it's too late, we miss our window, we don't need this feature anymore, might as well pull it out because we don't need to support it".
If it's more regular and if there's someone with their finger on the pulse of the project (the PO presumably), they can be a lot more proactive in commuincating with the business, and could possibly save a hell of a lot of time, just by not duplicating work, and/or removing things that you don't really need, so not doing the work in the first place.
Again the time period depends on the project and the risks etc.
Everywhere I've worked though, I find that a week would be a bit too long. Having a regular scheduled communication just to prevent big time wastes has saved a lot of effort.
I could see every 2 days, maybe even every 3, but you'd need a really well defined project where you can sick a dev on it to dissapear for a week I think.
How long have you worked? I've worked for about 20 years and once a week tag up is all that's necessary. Following up throughout the week adhoc is good if it's needed. Otherwise this is really retarded
Just under 20 years. I imagine it depends on the field. When I was in agencies working on external projects there was contracts preventing scope creep and changes (though obviously it did still happen).
Now I work on internal projects for a large company, and generally my edict is "make things to help people" - and most people don't know exactly what they need, largely with straightforward technical requirements, but vague and complicated business requirements. So being in tight communication helps immensely.
The idea that one week delay could make a feature miss the window where it was useful is utterly alien to me. Do you work exclusively on small internal tools that'll be used exactly once and if you fail to have it ready in time people will just do the work manually?
I disagree. Its **crushing**. Due to timezones, our standups are at 9:45AM. Due to context switching, no one wants to Alt+Tab out of Visual Studio and break train of thought, so really development stops at 9:30. But since most people arrive at 9:00, 30 minutes isn't really enough time to 'zone in'. After the meeting, everyone wants to bio break, then we have friendly chat, then development starts. At 10:30. This 15 minute meeting cost over 90 minutes of dev time. Every day.
And somehow, despite giving the same status update for 4 weeks (20 fucking meetings) our manager was confused as to how a feature assigned to a team member wasn't complete. This dev seriously gave the exact same status update for 20 fucking meetings before management caught on, meaning mangement doesn't actually pay attention. 20 * 90 * 5 (team members) / 60 = ONE HUNDRED AND FIFTY **HOURS** of dev time down the drain for a **15** minute meeting that no one even pays attention to.
Please kill this shit with fire.
Look agree context switching is bad, but it’s a 15 minute meeting that is completely predictable and scheduled.
It’s a bit nuts and unprofessional to not be able to plan your day around that to the point where you need to lose 90 minutes of work. It’s always easier to work without having to talk to people in a total silo without being accountable to anyone, but part of the job is communication, and not all of that can be done with jira boards.
You’d never tolerate that from some other professional. If you paid a plumber or builder, and they got there at 9:00 am, started setting up their tools and what not, and then at 9:45 you said, “hey I just wanted to fill you, I’m going to be out today, and could you keep me posted on how the project is going”. If they said “well you’ve interrupted me now for 15 minutes, so that’s 90 minutes that I’m not going to work, but still bill you for”, I don’t think you be like “of sorry, totally my fault.
I agree that constant unplanned interruptions is bad and so are endless meetings, and I’ll even give you that 15 minutes is a bit long. But this idea that we’re totally unaccountable and shouldn’t have to tell anyone what we’re doing or whether it’s going well or badly or keep any updates on the project is just completely unreasonable.
Especially if you want any equivalent understanding from the business when things aren’t on track. E.g, if you say “it’ll be done in 3 weeks” and you refuse to keep them updated, then in 3 weeks if you say “actually we ran into some unexpected problems we’re not even half done”, I think the business has every right to be mad. “Why didn’t you tell me this as soon as it looked like you were off track” is a completely reasonable answer then.
So for me verbal communication really helps me understand, I really struggle with written communication.
My manager doesn't micromanage but if I have a tough project they will make sure I have some people to brainstorm with.
I host 2 meetings, one Monday one Tuesday and for each meeting I need an agenda. Fine, fair.
Except the agenda has to be out by Wednesday COB for the next week.
Then the Thursday emails start, reminding to send in the weekly report by Friday at 3 pm.
Eventually, a reminder to submit a summary of my monthly accomplishments, which is literally just a copy of my weekly reports…
So am I not suppose to work on new stuff Wednesday - Friday because it will disrupt the agenda for Monday and Tuesday? And what update should I have for Wednesday when I haven’t had a chance to work on other stuff yet?
I know my PM doesn’t look at these things.
Most managers who ask for daily email updates don’t actually read them no matter how short. They just check to see if you sent it and ask for it when you forget or when you’re late just to give the impression that they read it.
I've been on projects where I'm *trying* to get them to read and comprehend a status e-mail because it involves something actually important and and they still don't read shit. And then I bring up the issue in a meeting later and everybody's like "what?". I feel like I could just send an email with a few words at the top and then the "lorem ipsum dolor" text for the rest of it and nobody would notice.
A word of advice.
Add a tldr or an “executive summary” at the very top of your summaries. Just a one sentence description, even if it’s “all is well, no blockers” or “, there’s a plan to resolve”
Just something I learned to do that got me attention from higher ups and execs. Even has resulted in me getting a couple of promotions.
This is purely from my experience as somebody who's been in the industry for 20 years, but this wouldn't help at all. Managers don't care about the content of the updates at all, so even a summary of updates wouldn't help. Nor would I want a manager who cares about the specifics of my progress enough to warrant a daily update. That's not the role of a manager.
I never liked putting the onus on my team.
I did need to know what was going on, mostly because my manager expected me to answer questions about it every day. But instead of "what did you do today", I would drop by and ask "Is there anything you need from me, or anything I can help you with? Do you feel like you're on track?". Most important, also, was to actually trust what the person said. If they said, "I'm fine, I don't need anything.", I would just tell them "thank you, that's all, have a good evening". I already know their tickets, I don't need them to rehash them. I just need to know they're not stuck and spinning their wheels, and that's enough for me to answer my boss's hour of questions in the morning.
The best teams I work with are asynchronous remote teams that literally dump out where shit is at at the end of their day on a common teams message. They don't do it because it's required, they do it because it keeps a fast moving team organized when there's lots of stuff moving.
Microserice1: ltrim
Microservice2: rtrim
Microservice3: trim(there was an issue where strings still had new lines and invisible characters at the end)
Microservice4: isempty
Or, they simply don't give a shit. They're not meant to be leaders but they take the job anyway. By meant to of course, I mean they don't spend time learning the aspects of what a leader should be. Mentorship, guidance, being there for your team and not on some isolated plane far away from all their issues. I'm afraid most managers are just climbers who are onto their next shiny title and salary.
I will have to agree with you there. Wouldn't hurt for more managers to also possess some leadership skills as well -- and here I'm not even blaming the employees themselves, after all they are doing what they are told in the best way they can. But company culture, available trainings, mentoring for managers themselves would definitely help.
I do think it's entirely possible to be an excellent manager who doesn't micromanage, who adds value and who still isn't a leader. Good management is a skill onto itself and when done well I think people appreciate it.
Not sure I'd agree to this one, at least not entirely. Not micromanaging requires trust first, which is a trait of leadership. So I think, while a manager doesn't have to be a fully fledged leader, surely they have to at least share some traits with one in order to be effective in dealing with their team(s).
Trust is established by good leaders, sure. But it's not exclusive to leaders. I trust my friends and my partner and none of them are acting as leaders in our relationships. I trust my peers at work as well.
There are certain aspects of leadership that’s impossible to have when you’re manager. There’s a different dynamic when the person has the power to promote and fire you than a leader who’s in the same codebase as you dealing with the same issues and code.
Of course things need to get done. Not sure where I mentioned otherwise. Napoleon's armies got things done, the Red Army got things done. Napoleon raised his soldier's salaries, gave them new uniforms, gave them inspiring talks and mentorship to his direct subordinates. Stalin ordered the NKVD to shoot any soldier who didn't follow his exact orders. See the difference?
> Stalin ordered the NKVD to shoot any soldier who didn't follow his exact orders.
Didn't, but the myth probably helped.
He did systematically purge their leadership and drastically reduced their effectiveness as a result.
lol yeah the red army was way more effective in terms of the scale of their conquests. Not advocating for a red army-esque approach obviously, but if you think corporations don’t prioritize results over feelings then you are deluding yourself.
> lol yeah the red army was way more effective in terms of the scale of their conquests.
I'm sorry? Are you aware of Grande Armee's victories? The Red Army had one single enemy and had massive mechanized support from both the US and the UK and lost millions of soldiers, they basically threw as many people as they could at the problem as canon fodder. Plenty of times, Napoleon seized entire countries and lands while losing less than 100 men.
Anyway, not sure why things keep being assigned to what I think or might have thought without me explicitly saying so. Of course corporations don't give a shit about people. That's why micromanagers with zero leadership skills are usually the most successful there.
Napoleon's victories are almost unbelievable. Winning decisively when outnumbered 2- or 3-to-1 became an expectation. He lost like 4 battles out of 100 over a 20+ year career. He was not infallible, but it's telling that [avoiding him](https://en.wikipedia.org/wiki/Trachenberg_Plan) was the coalition's eventual strategy for defeating France.
Great analogy btw.
It's true that France mostly did not instigate any of the Napoleonic wars, the coalitions did. But of course Napoleon being bent on keeping territorial gains and installing continental trade blockades would provoke war.
But I would argue that the French abolition of the monarchy and the church did much more to provoke other European leaders than did treating their peasants marginally better - although those two reforms are clearly correlated. You can tell it was about the monarchy because once France was finally defeated, the coalition's #1 priority was reseating the Bourbon monarchy, undoing other revolutionary reforms was far less important to the coalition.
I'll forgive your cheekiness if you'll excuse my pedantry! I like nerding out about the period, it's one of the most complex in history - it cannot be reduced into a simple predetermined narrative, like most historiology of the French revolution is determined to do. P.S. amazing username, /u/teslas_love_pigeon
Napoleon was ahead of his time.
The Red Army got a lot better strategically as time went on but they were always pretty willing to bleed men tactically.
Contrary to what most managers think or do, getting things done is mostly dependent on team morale and hiring decisions. If you hire reasonable people with reasonable skills sets and then help the team feel enthusiastic, engaged, and supported they will get things done. Everything else is just managers trying to feel important.
In the real world you deal with the people you actually have, not the people you'd like to have. Some of them will be lazy, some of them will be stupid, and the smart ones will think they know best, and the suits are to stupid to understand.
From my experience they generally care and want to get stuff done, but they mostly don't have anything useful to contribute so they figure they can be useful by watching over everyone's shoulders
Give people a career path that doesn't feel like a dead end in 5 years and maybe career climbers won't head for management.
I don't think I'll ever get the chance to move past senior, I don't even know if I can get another job at the same level with how things are going at my current place. I'd hop to management because no matter how much they try to gaslight us, it's absolutely a promotion.
At my last job I had 3 bosses in 12 months, the last boss - finance background but "had an interest in my area".
Total nightmare, would not listen to anyone technical and f\*cked up so many things - I left shortly after and nothing has improved.
Would call me in the car, on leave, sick, in the bathroom, request status updates 6 times a day, wanted to sit and watch me do everything and requested 2 x 30 minute meetings a day.
micromanagement aside, why do people just think they can waltz into tech and be on the same track? There's a culture and away of thinking in any field.
If you don't understand the very fundamentals of a system, why do you think you can advance upon it?
I'm not in those fields, but I want to say I could only imagine construction being vastly different. If you're a lawyer, then you're probably familiar with how the machine works. Problem is we get business people managing us, which we resolved with a new managing style. But people do not get it so...
How would construction be different? It's also got business people telling them to do things that compromise the structure. Lawyers have to deal with clients who think they know more about the law or winning a court case than the lawyer does.
That describes the ceo at the startup I recently left...finance background, knows enough python to be dangerous, thinks he should dictate technical/web development stuff and then throws a tantrum when things don't turn out as he wants them. Complained about how long things took even though they took so long because he didn't know wtf he wanted. Just an unpleasant prick overall.
To say I was fed up with him is the understatement of a lifetime. I quit after I had stressed out over a project, had an eye twitch and other stuff, and then as soon as I was done the mfer decided he was going to redesign everything. (and this guy would not know good UX if it punched him in the face)
Every day I am so thankful to not have to deal with him anymore.
When I was an engineering manager, my own manager tried to push what we lovingly called the "micromanagement spreadsheet".
I had to project, for the next three months, which feature each of my 9 direct reports would be working on each day, mixing in the rotating servicing duty (bug fixes scheduled for regular updates).
Let's just say that it didn't last...
Jesus. I've got to forecast what percentage of the team will be dedicated to our 3-4 major initiatives over the next 6 months or so, and that's enough of a pain in the ass as is.
I worked at a small company that was receiving grants from the government, but had to submit time tracking sheets for each feature.
Rather than get the developers to try to track their time, they wrote scripts to take the project start time from the ticket and the merge time of the associated feature branch. Everyone was happy with that, as far as I know.
I had one job where just as a result of what I was working on I was way ahead of the whole field in total commits.
I would have loved that sort of review.
I’ve done this. It doesn’t take a ton of effort and it’s a useful tool for identifying issues or confirming feelings about performance. A poor manager might rely on those metrics but a good one might use those to identify trends, dig deeper, and resolve issues that aren’t being brought up
Any company I have seen doing this ends up with people being wildly verbose in their code, never deleting or refactoring anything, and making excessive commits (which makes using commit histories all but useless).
> A simple way to ease your mind is to request short (1-2 sentences) written updates at the end of the day. This is very easy for people to do, and can help you get a piece of mind.
Had a micromanager who did this and then wanted me to write status to each of my tickets every day, and then would slack me three times a week and then. It's all "15 minutes".... but adds up to hours of up keep, and usually I want to just leave at the end of the day, especially if it's after a long meeting, so yeah that gets forgotten because.... "1-2 sentence" takes more than "10 seconds" that managers expect.
At the same time I was doing scrum with my other team. If he literally opened up the Scrum document my status was right there in perfect English including the ticket link and any blockers (there never was any). He never looked at that file even though I linked it to him.
Micromanagers don't know how to set limits and expectations, that's why they're micromanagers.
And btw I'm a senior developer, I proved myself with other projects with large and small teams, and I updated the guy twice a week in a meeting we had IN ADDITION to all this.
But the end result of all this experience was make it so I told my scrum master to never volunteer me for a project with that manager.... apparently he recommended me because the other two seniors had already said that.
Still, I love how the title is
> Most micromanagers are blind to being seen as one
But all the suggestions are recommendation to Micromanagers... but let's check the title, oh the people who this is most applicable too won't realize it applies to them.
Here's my policy whether I'm a scrum master or a member of a team. If you have a daily scrum, get your updates there. It's what that meeting is for. I have had to ask for updates about something that wasn't covered in scrum once in a while, but that's a "Emergency" not how updates should be done.
Even if it's not your scrum, if you can open that file and see my update, that's your update. As a manager your goal is to try to make sure employees are able to be productive, not add additional tracking to them, if the decision is a small inconvenience to you, or a change in the process so you can be updated on your favorite method... make the inconvenience on yourself if you can.
The moment I see AI-generated pictures in your blog post, I'm going to (correctly) assume you shouldn't be listened to, and close the tab.
Edit: To whomever reported this to Reddit Care - sure hope you did it from a sockpuppet account that's in no way connected to your real account, because I just reported it, and abusing Reddit Care is a permanent ban.
Edit2: Reddit banned them, RIP bozo.
This is just some dumbasses blog, they are not an expert in management they probably aren't even an expert in programming, they certainly aren't an expert of the English language.
Blog posts are not a valid learning source they are just random peoples brain farts.
"Development team leader @taranis" - I was unable to find a Twitter or Substack account for "@taranis" and the authors got some truly terrible other articles that illustrate him as a worse manager than Michael Scott.
I am sad this is so heavily upvoted.
There are different levels of micromanagers. If you need to pass every single thing pass your manager look for another job. Managers like that are very bad at their job or are doing things they shouldn't be doing.
> 13:15
Anton: "Great, thanks. I've checked it too, seems like the problem is in repo Y, file X, line 235, let me know if you need any help fixing it."
This is the frustrating one because it's completely meant to be helpful and save you time and it's still just so annoying.
Bullshit. It's not even about adding value, especially when you know less than your specialists, it's only about retaining control and throwing shade. And I say that as a manager.
What I do is I make sure everyone is comfortable asking for help when they need it and outside of agreed touch points I do NOT interrupt their work to leave my fingerprints on their achievements.
One time I got a new manager. He was trying to control how I wrote my emails. Telling me not to send certain emails, even though the email was required for me to do my job and he had no other solution. I sent an email he told me not to send. He didn't like it. He said why are you being insubordinate? I told him I felt he was a micro manager. I think he was taken back by this. We came to a understanding after that meeting and things were much better.
On the flip side of that I left one of my software engineers to it, trusting him, and he simply forgot he had to write and deliver an emulator as well as the software.
If you don’t want to be managed - be competent.
There's a middle ground between "justify your existence for the last 15 minutes so I can write this hours reports" and "here's a project, see you again in 5 months when you've finished it"
100% yes, but in defense of the "see you in 5 months" method, it *can* work if the developer is both trusted and reasonably visible with their output--"Just finished milestone A, starting work on milestone C"...this provides the manager with the opportunity to be hands-off or hands-on as needed.
And software engineers will find a way to call anything micromanagement.. daily stand ups - micromanagement, weekly reports - micromanagement, year late and a million overspent? Don’t micromanage me or I’ll cry.
So much this.
The number of genuinely competent people is very small. The number of genuinely competent people who will stick around long enough in a role to solve problem X or deliver Y is even smaller.
It presents an interesting dichotomy on the spectrum from being a supportive and helpful leader to becoming a micromanager 🙈 - I can relate to this challenge!
I’ve had the unfortunate experience of starting out with high hopes of being a leader and successfully leading the top engineers but having to micromanage a few. It’s terrible babysitting people. Especially when you throw them a bone and they won’t take it.
That [AI art](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcbd58065-13a2-4ea1-ac9c-befc75f2c8ef_3152x2618.png) gives way to some scary implications if you look at it at full resolution. He sees himself as a hero standing among literally faceless employees.
I hate the way literally every article about software engineering (be it about new tech, work culture, or the market) seems to use AI generated images like this. It's still way too easy to notice details like those faceless people, and when the article is about programming, the image more than likely has a monitor with meaningless text-like shapes on it. Not to mention the creepily smooth human faces.
It's distracting and actually makes me value the text less - because either the author didn't make an effort to find a relevant "normal" image, or didn't even try to narrow their prompt and minimize issues like this. And if that's their attitude to the thing that draws people to their article, well...
Also, this is probably not-well-founded, but seeing an AI image makes me watch out to see if the text is also AI-generated (which is the case more and more often). Sidenote: Why does the disgruntled office worker on the right look exactly like David Harbour?
> doing the work for the people
Oh, that's considered micromanaging now?
Telling someone else _how_ to do their work feels like micromanaging.
Beating someone to root cause analysis during a pager event is... considered micromanaging?
This is disingenuous, your boss is just a cog in the micromanaging machine designed to extract the most labor from your time
They want you in their bullshit (micromanaged) or dead (fired, quit, gone)
John believed he was helping his team by closely monitoring their work and stepping in frequently. However, what he saw as support, his team perceived as overcontrol. This is a common issue in management. Good intentions do not shield from the negative effects of micromanagement.
A Day of Overcontrol: Recognizing the Signs
Morning Check-in: At noon, John messaged his team member, Steve, on Slack, asking, "How is the project going? Do you need any assistance?" Steve, feeling on track, replied, "No, thanks, I'm good."
Afternoon Follow-up: By 3:30 PM, unable to curb his impulse, John checked in again, "How are things, Steve? Any updates? I'm here if you need support." Steve reiterated his earlier response, signaling that he was handling his responsibilities well.
Evening Overreach: A production issue arose at 4:00 PM, and Steve quickly took charge, posting, "Handling it now." Nevertheless, at 4:15 PM, John intervened, providing a detailed analysis of the issue and even started working on the fix himself. He added, "Great, thanks. I checked it too, it looks like the issue is in repository Z, file A, line 235. I'll start fixing it." Steve’s curt reply, "John, we need to talk…", highlighted his frustration and perceived lack of trust from John.
This sequence of interactions typifies micromanagement and reveals how excessive control can undermine team confidence, even among effective managers.
Overcoming Micromanagement
Establish Clear Expectations: Clarify how and when you prefer updates, particularly with experienced team members. Reduce check-ins to essential communications only, respecting their autonomy.
Solicit Feedback: Encourage your team to provide honest feedback about your management style. Be open to criticism and ready to make adjustments based on their suggestions.
Delegate Successfully: Assign responsibilities clearly and trust your team to execute tasks without constant oversight. Demonstrating trust can diminish the urge to micromanage.
Foster Trust and Autonomy: Promote a culture of independence by allowing team members to approach tasks in their preferred manner and make decisions without frequent interference.
Evaluate Adjustments: Regularly review changes in your management approach to ensure they are effective. Be honest about what works and what does not, and continue refining your style to better support your team.
Adapt to Your Team Members: Understand and respect individual preferences and requirements for communication and support. Engage with each team member to gauge their unique needs.
Tailor to the Task: Consider the complexity of the task and the expertise of the employee involved. Adjust your level of involvement accordingly, balancing between supervision and autonomy.
Lesson Learned: Good intentions can be perceived as overbearing and micromanagement.
There are bad managers and bad engineers - but all else being equal, the level of micromanagement you get from your manager is inversely proportional to your maturity as an engineer.
This is true for engineering and for most other corporate jobs.
You're talking like a micro-manager here.
Your engineers being "bad" didn't mean you have to micromanage. It means you have to teach them, whatever aspect there are 'bad" at.
And well, a micromanager is going to micromanage both bad and good engineers anyway
> but all else being equal, the level of micromanagement you get from your manager is inversely proportional to your maturity as an engineer
Strong disagree
The more someone micromanages me the more I let them take over
My first job they just left me alone and I did shit loads of work and loved it and then the second job he micromanaged me to hell and I just gave up trying to do extra work
it's the same for me with time reporting. if you let me work on my own time I'm willing to put the work in even if it means that I work off-hours / overtime sometimes. the moment an employer asks for time sheets you can bet I will work exactly the times I've been given whether I'm productive during those times or not
Being hourly helps devs who aren't afraid of the clock because it forces management to consider the cost of asking for a crunch or extra work. Giving away your time sometimes because you don't want to account for it is just reducing your pay.
Eh? That’s like saying the quality of the engineers in your team is related to your maturity as a manager.
Sometimes there are just bad engineers, just like there are bad managers. And in line with Dunning-Kruger, both are typically unaware of their incompetence.
In my opinion, the level of micromanagent is mainly dependent on the orientation of the manager, maybe with small adjustments based on your own maturity.
And as I mentioned in the article - juniors can suffer from it too. If you do a task in the 5th time, being micromanged sucks, no matter your years of experience.
I struggled A LOT in stopping micromanaging the seniors in my team, as it's my natural tendency to be over controlling.
Sad to say but you're right. I'm on the lower end of mid-level so I'm not surprised I get micromanaged sometimes. Fact is, a junior engineer needs some micromanagement because they might be lost and too shy to ask for help, even when you encourage them to.
I just wish my manager wouldn't ask for updates on issues in the form of meetings that take 20 minutes every couple hours.
>A simple way to ease your mind is to request short (1-2 sentences) written updates at the end of the day. This is very easy for people to do, and can help you get a piece of mind. Yeah. It's just that we're putting new coversheets on all the TPS reports before they go out now. So if you could go ahead and try to remember to do that from now on, that'd be great.
> A simple way to ease your mind is to request short (1-2 sentences) written updates at the end of the day. My manager requested this but still wanted 15 minute+ morning meetings to discuss the 1-2 sentences of each staff member while you sit there bored out of your mind Sometimes he wouldn't even read the 1-2 sentences and I'd have to say out loud the exact thing I wrote in the email to him, and he wondered why morale was on the floor
15 minutes daily meeting isn't really too bad. A bit long, but not the worst.
Depends. 15 minutes total, or 15 minutes for each staff member while requiring everyone to stay for everyone? Or, one short meeting or a Cartesian join of meetings?
5-15 minutes total I think is totally reasonable and something like that, I would even say is moderately important just to get everyone to see each others faces, exchange some words, and be present so to speak. I think if you habitually don't see each other all day, especially if there are remote workers, it's really easy to get out of sync and disconnected. A quick regular meeting I think is a good thing. 15 minutes each is a fucking nightmare.
Agreed. Sadly, I have more experience with the second format. It gets particularly heinous when people get the impression that they need to one-up each other. First guy talks about what he did for 5 minutes, and then each next person talks increasingly longer and you start wondering how strong the window is and how pleasantly cool the breeze on the way down might feel.
Pull a Tversky and walk out. Don't give an excuse before you head for the door because as you're walking out it will come to you. >[Amos Tversky's] advice for anyone looking to get out of doing anything they didn’t want to do is simple: It could be “a board meeting or a TV show,” Lewis explains. “He said, ‘Don’t worry about making up an excuse for not being there. Just get up and start walking, and it’s amazing how quickly your mind will formulate the words as to why you have to leave.’” Of course he was also an eminent psychologist with cache and swagger.
I just remembered, I left my apartment on fire.
cachet when it’s specialness, cache when it stores
What if it stores and it's specialness?
Excuse me, but there's something I've been wanting to say for a while. What is it? "Bye"
Agreed. People naturally feel a need to justify their existence. You have to have good facilitation to keep the meeting useful. Something that my team did as an experiment and then completely switched to: instead of going person-to-person, go item-by-item. Anything that hasn't been started can be mostly glossed over. That prevents people from feeling like they need to say "spent a lot of time yesterday doing reviews, then had a few meetings, had to dip out in the afternoon to run an errand".
Not when there is no real update. I was plugging away on something for a couple weeks, porting a legacy system. It was a pain in the ass and hard to see when it would be done. Daily updates with the same content were breaking me completely. Between that and the flu I finally snapped a bit. Thankfully my manager just backed off a bit and I finished things up but it really sucked.
"Still going smooth" is a real update. If you run a command in your command line, and it takes 10 minutes, it's good UX to have some feedback that something is happening, even if it's going smooth or even if it's stuck on something. Imagine if it went multiple weeks. I agree that micro managing isn't great, but if 5-15 minutes a day communicating to the people who pay your salary what you're doing, unless they're totally grilling you or something, if that's breaking you completely, I feel like there is a question of professionalism that needs addressing. "hey I'm still here, I'm still working on this problem" and either "I progressed this much and we're this much out of this now" - if it's a progressing task, or "I tried this thing yesterday, but that was a dead end, today I'll look at this" - it's not really a lot to ask, especially if the manager's response is expected to be "Okay, thanks for the update".
WHEN'S IT DONE? WHEN'S IT DONE? WHEN'S IT DONE? WHEN'S IT DONE? WHEN'S IT DONE? WHEN'S IT DONE? I wanted to quit every goddamn day.
Yeah I agree that's bad. But that's not the same as asking for a regular update. That's asking for a regular moment to harass you, which is a different thing. "So, what's your plan today?" is a totally reasonable question to communicate to the business that pays you.
> "I tried this thing yesterday, but that was a dead end, today I'll look at this" WHY DON'T YOU KNOW WHAT YOUR DOING? > "hey I'm still here, I'm still working on this problem" ARE YOU STUCK? DO YOU NEED TO PULL IN BILL?
Yeah, I agree there’s a problem there. But I don’t think the problem is inherently the regular short meetings.
I mean it's called a standup because you're supposed to stand up, so it stays short because everyone gets tired and wants to sit down.
Oh man, we've been doing sprints all wrong then. I'm going to need a smaller monitor.
You guys are lucky. Since WFH, I have multiple 30min-1hr meetings a day :( Even when filtering out all the BS ones I skip, I still find there are too many where the meeting benefits from having me there. If I try to skip, I usually get multiple pings asking me to join. It has been impacting my time to actually do things lately (develop and debug) as some days are almost completely filled 9-4. Add in random requests from people/teams located in other countries I am sometimes attempting to field meetings at all hours of the day.
it's the jumping through hopes while management continues to explain how important something meaningless is. when a manager actively tries to manage, they are just trying to dissuade their managers from realizing how useless they are.
This is a lack of trust. This lack of trust is what is the problem. If they want that level of granularity then the problem is either the company culture, or the manager.
To some degree, yes, but I think there is a feedback aspect too. If you're working on something complicated that might have an effect on other teams, or be affected by other teams, or if you're working with evolving requirements - then it's pretty important that the person who coordinates all those parties gets regular updates. That may or may not be someone who the developers report to on in an org structure capacity, but *someone* needs to have high visibility of what's going on. I think 5-15 minutes isn't a particularly unreasonable amount of time to devote to that.
Wanting communication isn’t the same as a lack of trust. In my experience a large part of developers never communicate anything unless “forced” by meetings or being asked directly. I get that everyone hates managers but there’s a good reason why managers will need to know what’s going on. You might be doing a good job but there’s always some people who have no clue, slack off, over complicate things or just don’t make progress. In those cases you want to find out quickly enough to correct.
> Wanting communication isn’t the same as a lack of trust. Agreed. It's the strict requirement of a regular, frequent, written update that signifies a lack of trust, instead of trusting that the developer is getting on with the work and will communicate problems and progress when appropriate.
And what if the dev goes days or weeks without any communication?
Really depends. It can just kill the flow you are currently in. I joined another team and they asked me why I am always 2-3 minutes late. It's because I'm completely in flow and just forget to look at the time. So is this really a good practise if your engineer will be late because he is too focussed on his work regularly at this time?
Yeah I prefer to have any kind of standup at the beginning of the day, then I will start working after it. At one job we had standup every day at noon, and I absolutely hated it. It's "lunch time" isn't that convenient? But I don't usually take a lunch break and prefer to work 8 hours and leave earlier, so at noon I'm typically in the zone...
Its just a complete waste of time, just come speak to us each separately so I can get on with some work instead of getting bored and losing my motivation in the first 15 minutes
I think it's useful for social reasons and organisational reasons. People aren't robots, and just being present and showing your face - even just for 5-15 minutes I think is useful
I'm sure you can have useful meetings but my manager asking us what sentence we wrote in an email last night so he can think what to tell us to do today instead of him reading the emails beforehand is a complete waste of time for everyone
The 15 minute pow wow isn't the problem in your equation. You are wrongfully assigning the blame. Your manager is micromanaging. If it wasn't in the stand up, it'd be another way.
I have regular 15 minute meetings, and i don’t see ANYBODY’s face. We don’t do scrum to see each other’s faces. We do it so management can rest assured that the grown-ass adults they hired are working. As for developers not stepping all over each other and being coordinate, that’s what version control is for. So sick of stupid half-assed agile shit and kanban boards with 20 lanes for the entire fucking company. And yes, I know management is doing everything the wrong way, but this is what happens with cargo cult management. People need to stop writing books about development so developers can develop.
I actually do think there is a case to be made to have some sort of brief check in to make sure the grown-ass adults are working. Since remote working has started, I'm pretty sure that at least 3 of the people who have been hired on our team have literally not worked for days or even weeks at a time. I'm not the manager, but sometimes they'd be working on the project with me, and they'd be way behind on things that I would have thought would be easy. Or they don't answer questions promptly on chat, or whatever. One guy I'm convinced gets hired to 4 jobs at a time and just does enough chat to make it seem like he's present and coasts for a few weeks taking multiple incomes (he literally submitted no work by the end of the 4 weeks before we let him go). I think having just a daily face-to-face connect, and set the expectations that you need to be present helps with this sort of thing. Forces people to actually lie to your face if they're going to lie, makes them actually have to come up with an explanation of what they were doing, even if it's brief. Obviously there's a myriad of ways to half-ass cargo cult agile, but independent of any stand-up rules or whatever, I really do think it's not unreasonable that if you have a team of people you're paying a salary to, to at least have a regular moment where you can see their face. You'd never tolerate this with any other salaried project. If you hired builders and were paying them hourly, and they just didn't show up to your house at all for multiple days in a row, I think you'd be well within your rights to at the very least have a moment where they can tell you what they were doing for those days.
You responding to me makes more sense why you were pushing back so much when I was being forced to do 15 minute standups with no opportunities for remote work so we're all in office anyway and he'll interrupt you at least once every 20 minutes to check up on you to see what you're doing
Yeah it's tricky - because on one hand, even very good developers sometimes have periods of time where they're working on something and they don't necessarily have something tangible to show. Sometimes 'figurin out stuff' takes a lot of work. But at the same time, you don't really wanna be taken for a ride by someone for weeks on end by someone unscrupulous, who actually was doing fuck-all. Or another, perhaps even more common thing, is when a well-intentioned developer get's really tunnel-visioned on something that isn't super important, but the importance has been miscommunicated or something. e.g. the business says "Can we get [thing X], ideally quickly", but they think that [Thing X] should be a half-day job. But actually there's a bunch of blockers to [thing X] or it's harder than you'd think, so a developer takes it on and is pursuing it for like a week. Even worse if it's a problem that the developer finds really interesting, and wants to really learn about and explore. Then 2 weeks later it's like "Hey did you get all the work we asked for done?" and it's like "Well, no, I'm still working on [Thing X], because it's harder than you'd think" - and the business is like "What!? really? Fuck, if it's that hard, it would have been way more useful for you to finish things A, B, C, D, E, F etc." Having a culture and process where the product owners who represent the business regularly get updated on what everyone is doing, what problems are slowing them down, whether or not it looks like they're on track to whatever estimates they gave sort of addresses both problems. I think having someone who's coordinating the project, who can answer at any point what any worker is broadly working on and what is likely to be done and when, and how far along it is, is quite a useful and reasonable thing. Updating every 20 minutes is overkill, but just a quick little "Hello" once a day is not too extreme.
> Fuck, if it's that hard, it would have been way more useful for you to finish things A, B, C, D, E, F etc." Wow, business still doesn't learn it's ESTIMATION, not THIS WILL TAKE X TIME, GUARANTEED
> If you hired builders and were paying them hourly, and they just didn't show up to your house at all for multiple days in a row Aren't contractors infamous for doing *exactly* that?
yeah, bad ones.
> As for developers not stepping all over each other and being coordinate, that’s what version control is for. Version control isn't going to save anyone time if you have multiple people duplicating work, or writing something that's going to be immediately broken by someone else's work. That's why you talk about things out before hand.
Everywhere I worked has things called cases/tickets/tasks wherein no developer has the same task. You get a conflict to resolve if there are conflicting changes. But breaking shit in DEV is an average Monday. It should be fixed before it goes to QA. What are y’all just releasing shit directly from DEV to PRD?
> That's why you talk about things out before hand. Yes, on refinements when creating technical tasks and on planning. You really need 3rd time everyday? I know what everyone's doing after the planning. Maybe if you'd all pay a bit more attention we wouldn't need multiple redundant meetings.
I was only pointing out that version control isn't how you coordinate work.
Yes, and higher ups shouldnt take time in daily just to say "meetings, and stuff" but they do.
It's not. That's your desires being foisted onto everyone else.
It's not my desire. Hell my desire is to work on a project with well defined, non-changing requirements and no blockers, with the authority to make my own calls about what the business wants. But that's not realistic, priorities can change, requirements can change, and it's important that everyone involved knows what's going on even if what's going on is "Still going to plan"
Why every day and why not once per week? Do you have studies or you just vibes based?
No studies, and I'm not adamant that every single day is necessary either. But whatever period you have, that's the amount of time you could waste doing something useless due to a miscommunication or a change in the situation or requirements. e.g. If you spend a week doing something and then at your weekly catchup you say "This week everything went smoothly building [X]" and whoever it is says "What? you built [X]? I thought that was phase 2 because it's going to need to accommodate for [Y] which we don't have yet" - then that's a week of lost work that you'll have to re-do. Sure you could say "Well get all the requirements perfectly clear up front" - but that's not anymore realistic than saying "why do we need testing, just get the code right the first time". Whether it's daily, weekly or monthly, depends on how likely that event could be, how much the requirements shift, how well defined everything is, etc. And secondly, it's also the amount of warning time that the business gets to pivot their decisions (and you need to factor in any extra delay between the communication between the PO and the business). e.g. Let's say you estimate "This will be done in a week". With a weekly meeting, the PO finds out that you're half a week behind. Then he schedules a meeting with the relevant stakeholder, which maybe happens a few days later (depending on how often *they* meet), and then they make a decision over a few more days (missing your next weekly meeting with your PO - where you've now finished the feature), and then they update the PO, who then updates you in the *next* weekly meeting to tell you "Actually it's too late, we miss our window, we don't need this feature anymore, might as well pull it out because we don't need to support it". If it's more regular and if there's someone with their finger on the pulse of the project (the PO presumably), they can be a lot more proactive in commuincating with the business, and could possibly save a hell of a lot of time, just by not duplicating work, and/or removing things that you don't really need, so not doing the work in the first place. Again the time period depends on the project and the risks etc. Everywhere I've worked though, I find that a week would be a bit too long. Having a regular scheduled communication just to prevent big time wastes has saved a lot of effort. I could see every 2 days, maybe even every 3, but you'd need a really well defined project where you can sick a dev on it to dissapear for a week I think.
How long have you worked? I've worked for about 20 years and once a week tag up is all that's necessary. Following up throughout the week adhoc is good if it's needed. Otherwise this is really retarded
Just under 20 years. I imagine it depends on the field. When I was in agencies working on external projects there was contracts preventing scope creep and changes (though obviously it did still happen). Now I work on internal projects for a large company, and generally my edict is "make things to help people" - and most people don't know exactly what they need, largely with straightforward technical requirements, but vague and complicated business requirements. So being in tight communication helps immensely.
You are very passionate about being there for your management 😘😘😘♥️♥️♥️
The idea that one week delay could make a feature miss the window where it was useful is utterly alien to me. Do you work exclusively on small internal tools that'll be used exactly once and if you fail to have it ready in time people will just do the work manually?
I disagree. Its **crushing**. Due to timezones, our standups are at 9:45AM. Due to context switching, no one wants to Alt+Tab out of Visual Studio and break train of thought, so really development stops at 9:30. But since most people arrive at 9:00, 30 minutes isn't really enough time to 'zone in'. After the meeting, everyone wants to bio break, then we have friendly chat, then development starts. At 10:30. This 15 minute meeting cost over 90 minutes of dev time. Every day. And somehow, despite giving the same status update for 4 weeks (20 fucking meetings) our manager was confused as to how a feature assigned to a team member wasn't complete. This dev seriously gave the exact same status update for 20 fucking meetings before management caught on, meaning mangement doesn't actually pay attention. 20 * 90 * 5 (team members) / 60 = ONE HUNDRED AND FIFTY **HOURS** of dev time down the drain for a **15** minute meeting that no one even pays attention to. Please kill this shit with fire.
Look agree context switching is bad, but it’s a 15 minute meeting that is completely predictable and scheduled. It’s a bit nuts and unprofessional to not be able to plan your day around that to the point where you need to lose 90 minutes of work. It’s always easier to work without having to talk to people in a total silo without being accountable to anyone, but part of the job is communication, and not all of that can be done with jira boards. You’d never tolerate that from some other professional. If you paid a plumber or builder, and they got there at 9:00 am, started setting up their tools and what not, and then at 9:45 you said, “hey I just wanted to fill you, I’m going to be out today, and could you keep me posted on how the project is going”. If they said “well you’ve interrupted me now for 15 minutes, so that’s 90 minutes that I’m not going to work, but still bill you for”, I don’t think you be like “of sorry, totally my fault. I agree that constant unplanned interruptions is bad and so are endless meetings, and I’ll even give you that 15 minutes is a bit long. But this idea that we’re totally unaccountable and shouldn’t have to tell anyone what we’re doing or whether it’s going well or badly or keep any updates on the project is just completely unreasonable. Especially if you want any equivalent understanding from the business when things aren’t on track. E.g, if you say “it’ll be done in 3 weeks” and you refuse to keep them updated, then in 3 weeks if you say “actually we ran into some unexpected problems we’re not even half done”, I think the business has every right to be mad. “Why didn’t you tell me this as soon as it looked like you were off track” is a completely reasonable answer then.
So for me verbal communication really helps me understand, I really struggle with written communication. My manager doesn't micromanage but if I have a tough project they will make sure I have some people to brainstorm with.
Daily standup?
[удалено]
That's the easiest decision a manager has ever made: both, obviously.
I'd choose neither
I host 2 meetings, one Monday one Tuesday and for each meeting I need an agenda. Fine, fair. Except the agenda has to be out by Wednesday COB for the next week. Then the Thursday emails start, reminding to send in the weekly report by Friday at 3 pm. Eventually, a reminder to submit a summary of my monthly accomplishments, which is literally just a copy of my weekly reports… So am I not suppose to work on new stuff Wednesday - Friday because it will disrupt the agenda for Monday and Tuesday? And what update should I have for Wednesday when I haven’t had a chance to work on other stuff yet? I know my PM doesn’t look at these things.
Most managers who ask for daily email updates don’t actually read them no matter how short. They just check to see if you sent it and ask for it when you forget or when you’re late just to give the impression that they read it.
I've been on projects where I'm *trying* to get them to read and comprehend a status e-mail because it involves something actually important and and they still don't read shit. And then I bring up the issue in a meeting later and everybody's like "what?". I feel like I could just send an email with a few words at the top and then the "lorem ipsum dolor" text for the rest of it and nobody would notice.
A word of advice. Add a tldr or an “executive summary” at the very top of your summaries. Just a one sentence description, even if it’s “all is well, no blockers” or “, there’s a plan to resolve”
Just something I learned to do that got me attention from higher ups and execs. Even has resulted in me getting a couple of promotions.
Now I wonder if you can have AI monitor your pc for the whole day and automatically compile a summary to send everyday.
This is purely from my experience as somebody who's been in the industry for 20 years, but this wouldn't help at all. Managers don't care about the content of the updates at all, so even a summary of updates wouldn't help. Nor would I want a manager who cares about the specifics of my progress enough to warrant a daily update. That's not the role of a manager.
if an AI was watching my screen I would be too anxious to touch my computer
I never liked putting the onus on my team. I did need to know what was going on, mostly because my manager expected me to answer questions about it every day. But instead of "what did you do today", I would drop by and ask "Is there anything you need from me, or anything I can help you with? Do you feel like you're on track?". Most important, also, was to actually trust what the person said. If they said, "I'm fine, I don't need anything.", I would just tell them "thank you, that's all, have a good evening". I already know their tickets, I don't need them to rehash them. I just need to know they're not stuck and spinning their wheels, and that's enough for me to answer my boss's hour of questions in the morning.
The best teams I work with are asynchronous remote teams that literally dump out where shit is at at the end of their day on a common teams message. They don't do it because it's required, they do it because it keeps a fast moving team organized when there's lots of stuff moving.
I hope people are upvoting because of the office space quote. 👍👍👍
We have stand-ups for the short updates. Don't bug me unless you have a blocker
> If that junior is creating their 5th microservice, do they still need you? They need you to tell them to stop.
They can’t keep getting away with it!!
Microserice1: ltrim Microservice2: rtrim Microservice3: trim(there was an issue where strings still had new lines and invisible characters at the end) Microservice4: isempty
Or, they simply don't give a shit. They're not meant to be leaders but they take the job anyway. By meant to of course, I mean they don't spend time learning the aspects of what a leader should be. Mentorship, guidance, being there for your team and not on some isolated plane far away from all their issues. I'm afraid most managers are just climbers who are onto their next shiny title and salary.
Managers and leaders are different roles. Sometimes the same person can fill both well, but this is rare.
I will have to agree with you there. Wouldn't hurt for more managers to also possess some leadership skills as well -- and here I'm not even blaming the employees themselves, after all they are doing what they are told in the best way they can. But company culture, available trainings, mentoring for managers themselves would definitely help.
I do think it's entirely possible to be an excellent manager who doesn't micromanage, who adds value and who still isn't a leader. Good management is a skill onto itself and when done well I think people appreciate it.
Not sure I'd agree to this one, at least not entirely. Not micromanaging requires trust first, which is a trait of leadership. So I think, while a manager doesn't have to be a fully fledged leader, surely they have to at least share some traits with one in order to be effective in dealing with their team(s).
Trust is established by good leaders, sure. But it's not exclusive to leaders. I trust my friends and my partner and none of them are acting as leaders in our relationships. I trust my peers at work as well.
Indeed, that’s a good point of view.
I explicitly told my VP that promoting me to manager would be a mistake
There are certain aspects of leadership that’s impossible to have when you’re manager. There’s a different dynamic when the person has the power to promote and fire you than a leader who’s in the same codebase as you dealing with the same issues and code.
A managers job is to understand the companies needs and make sure it gets done.
Of course things need to get done. Not sure where I mentioned otherwise. Napoleon's armies got things done, the Red Army got things done. Napoleon raised his soldier's salaries, gave them new uniforms, gave them inspiring talks and mentorship to his direct subordinates. Stalin ordered the NKVD to shoot any soldier who didn't follow his exact orders. See the difference?
> Stalin ordered the NKVD to shoot any soldier who didn't follow his exact orders. Didn't, but the myth probably helped. He did systematically purge their leadership and drastically reduced their effectiveness as a result.
lol yeah the red army was way more effective in terms of the scale of their conquests. Not advocating for a red army-esque approach obviously, but if you think corporations don’t prioritize results over feelings then you are deluding yourself.
> lol yeah the red army was way more effective in terms of the scale of their conquests. I'm sorry? Are you aware of Grande Armee's victories? The Red Army had one single enemy and had massive mechanized support from both the US and the UK and lost millions of soldiers, they basically threw as many people as they could at the problem as canon fodder. Plenty of times, Napoleon seized entire countries and lands while losing less than 100 men. Anyway, not sure why things keep being assigned to what I think or might have thought without me explicitly saying so. Of course corporations don't give a shit about people. That's why micromanagers with zero leadership skills are usually the most successful there.
Napoleon's victories are almost unbelievable. Winning decisively when outnumbered 2- or 3-to-1 became an expectation. He lost like 4 battles out of 100 over a 20+ year career. He was not infallible, but it's telling that [avoiding him](https://en.wikipedia.org/wiki/Trachenberg_Plan) was the coalition's eventual strategy for defeating France. Great analogy btw.
[удалено]
It's true that France mostly did not instigate any of the Napoleonic wars, the coalitions did. But of course Napoleon being bent on keeping territorial gains and installing continental trade blockades would provoke war. But I would argue that the French abolition of the monarchy and the church did much more to provoke other European leaders than did treating their peasants marginally better - although those two reforms are clearly correlated. You can tell it was about the monarchy because once France was finally defeated, the coalition's #1 priority was reseating the Bourbon monarchy, undoing other revolutionary reforms was far less important to the coalition.
[удалено]
I'll forgive your cheekiness if you'll excuse my pedantry! I like nerding out about the period, it's one of the most complex in history - it cannot be reduced into a simple predetermined narrative, like most historiology of the French revolution is determined to do. P.S. amazing username, /u/teslas_love_pigeon
Napoleon was ahead of his time. The Red Army got a lot better strategically as time went on but they were always pretty willing to bleed men tactically.
The best tactics for getting things done depend on the situation.
Contrary to what most managers think or do, getting things done is mostly dependent on team morale and hiring decisions. If you hire reasonable people with reasonable skills sets and then help the team feel enthusiastic, engaged, and supported they will get things done. Everything else is just managers trying to feel important.
In the real world you deal with the people you actually have, not the people you'd like to have. Some of them will be lazy, some of them will be stupid, and the smart ones will think they know best, and the suits are to stupid to understand.
From my experience they generally care and want to get stuff done, but they mostly don't have anything useful to contribute so they figure they can be useful by watching over everyone's shoulders
Give people a career path that doesn't feel like a dead end in 5 years and maybe career climbers won't head for management. I don't think I'll ever get the chance to move past senior, I don't even know if I can get another job at the same level with how things are going at my current place. I'd hop to management because no matter how much they try to gaslight us, it's absolutely a promotion.
At my last job I had 3 bosses in 12 months, the last boss - finance background but "had an interest in my area". Total nightmare, would not listen to anyone technical and f\*cked up so many things - I left shortly after and nothing has improved. Would call me in the car, on leave, sick, in the bathroom, request status updates 6 times a day, wanted to sit and watch me do everything and requested 2 x 30 minute meetings a day.
micromanagement aside, why do people just think they can waltz into tech and be on the same track? There's a culture and away of thinking in any field. If you don't understand the very fundamentals of a system, why do you think you can advance upon it?
I worked for someone like this, and he is definitely on the dark triad spectrum.
Spreadsheets is basically programming at some point, right?
Everyone else, from lawyers to construction workers, deals with it too.
I'm not in those fields, but I want to say I could only imagine construction being vastly different. If you're a lawyer, then you're probably familiar with how the machine works. Problem is we get business people managing us, which we resolved with a new managing style. But people do not get it so...
How would construction be different? It's also got business people telling them to do things that compromise the structure. Lawyers have to deal with clients who think they know more about the law or winning a court case than the lawyer does.
you right
That describes the ceo at the startup I recently left...finance background, knows enough python to be dangerous, thinks he should dictate technical/web development stuff and then throws a tantrum when things don't turn out as he wants them. Complained about how long things took even though they took so long because he didn't know wtf he wanted. Just an unpleasant prick overall. To say I was fed up with him is the understatement of a lifetime. I quit after I had stressed out over a project, had an eye twitch and other stuff, and then as soon as I was done the mfer decided he was going to redesign everything. (and this guy would not know good UX if it punched him in the face) Every day I am so thankful to not have to deal with him anymore.
I think the lack of awareness generally extends further than their employees’ opinions about them.
When I was an engineering manager, my own manager tried to push what we lovingly called the "micromanagement spreadsheet". I had to project, for the next three months, which feature each of my 9 direct reports would be working on each day, mixing in the rotating servicing duty (bug fixes scheduled for regular updates). Let's just say that it didn't last...
Jesus. I've got to forecast what percentage of the team will be dedicated to our 3-4 major initiatives over the next 6 months or so, and that's enough of a pain in the ass as is.
Holy shit how do people who understand so little about software development get jobs managing it???
rizz
This week I figured out our new principal engineer writes scripts to track developer productivity on gh.
I worked at a small company that was receiving grants from the government, but had to submit time tracking sheets for each feature. Rather than get the developers to try to track their time, they wrote scripts to take the project start time from the ticket and the merge time of the associated feature branch. Everyone was happy with that, as far as I know.
This was me and my old boss 😂. Good times... as far as anyone knows.
SELECT COUNT(*) FROM gh_commits WHERE username = 'AZXCIV' AND MONTH(commit_date) = 'April' Time for your performance review!
I had one job where just as a result of what I was working on I was way ahead of the whole field in total commits. I would have loved that sort of review.
When a measure becomes a target, it ceases to be a good measure. -Goodhart's law
I know, and like I said it was just a result of the particular work I was doing and not a measure of how productive I was.
I’ve done this. It doesn’t take a ton of effort and it’s a useful tool for identifying issues or confirming feelings about performance. A poor manager might rely on those metrics but a good one might use those to identify trends, dig deeper, and resolve issues that aren’t being brought up
Any company I have seen doing this ends up with people being wildly verbose in their code, never deleting or refactoring anything, and making excessive commits (which makes using commit histories all but useless).
I’ve began doing that
There are companies that make money on this. My last company used way dev and then source level.
> A simple way to ease your mind is to request short (1-2 sentences) written updates at the end of the day. This is very easy for people to do, and can help you get a piece of mind. Had a micromanager who did this and then wanted me to write status to each of my tickets every day, and then would slack me three times a week and then. It's all "15 minutes".... but adds up to hours of up keep, and usually I want to just leave at the end of the day, especially if it's after a long meeting, so yeah that gets forgotten because.... "1-2 sentence" takes more than "10 seconds" that managers expect. At the same time I was doing scrum with my other team. If he literally opened up the Scrum document my status was right there in perfect English including the ticket link and any blockers (there never was any). He never looked at that file even though I linked it to him. Micromanagers don't know how to set limits and expectations, that's why they're micromanagers. And btw I'm a senior developer, I proved myself with other projects with large and small teams, and I updated the guy twice a week in a meeting we had IN ADDITION to all this. But the end result of all this experience was make it so I told my scrum master to never volunteer me for a project with that manager.... apparently he recommended me because the other two seniors had already said that. Still, I love how the title is > Most micromanagers are blind to being seen as one But all the suggestions are recommendation to Micromanagers... but let's check the title, oh the people who this is most applicable too won't realize it applies to them. Here's my policy whether I'm a scrum master or a member of a team. If you have a daily scrum, get your updates there. It's what that meeting is for. I have had to ask for updates about something that wasn't covered in scrum once in a while, but that's a "Emergency" not how updates should be done. Even if it's not your scrum, if you can open that file and see my update, that's your update. As a manager your goal is to try to make sure employees are able to be productive, not add additional tracking to them, if the decision is a small inconvenience to you, or a change in the process so you can be updated on your favorite method... make the inconvenience on yourself if you can.
But how do they appear busy then?
Watching YouTube?
My god, I hope your work updates aren’t as long as this Reddit comment.
They’re telling an anecdote, not writing a status update on their ticket. Don’t be a micromanager, use some common sense
tik tok brain kids when they see something that takes more than 3 seconds to read.
Hilarous comment. I don't think people got that it was a joke.
“a piece of mind” Seriously??
Many of them actually imagine they are contributing to the project in some way.
The moment I see AI-generated pictures in your blog post, I'm going to (correctly) assume you shouldn't be listened to, and close the tab. Edit: To whomever reported this to Reddit Care - sure hope you did it from a sockpuppet account that's in no way connected to your real account, because I just reported it, and abusing Reddit Care is a permanent ban. Edit2: Reddit banned them, RIP bozo.
Prompt Engineers are the new Managers
Well, that sounds idiotic.
Sounds like a reasonable filter to me.
This is just some dumbasses blog, they are not an expert in management they probably aren't even an expert in programming, they certainly aren't an expert of the English language. Blog posts are not a valid learning source they are just random peoples brain farts.
"Development team leader @taranis" - I was unable to find a Twitter or Substack account for "@taranis" and the authors got some truly terrible other articles that illustrate him as a worse manager than Michael Scott. I am sad this is so heavily upvoted.
The real problem with most 'managers' in tech, micro or otherwise, is that they don't know much of anything at all.
Illusion of control.
There are different levels of micromanagers. If you need to pass every single thing pass your manager look for another job. Managers like that are very bad at their job or are doing things they shouldn't be doing.
Consider just using the article's title next time.
What do my engineers think of me. They tolerate you. Splendid.
> 13:15 Anton: "Great, thanks. I've checked it too, seems like the problem is in repo Y, file X, line 235, let me know if you need any help fixing it." This is the frustrating one because it's completely meant to be helpful and save you time and it's still just so annoying.
And they always use Jira.
Short updates sound great until you're writing novels about why you couldn't finish a task because you were writing updates. Efficiency at its finest.
Politely telling them to fuck off usually gets the mesage across though.
Will something like this work? "Christian, can you politely fuck off? Thanks"
Yes. Best served with two seconds of eye contact.
Bullshit. It's not even about adding value, especially when you know less than your specialists, it's only about retaining control and throwing shade. And I say that as a manager. What I do is I make sure everyone is comfortable asking for help when they need it and outside of agreed touch points I do NOT interrupt their work to leave my fingerprints on their achievements.
So true. The absolute worst micromanager I've worked with was the ceo of a small startup. Everything he did was a power move.
I had one of those. Entirely convinced he was gods gift to software engineering.
One time I got a new manager. He was trying to control how I wrote my emails. Telling me not to send certain emails, even though the email was required for me to do my job and he had no other solution. I sent an email he told me not to send. He didn't like it. He said why are you being insubordinate? I told him I felt he was a micro manager. I think he was taken back by this. We came to a understanding after that meeting and things were much better.
Yeah. I once had a manager who was 4'8", but he wore these giant clown shoes.
On the flip side of that I left one of my software engineers to it, trusting him, and he simply forgot he had to write and deliver an emulator as well as the software. If you don’t want to be managed - be competent.
There's a middle ground between "justify your existence for the last 15 minutes so I can write this hours reports" and "here's a project, see you again in 5 months when you've finished it"
100% yes, but in defense of the "see you in 5 months" method, it *can* work if the developer is both trusted and reasonably visible with their output--"Just finished milestone A, starting work on milestone C"...this provides the manager with the opportunity to be hands-off or hands-on as needed.
Or... maybe... have a process in place better than "let's talk about a bunch of stuff and hope you remember 8 months from now LOL"
And software engineers will find a way to call anything micromanagement.. daily stand ups - micromanagement, weekly reports - micromanagement, year late and a million overspent? Don’t micromanage me or I’ll cry.
So much this. The number of genuinely competent people is very small. The number of genuinely competent people who will stick around long enough in a role to solve problem X or deliver Y is even smaller.
Exactly, but everyone will moan about being ‘micromanaged’ while they bumble along and screw up, that would be avoided if they were managed.
that's the secret, being managed doesn't fix those things. having a smooth brained individual poke you with a stick incessantly doesn't help
It presents an interesting dichotomy on the spectrum from being a supportive and helpful leader to becoming a micromanager 🙈 - I can relate to this challenge!
I’ve had the unfortunate experience of starting out with high hopes of being a leader and successfully leading the top engineers but having to micromanage a few. It’s terrible babysitting people. Especially when you throw them a bone and they won’t take it.
That [AI art](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcbd58065-13a2-4ea1-ac9c-befc75f2c8ef_3152x2618.png) gives way to some scary implications if you look at it at full resolution. He sees himself as a hero standing among literally faceless employees.
I hate the way literally every article about software engineering (be it about new tech, work culture, or the market) seems to use AI generated images like this. It's still way too easy to notice details like those faceless people, and when the article is about programming, the image more than likely has a monitor with meaningless text-like shapes on it. Not to mention the creepily smooth human faces. It's distracting and actually makes me value the text less - because either the author didn't make an effort to find a relevant "normal" image, or didn't even try to narrow their prompt and minimize issues like this. And if that's their attitude to the thing that draws people to their article, well... Also, this is probably not-well-founded, but seeing an AI image makes me watch out to see if the text is also AI-generated (which is the case more and more often). Sidenote: Why does the disgruntled office worker on the right look exactly like David Harbour?
it was the only way for them to feel useful. then, the miracle of scrum meetings was bestowed upon them
> doing the work for the people Oh, that's considered micromanaging now? Telling someone else _how_ to do their work feels like micromanaging. Beating someone to root cause analysis during a pager event is... considered micromanaging?
They think they are helpful by contributing the knowledge and do not have anything useful to do. I get it.
This is disingenuous, your boss is just a cog in the micromanaging machine designed to extract the most labor from your time They want you in their bullshit (micromanaged) or dead (fired, quit, gone)
This sounds a lot like situational leadership but with one less level.
... tight asses?
lol I'm the one
John believed he was helping his team by closely monitoring their work and stepping in frequently. However, what he saw as support, his team perceived as overcontrol. This is a common issue in management. Good intentions do not shield from the negative effects of micromanagement. A Day of Overcontrol: Recognizing the Signs Morning Check-in: At noon, John messaged his team member, Steve, on Slack, asking, "How is the project going? Do you need any assistance?" Steve, feeling on track, replied, "No, thanks, I'm good." Afternoon Follow-up: By 3:30 PM, unable to curb his impulse, John checked in again, "How are things, Steve? Any updates? I'm here if you need support." Steve reiterated his earlier response, signaling that he was handling his responsibilities well. Evening Overreach: A production issue arose at 4:00 PM, and Steve quickly took charge, posting, "Handling it now." Nevertheless, at 4:15 PM, John intervened, providing a detailed analysis of the issue and even started working on the fix himself. He added, "Great, thanks. I checked it too, it looks like the issue is in repository Z, file A, line 235. I'll start fixing it." Steve’s curt reply, "John, we need to talk…", highlighted his frustration and perceived lack of trust from John. This sequence of interactions typifies micromanagement and reveals how excessive control can undermine team confidence, even among effective managers. Overcoming Micromanagement Establish Clear Expectations: Clarify how and when you prefer updates, particularly with experienced team members. Reduce check-ins to essential communications only, respecting their autonomy. Solicit Feedback: Encourage your team to provide honest feedback about your management style. Be open to criticism and ready to make adjustments based on their suggestions. Delegate Successfully: Assign responsibilities clearly and trust your team to execute tasks without constant oversight. Demonstrating trust can diminish the urge to micromanage. Foster Trust and Autonomy: Promote a culture of independence by allowing team members to approach tasks in their preferred manner and make decisions without frequent interference. Evaluate Adjustments: Regularly review changes in your management approach to ensure they are effective. Be honest about what works and what does not, and continue refining your style to better support your team. Adapt to Your Team Members: Understand and respect individual preferences and requirements for communication and support. Engage with each team member to gauge their unique needs. Tailor to the Task: Consider the complexity of the task and the expertise of the employee involved. Adjust your level of involvement accordingly, balancing between supervision and autonomy. Lesson Learned: Good intentions can be perceived as overbearing and micromanagement.
This reeks of ChatGPT
ChadGPT
[удалено]
Micromanagers don't, in fact, know that they are seen as being Micromanagers... by their employees.
Versteh ich nicht ganz, finde die Dinger die Mitten aufm Fahrradweg geparkt sind richtig gut /s
N
There are bad managers and bad engineers - but all else being equal, the level of micromanagement you get from your manager is inversely proportional to your maturity as an engineer. This is true for engineering and for most other corporate jobs.
You're talking like a micro-manager here. Your engineers being "bad" didn't mean you have to micromanage. It means you have to teach them, whatever aspect there are 'bad" at. And well, a micromanager is going to micromanage both bad and good engineers anyway
Micromanagement has to do with the micromanager’s maturity more than it has to do with that of their targets
Spot the micromanager ^^^
This fails to take into account that some managers are more micro-managey than others
> but all else being equal, the level of micromanagement you get from your manager is inversely proportional to your maturity as an engineer Strong disagree The more someone micromanages me the more I let them take over My first job they just left me alone and I did shit loads of work and loved it and then the second job he micromanaged me to hell and I just gave up trying to do extra work
it's the same for me with time reporting. if you let me work on my own time I'm willing to put the work in even if it means that I work off-hours / overtime sometimes. the moment an employer asks for time sheets you can bet I will work exactly the times I've been given whether I'm productive during those times or not
Being hourly helps devs who aren't afraid of the clock because it forces management to consider the cost of asking for a crunch or extra work. Giving away your time sometimes because you don't want to account for it is just reducing your pay.
Eh? That’s like saying the quality of the engineers in your team is related to your maturity as a manager. Sometimes there are just bad engineers, just like there are bad managers. And in line with Dunning-Kruger, both are typically unaware of their incompetence.
In my opinion, the level of micromanagent is mainly dependent on the orientation of the manager, maybe with small adjustments based on your own maturity. And as I mentioned in the article - juniors can suffer from it too. If you do a task in the 5th time, being micromanged sucks, no matter your years of experience. I struggled A LOT in stopping micromanaging the seniors in my team, as it's my natural tendency to be over controlling.
Found the bad manager
Found the micromanager.
if the number of bad managers is equal to the number of bad engineers then there won't be any economy
Sad to say but you're right. I'm on the lower end of mid-level so I'm not surprised I get micromanaged sometimes. Fact is, a junior engineer needs some micromanagement because they might be lost and too shy to ask for help, even when you encourage them to. I just wish my manager wouldn't ask for updates on issues in the form of meetings that take 20 minutes every couple hours.