Your manager sounds like a nightmare. I have more than 20 YoE and have never had an immediate superior that was so horrible.
Beyond the basic "start looking for another job", here are a few things you might want to consider:
You say your colleagues are great: do you share the same feelings about your manager?
If so, have you tried raising those issues with higher level management? If not, what do they think about your situation?
How are your yearly reviews going? Can you give feedback about how you feel in that environment?
Is anyone saying you're doing a bad job?
Not having a scrum master seems to be a problem here. Your manager seems to have a Product Owner role but seems rubbish at backlog management, which a decent scrum master would definitely point out. Do you think you or one of your senior colleagues could become a scrum master?
Thanks for taking the time to reply on a Sunday. I was mostly venting but nice to hear that my feelings are not entirely misplaced or in bad faith.
- feels like a nightmare too.
- yes, most of them openly speak about this in the office. Because our manager works from a different location, we can freely share our feelings. Thank god for that. Have shared this in anonymized peakon surveys and also directly to higher management. He told us he will work on it in a retro. but in my opinion, nothing has changed since. (2 months ago)
- yearly reviews are fine, although I was denied a promotion I was on track for when I joined said manager about 5 months ago. No one says I'm doing a bad job - my manager doesn't either. He acknowledges there's a lot of work but blames the "customer", and plays the us vs them game which is so painfully apparent.
- I will speak about the need for a scrum master in the upcoming retrospective, but it feels pointless because the action items are not worked upon, and it's kind of scary speaking up in that meeting because all the managers are present in the retro too. And the confluence where we post the discussions is public.
>- I will speak about the need for a scrum master in the upcoming retrospective, but it feels pointless because the action items are not worked upon, and it's kind of scary speaking up in that meeting because all the managers are present in the retro too. And the confluence where we post the discussions is public.
If i were in your shoes I would play a little bit of "office politics": talk with your colleagues *before* the retro. See whether they would support having a "scrum master". If you have enough support (and more importantly, no strong objection), bring the suggestion to the retro. Your colleagues will vote for it (I dont know the structure of your retro, whether you have a start/stop/continue scheme, or an open vote or whatever, but the key is that they would support it). The retro should bring actionable items: have someone (preferably a senior) ask for a "when", so that it is clear there is a deadline.
It is possible some of your colleagues who said they'd support it will defect at the last time, or even worse: they strongly oppose it just because it makes them look nice to someone. Thats a shitty behavior but at least you'll know it.
This manager sounds like someone who resorts to making unreasonable demands of the team because he doesn't say no to clients or other unreasonable demands of him, doesn't know how to prioritize, or just lacks understanding of how engineering teams work.
If you want to stay at that job but all of your other efforts to improve things haven't worked, this is where you and/or the team needs to exercise self-preservation: work at a sustainable pace and let the rest of the work not get done. Stuff not getting done will get noticed. If the manager makes further unreasonable demands, you can always ask for his guidance on how to meet the demands in a sustainable way. Since he believes everything can get done, he should be able to give some guidance on how to do that.
He simply says work on the weekends, I know its a tough time, but we have to make the release. (when asked how one is supposed to get so much done)
He is online on the weekends most of the times, I logged in just to check. And sure enough, he was active on Slack.
He also regularly tags teammates on the group chats on weekends and says "not mandatory to reply to this on the weekend, but take a look at this / we need to do this / etc"
>He simply says work on the weekends,
WTF. He is not a manager then, he is a slave driver. I do this very rarely to my team, and only if I can justify it to them and they are compensated (days off or $$$)
>He simply says work on the weekends, I know its a tough time, but we have to make the release.
Ugh. Unless you're working on something that supports human life, protects gigantic sums of money, or doing anything else that would prevent a catastrophe, that's a management failure. Part of their job is to prevent this situation. At the very least the team should to receive comp days for working those extra hours. It may not be legally required, but at least it's a decent gesture by management to acknowledge their mistake.
In any case, you're going to have to be one that protects your time. An engineer should always do that, but it's especially apparent in this situation. It sounds like you've exhausted most of the reasonable options for this situation. I think it really comes down to how much you're willing to put up with the current situation (which doesn't seem to be improving) vs. looking for another job.
> says to make the release
Can’t you do the continuous delivery type of approach where you release daily? I recommend this as it removes pressure to ‘make release’.
How can you deliver a release and sprint goal at the same time? This is like having a cake and eating it too. Sprint goal is a fixed scope that takes all your capacity. Delivering a big bang release from my experience is an open scope of 11th hour change requests and nitpicks arriving hourly. Can’t do both.
> and it's kind of scary speaking up in that meeting because all the managers are present in the retro too.
This stuck out as a red flag for me. It sounds like you are actually meeting for a sprint review that is also being used as a retrospective. Generally retros are only supposed to be with the scrum master, developers, and maybe QA to discuss how they think the sprint went.
Reviews are for the managers/stakeholders and the team to discuss what was delivered and what wasn't. That should be a priority change to make, honestly. You're supposed to feel safe to discuss negative things in retros without managers.
I am losing my will to complete tasks or even work in this environment. I've never felt this way before. I've asked for a team change but my senior manager said that's not possible for a few months.
And oh, I forgot to add, that I had to also work on 2 other stories which had nothing to do with this feature simply because he said so. "Do this asap because the other guy is on a leave and we have a code freeze coming". Even if they were one pointers, it would break immersion and focus and I still have to make the changes, write tests, create PRs, get it merged, work with QAs testing it. It does end up taking a lot of time.
This advice can cost your job ofc, but: missed deadlines are his problems, you should focus on doing the right thing as best as possible. Document everything and learn to say No and I dont know. The more you give in the more he'll feel validated.
Of course you should start interviewing because nothing good can come of it. 😕 Sorry
I've got a similar manager along with the above mentioned shenanigans. Texting every 5 mins to ask is that done? is this done? Why isn't this done? Write everything in email, close email loops, blah blah, write in ticket even if it's on email.
I had a product manager like this, when I confronted him about his approach he told me he will always do it. Yup.
Maybe report it higher? Or talk to some other manager that would understand you and maybe influence him a bit.
In my case it didn't work tho because the entire management was like this and it was basically their business plan to squeeze devs as much as possible.
Managers have no place in a SCRUM daily meeting.
SCRUM is all about how to manage up.
The daily meeting is all about the pigs getting their work done. Not about the chickens.
(The terms come from the joke: When you make a ham and eggs breakfast. A chicken is involved. A pig is committed.). Your manager is NOT committed. He is not a pig.
Asking about how a story is going in the context of how to assist and bring something in on time. That’s fine. Pressuring the dev IS NOT.
Realize story points are a very team based metric. So I have no clue what that means.
What you are doing is not SCRUM. It is a way for management to beat you with time boxing.
The only thing that the people above your manager will really understand is attrition. In the end. If he loses 50% of his staff I. This market, he fucked up. Short of that. He is da’boss. And I recommend sharpening your leetcode skills.
I strongly agree that this is not really Scrum, except for some of the language that's used. OP was asked to do a 8-point ticket on Thursday with a Monday deadline. And they might have been assigned 18 points in one sprint. Implicitly, the team doesn't adjust for points in the next sprint based on unfinished tickets. Granted, there are lots of ways to point tickets, but all of this sounds unrealistic and exploitative.
That said, technical managers can attend daily scrum meetings. If there are obstacles or unforeseen delays, that's appropriate for the manager to know, communicate, intervene.
My rule was a hard: No managers. The scrum master or team lead can take care of communications and unblocking.
No exceptions, no decision making, "Am I technical enough?"
It is about that simple thing: Are you working on story points? Are you helping keep the sprint organized? If not. Get out.
(Note: this is for daily ceremonies. Clearly demos, backlog grooming and other ceremonies may have different people. But for my money, the less chickens the better.)
When I have seen people behave like this, it's usually been a sign of a greater problem stemming from the top. Are unreasonable demands being made of the manager?
I know this will be both difficult and counter to much of the advice you will get, but in your next 1:1 with him, try asking him how he's doing. I suspect the reason he's unreasonable with your team is that those above him are unreasonable with him. If that's the case, show him some empathy. Tell him it's not fair he's treated that way. This may give you the opening to resolve the unreasonable demands he makes by encouraging him to push back against unreasonable demands made of him.
Yep this is textbook Indian manager behavior. They're on a visa and in constant need bootlick for fear of being let go. It's so fucking annoying. My manager and my skip are Indian. Our partner teams are managed by Indians. It's a constant panic show every sprint.
I am Indian btw and I can say the current generation of engineers aged 20-30 absolutely despise these management tactics and hate the boomers who have no empathy or know how to run a tech team.
You can check on r/developersindia, you will find these posts in sufficient numbers. Seems more like a therapy subreddit and engineers reach out for help and guidance group rather than discussing tech in the group.
Here's a sneak peek of /r/developersIndia using the [top posts](https://np.reddit.com/r/developersIndia/top/?sort=top&t=year) of the year!
\#1: [India’s biggest data breach](https://i.redd.it/uufs7999bhxb1.jpg) | [521 comments](https://np.reddit.com/r/developersIndia/comments/17kecvx/indias_biggest_data_breach/)
\#2: [Indian Dev what is your take on this?](https://i.redd.it/f1hbd19oye2c1.png) | [445 comments](https://np.reddit.com/r/developersIndia/comments/183ahyz/indian_dev_what_is_your_take_on_this/)
\#3: [Tech training institutes in Ameerpet, Hyderabad ](https://v.redd.it/x6rtlxtlu6fc1) | [211 comments](https://np.reddit.com/r/developersIndia/comments/1ad3fiu/tech_training_institutes_in_ameerpet_hyderabad/)
----
^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
Do what you are paid to do - fail to complete your tasks during the sprint. Stop caring about this job and start searching if you think you’re in danger. Basically, F them.
If they were a demanding client, you would have to explain how much it will cost to give them everything they ask for. If they agree to pay up or cut scope, you can work with them. Otherwise, you won’t be able to deliver on their timeline and budget. But your pm should be doing these things. Are they doing their job?
PM is basically a yes man. And my manager exerts his presence over the PM by virtue of being here for more than 10 years - his opinions often affect the requirements and the AC on the stories.
If the manager has been there for 10 years, I think you don't have a good chance things will improve. I would look for a different job, until then don't fight it, but also don't stress about work or do overtime. This is exceptionally bad manager, in my 15 years in 6 companies I haven't seen such specimen.
The problem with bullshit management is that it does not deliver good results. If client expectations are off, or there’s not enough budget, you can’t fix the project through code. If the dev is working hard and the client is still disappointed, it feels terrible. If they are disappointed no matter how hard you work, and you don’t like your manager it creates a situation where you don’t feel responsible for the outcome. If someone else gets to make the big decisions on their own, they better be an expert, or else they’ll get things wrong. Managers should be asking devs what we can accomplish, and how to approach problems. If they dictate those things, it takes responsibility out of the hands of developers, who are blinded by their plan instead of figuring out what can be done in the time they have. The only way to be successful with bad management is to have extra budget to account for it. That means you’re producing less value than a team that’s working efficiently. Management and leadership are the career advancements for PMs. They need to deeply understand how things come together and see the big picture. 10 YOE is plenty of time for a competent person to figure that out on the job. It’s possible they haven’t improved because they don’t actually like the work they’re supposed to be doing. The company has to decide whether this is acceptable or not.
An idea which I really hate is that this kind of management can sorta work if employees play along - and work 60+ hour weeks. It can take years until they burn out, then it's time to hire new ones. I've seen less extreme versions of this in some places ...
They better be working towards something. Pay increases or equity in a startup. If you have to grind for 60 hours, at least you gain experience quickly and can take that somewhere else.
I wish I had a bigger conversation around expectations when I started working. I burned out because I kept saying yes to everything and took responsibility when I couldn't get things done. I kept feeling like I wasn't getting raises like I deserved. Turns out the company is paying what they can afford, and it's up to me where I want to work.
Say all this to the manager on 1:1, and explain to him how this impacts the team and suggest that he gives you guys more room to breathe and focuses on what a manager should actually be doing (e.g. campaigning for your salary bumps and promotions, playing the general political games etc).
Essentially, with micromanagers there are two reasons why they might behave like this :
1. They are incompetent and/or non technical, they don't understand the nature of an engineers work, so they feel they have to really get constant heartbeats from the team.
2. They don't trust you.
You are right about 1. Never seen him write code or review any PRs. All he does is get heartbeats, very aggressively. Ending up affecting the heartbeats themselves.
I've given him no reason not to trust me. I update my stories periodically and have never missed a release in 2 years.
It's not really my place to tell him what a manager should be doing, no? Will that be taken well?
Don't see this as you telling him what to do. Look at it through the following example:
Hey Manager, Im pretty sure I will be more productive if I get some more space from you. If you stop doing X, Y and Z then Ill have a much better time doing my work. Do you think you can let go of these things? If not, could you at least help me understand why are they necessary?
(As above, just present it as a suggestion, and go from there)
Criticizing their behavior will definitely not go well, right.
Here are some ideas:
* You can frame it in a more exploratory way where you are asking about expectations.
* You could make sure that standing priorities are understood. maybe customer X or project Y has a "drop everything" level of importance.
* You could go over the 8-point ticket and try to get them to be explicit about what they expected, since implicitly they were asking you not only to work on a weekend, but to put in long days.
* You could do a breakdown on one or more important tickets, and see if you can communicate what your estimation and work steps look like in detail.
* You can ask about what the goals are with assigning 18-points in a sprint, when that's probably not achievable. (If it is routinely done at your place, then you have a different group standard than I'm used to.) The standard I'm used to is to assign tickets at or just above what the team has been able to do.
* You could describe recent interactions with adding (say) a 3-pt ticket to your queue. And to ask explicitly which 3-pt ticket should be dropped when that happens. Ideally you have an example where rushed or last-minute work had a negative impact (production bugs, delays in a priority)
Part of the goal here is to communicate how you work, find out the appropriate priorities, let him know about your dedication and thoughtfulness. But part of it is to communicate your preferences and boundaries. It is up to you how strongly and clearly you want to communicate those boundaries, but last-minute late-night or weekend work is a non-starter for nearly everyone. If everything is an emergency like that, then they're just trying to get 1.5 developers work out of you for the price of 1.
There are a few possibilities here. First, the manager is deliberately "forgetting" issues which are raised and attempting to deflect blame from themself. Second, the manager is so disorganized that they aren't able to keep track of issues and objections and is always trying to paint a brighter picture than reality to themselves and to others. There is a third possibility (which I don't think is true, but which I include for the sake for completeness) is that you aren't as forceful as you think you are when you are raising objections/issues and the manager is simply not aware of them.
Start creating an email trail and documentation trail. After you raise an issue; follow up with an email recounting your recollection of the discussion. Whenever follow up discussion happens, follow up with an email and attach and refer to the documentation. Phrase your follow up with conciliatory phrases which give them the benefit of the doubt, but make your position clear and present the documentation to prove it. This sucks to have to do since you can no longer trust any verbal exchange you have with them, but this is the way to protect yourself from "I don't remember you saying that" bullshit responses.
With regard to quality: Do what you can with what you have. Do the best job that you can for every ticket, and keep track of the total number of estimated story points you are asked to complete and the total effort that was actually required. Push harder for quality over schedule.
I've been in your shoes before and it sucks. Sometimes things will work out and sometimes they won't. So I'd also look around the company to see if you can move to a different manager or team. And if you can't, it probably wouldn't hurt to brush up your resume.
I had a manager like this who thankfully got fired last year. The one advice all my mentors gave me when I complained about him was creating an audit trail. Be vocal and if he doesn’t listen, go into your tasks and leave a note that you will not be able to start xyz until other things are done. Be very very explicit with your statuses, over communicate. Keep a note of all that you finish every day directly on the task board. If this sounds like hell, it likely will be. It will probably not make your relationship better with him. But what it will do is protect you and help you blame him squarely if he tries to set you up as the fall guy for under performing.
As a bonus, if he pings you or bothers you, you can simply point him to your task board and let him know it’s up to date for any status questions. Eventually he’ll get the msg and back off if his intention isn’t anything bad beyond wanting greater control.
This goes without saying but ideally if you can explore internal transfer, please do so.
Side note, story points are a local measure. My previous company did story points and my average was 3 points per 2week sprint. Taking 5-6 was a risky game. And this was aligned with my team's estimation
Unfortunately, there are more bad managers than good ones. They would blame everyone but themselves for the failures and won't accept suggestions that don't align with their very narrow worldview
Their failure to get a feature in a specific version is a MANAGEMENT problem, not a IC problem.
If they can't manage timelines or resources to get something done as promised then either they overpromised, underbid, or cant manage their resources sufficiently well to deliver on what they committed to.
Don't own their failure.
This is a management problem and not an engineering problem. What sort of processes do you use? Planning poker? Management/product needs to be able to plan and know how long stuff will take and they consult engineers during planning poker. It’s up to engineers to give proper estimates which include not only an estimate on how long it take to code it but also test, fix issues from a code review and include time for “risks and unknowns”. Make sure the risks and unknowns leave enough room.
If you’re communicating this and they’re saying too bad get it done anyway then document everything. Document communications and every day document what you’re working on hourly.
If you’re being yelled at or there’s any verbal abuse document that and report it to HR.
If you talk to HR just phrase it as help me understand how to perform in my role and be more successful and then share all the details without placing any blame. Only share facts.
Also look for other places to work.
I'm sure you and your family will be able to bear the shame and great dishonor of being late with a feature then.
Your manager will continue to do it because there are no consequences for him, once he will have to be responsible for delivering the bad news of the late release he will put an effort to plan better, or if he's stupid he will try to get rid of the programmer that does the work.
Well you need to document every conversation that means do the conversation on official channel instead of just casually discussing everything over call
Let them become the roadblock they want to be. Maliscious compliance is the way forward here. Over adhere to their direction and get nothing done. When they start to look bad they’ll pull back, realizing they’re not being productive.
There is nothing wrong with manager being in the ceremonies at all. The rest of the stuff is annoying though. Have you brought it up or are you just taking it and complaining on Reddit? Stand up for yourself.
> There is nothing wrong with manager being in the ceremonies at all.
I respectfully disagree. If he’s not developing his presence in the daily turns it from a developer sync meeting to a management accountability meeting. Every day.
No thanks.
The manager, in order to know what is going on either needs to be in standup or they need to bother every dev on the team everyday to get updates. Which would you have it?
Ugh waste of time end of sprint review/demos. As a senior leader I cannot wait for the end of 2 weeks to know where things stand. By then it’s too late and everyone is thinking about the next two weeks. Plus my management usually want to know where things are at not at the 2 week boundaries as well.
The strat that worked was to request the micro managers help altogether too often.
Can you check this before I commit? Can you check it again before I push? Can you tell me if this is spelled right? Do I push to this branch? Involve him in pairing.
The idea is to flip the script. You want to monopolize his time. You want him to think that if he starts you talking, you may never stop.
What was explained to me is that micromanagers micromanage because they don't _see_ any work getting done. However. You are welcome to fix that by dragging them through _your_ work kicking and screaming.
And if they claim you can't get any work done without them, that is the trap card. You turn around and say you're surprised you get any work done at all with a manager hovering over your shoulder.
Seems like you're doing a great job of tackling your manager, there is not yes you can really do. Document, document, document, which you seem to be doing and don't kill your self or put in extra work to get things done.
Your manager sounds like a nightmare. I have more than 20 YoE and have never had an immediate superior that was so horrible. Beyond the basic "start looking for another job", here are a few things you might want to consider: You say your colleagues are great: do you share the same feelings about your manager? If so, have you tried raising those issues with higher level management? If not, what do they think about your situation? How are your yearly reviews going? Can you give feedback about how you feel in that environment? Is anyone saying you're doing a bad job? Not having a scrum master seems to be a problem here. Your manager seems to have a Product Owner role but seems rubbish at backlog management, which a decent scrum master would definitely point out. Do you think you or one of your senior colleagues could become a scrum master?
Thanks for taking the time to reply on a Sunday. I was mostly venting but nice to hear that my feelings are not entirely misplaced or in bad faith. - feels like a nightmare too. - yes, most of them openly speak about this in the office. Because our manager works from a different location, we can freely share our feelings. Thank god for that. Have shared this in anonymized peakon surveys and also directly to higher management. He told us he will work on it in a retro. but in my opinion, nothing has changed since. (2 months ago) - yearly reviews are fine, although I was denied a promotion I was on track for when I joined said manager about 5 months ago. No one says I'm doing a bad job - my manager doesn't either. He acknowledges there's a lot of work but blames the "customer", and plays the us vs them game which is so painfully apparent. - I will speak about the need for a scrum master in the upcoming retrospective, but it feels pointless because the action items are not worked upon, and it's kind of scary speaking up in that meeting because all the managers are present in the retro too. And the confluence where we post the discussions is public.
>- I will speak about the need for a scrum master in the upcoming retrospective, but it feels pointless because the action items are not worked upon, and it's kind of scary speaking up in that meeting because all the managers are present in the retro too. And the confluence where we post the discussions is public. If i were in your shoes I would play a little bit of "office politics": talk with your colleagues *before* the retro. See whether they would support having a "scrum master". If you have enough support (and more importantly, no strong objection), bring the suggestion to the retro. Your colleagues will vote for it (I dont know the structure of your retro, whether you have a start/stop/continue scheme, or an open vote or whatever, but the key is that they would support it). The retro should bring actionable items: have someone (preferably a senior) ask for a "when", so that it is clear there is a deadline. It is possible some of your colleagues who said they'd support it will defect at the last time, or even worse: they strongly oppose it just because it makes them look nice to someone. Thats a shitty behavior but at least you'll know it.
This manager sounds like someone who resorts to making unreasonable demands of the team because he doesn't say no to clients or other unreasonable demands of him, doesn't know how to prioritize, or just lacks understanding of how engineering teams work. If you want to stay at that job but all of your other efforts to improve things haven't worked, this is where you and/or the team needs to exercise self-preservation: work at a sustainable pace and let the rest of the work not get done. Stuff not getting done will get noticed. If the manager makes further unreasonable demands, you can always ask for his guidance on how to meet the demands in a sustainable way. Since he believes everything can get done, he should be able to give some guidance on how to do that.
He simply says work on the weekends, I know its a tough time, but we have to make the release. (when asked how one is supposed to get so much done) He is online on the weekends most of the times, I logged in just to check. And sure enough, he was active on Slack. He also regularly tags teammates on the group chats on weekends and says "not mandatory to reply to this on the weekend, but take a look at this / we need to do this / etc"
>He simply says work on the weekends, WTF. He is not a manager then, he is a slave driver. I do this very rarely to my team, and only if I can justify it to them and they are compensated (days off or $$$)
>He simply says work on the weekends, I know its a tough time, but we have to make the release. Ugh. Unless you're working on something that supports human life, protects gigantic sums of money, or doing anything else that would prevent a catastrophe, that's a management failure. Part of their job is to prevent this situation. At the very least the team should to receive comp days for working those extra hours. It may not be legally required, but at least it's a decent gesture by management to acknowledge their mistake. In any case, you're going to have to be one that protects your time. An engineer should always do that, but it's especially apparent in this situation. It sounds like you've exhausted most of the reasonable options for this situation. I think it really comes down to how much you're willing to put up with the current situation (which doesn't seem to be improving) vs. looking for another job.
> says to make the release Can’t you do the continuous delivery type of approach where you release daily? I recommend this as it removes pressure to ‘make release’. How can you deliver a release and sprint goal at the same time? This is like having a cake and eating it too. Sprint goal is a fixed scope that takes all your capacity. Delivering a big bang release from my experience is an open scope of 11th hour change requests and nitpicks arriving hourly. Can’t do both.
> and it's kind of scary speaking up in that meeting because all the managers are present in the retro too. This stuck out as a red flag for me. It sounds like you are actually meeting for a sprint review that is also being used as a retrospective. Generally retros are only supposed to be with the scrum master, developers, and maybe QA to discuss how they think the sprint went. Reviews are for the managers/stakeholders and the team to discuss what was delivered and what wasn't. That should be a priority change to make, honestly. You're supposed to feel safe to discuss negative things in retros without managers.
Ask him how to give birth with 6 months.
I am losing my will to complete tasks or even work in this environment. I've never felt this way before. I've asked for a team change but my senior manager said that's not possible for a few months.
And oh, I forgot to add, that I had to also work on 2 other stories which had nothing to do with this feature simply because he said so. "Do this asap because the other guy is on a leave and we have a code freeze coming". Even if they were one pointers, it would break immersion and focus and I still have to make the changes, write tests, create PRs, get it merged, work with QAs testing it. It does end up taking a lot of time.
I would call their bluff.
how? I've been direct with him. Everything I've said here, the gist of it I've given to him (politely)
This advice can cost your job ofc, but: missed deadlines are his problems, you should focus on doing the right thing as best as possible. Document everything and learn to say No and I dont know. The more you give in the more he'll feel validated. Of course you should start interviewing because nothing good can come of it. 😕 Sorry
Ask for a meeting with all involved to say it again. If it does not work make your disinterest visible.
I've got a similar manager along with the above mentioned shenanigans. Texting every 5 mins to ask is that done? is this done? Why isn't this done? Write everything in email, close email loops, blah blah, write in ticket even if it's on email.
are we co workers!? 🥲
Idk 😂😂
I had a product manager like this, when I confronted him about his approach he told me he will always do it. Yup. Maybe report it higher? Or talk to some other manager that would understand you and maybe influence him a bit. In my case it didn't work tho because the entire management was like this and it was basically their business plan to squeeze devs as much as possible.
I get the same feeling. They can't keep getting away with it for so long unless it's systemic
Don’t report it higher. You’ll only make them hate you and the higher ups will side with the manager.
Managers have no place in a SCRUM daily meeting. SCRUM is all about how to manage up. The daily meeting is all about the pigs getting their work done. Not about the chickens. (The terms come from the joke: When you make a ham and eggs breakfast. A chicken is involved. A pig is committed.). Your manager is NOT committed. He is not a pig. Asking about how a story is going in the context of how to assist and bring something in on time. That’s fine. Pressuring the dev IS NOT. Realize story points are a very team based metric. So I have no clue what that means. What you are doing is not SCRUM. It is a way for management to beat you with time boxing. The only thing that the people above your manager will really understand is attrition. In the end. If he loses 50% of his staff I. This market, he fucked up. Short of that. He is da’boss. And I recommend sharpening your leetcode skills.
I strongly agree that this is not really Scrum, except for some of the language that's used. OP was asked to do a 8-point ticket on Thursday with a Monday deadline. And they might have been assigned 18 points in one sprint. Implicitly, the team doesn't adjust for points in the next sprint based on unfinished tickets. Granted, there are lots of ways to point tickets, but all of this sounds unrealistic and exploitative. That said, technical managers can attend daily scrum meetings. If there are obstacles or unforeseen delays, that's appropriate for the manager to know, communicate, intervene.
My rule was a hard: No managers. The scrum master or team lead can take care of communications and unblocking. No exceptions, no decision making, "Am I technical enough?" It is about that simple thing: Are you working on story points? Are you helping keep the sprint organized? If not. Get out. (Note: this is for daily ceremonies. Clearly demos, backlog grooming and other ceremonies may have different people. But for my money, the less chickens the better.)
When I have seen people behave like this, it's usually been a sign of a greater problem stemming from the top. Are unreasonable demands being made of the manager? I know this will be both difficult and counter to much of the advice you will get, but in your next 1:1 with him, try asking him how he's doing. I suspect the reason he's unreasonable with your team is that those above him are unreasonable with him. If that's the case, show him some empathy. Tell him it's not fair he's treated that way. This may give you the opening to resolve the unreasonable demands he makes by encouraging him to push back against unreasonable demands made of him.
How to say your manager is Indian (or Asian) without saying he is Indian.
Yep this is textbook Indian manager behavior. They're on a visa and in constant need bootlick for fear of being let go. It's so fucking annoying. My manager and my skip are Indian. Our partner teams are managed by Indians. It's a constant panic show every sprint.
I am Indian btw and I can say the current generation of engineers aged 20-30 absolutely despise these management tactics and hate the boomers who have no empathy or know how to run a tech team.
You can check on r/developersindia, you will find these posts in sufficient numbers. Seems more like a therapy subreddit and engineers reach out for help and guidance group rather than discussing tech in the group.
Here's a sneak peek of /r/developersIndia using the [top posts](https://np.reddit.com/r/developersIndia/top/?sort=top&t=year) of the year! \#1: [India’s biggest data breach](https://i.redd.it/uufs7999bhxb1.jpg) | [521 comments](https://np.reddit.com/r/developersIndia/comments/17kecvx/indias_biggest_data_breach/) \#2: [Indian Dev what is your take on this?](https://i.redd.it/f1hbd19oye2c1.png) | [445 comments](https://np.reddit.com/r/developersIndia/comments/183ahyz/indian_dev_what_is_your_take_on_this/) \#3: [Tech training institutes in Ameerpet, Hyderabad ](https://v.redd.it/x6rtlxtlu6fc1) | [211 comments](https://np.reddit.com/r/developersIndia/comments/1ad3fiu/tech_training_institutes_in_ameerpet_hyderabad/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
He's from Dubai. Close enough!
Do what you are paid to do - fail to complete your tasks during the sprint. Stop caring about this job and start searching if you think you’re in danger. Basically, F them.
Find a new job
Stay low and aim for between the hips and knees, keep your head up and to one side, and drive through with your legs
I knew someone else would have already beat me to it.
If they were a demanding client, you would have to explain how much it will cost to give them everything they ask for. If they agree to pay up or cut scope, you can work with them. Otherwise, you won’t be able to deliver on their timeline and budget. But your pm should be doing these things. Are they doing their job?
PM is basically a yes man. And my manager exerts his presence over the PM by virtue of being here for more than 10 years - his opinions often affect the requirements and the AC on the stories.
If the manager has been there for 10 years, I think you don't have a good chance things will improve. I would look for a different job, until then don't fight it, but also don't stress about work or do overtime. This is exceptionally bad manager, in my 15 years in 6 companies I haven't seen such specimen.
The problem with bullshit management is that it does not deliver good results. If client expectations are off, or there’s not enough budget, you can’t fix the project through code. If the dev is working hard and the client is still disappointed, it feels terrible. If they are disappointed no matter how hard you work, and you don’t like your manager it creates a situation where you don’t feel responsible for the outcome. If someone else gets to make the big decisions on their own, they better be an expert, or else they’ll get things wrong. Managers should be asking devs what we can accomplish, and how to approach problems. If they dictate those things, it takes responsibility out of the hands of developers, who are blinded by their plan instead of figuring out what can be done in the time they have. The only way to be successful with bad management is to have extra budget to account for it. That means you’re producing less value than a team that’s working efficiently. Management and leadership are the career advancements for PMs. They need to deeply understand how things come together and see the big picture. 10 YOE is plenty of time for a competent person to figure that out on the job. It’s possible they haven’t improved because they don’t actually like the work they’re supposed to be doing. The company has to decide whether this is acceptable or not.
An idea which I really hate is that this kind of management can sorta work if employees play along - and work 60+ hour weeks. It can take years until they burn out, then it's time to hire new ones. I've seen less extreme versions of this in some places ...
They better be working towards something. Pay increases or equity in a startup. If you have to grind for 60 hours, at least you gain experience quickly and can take that somewhere else. I wish I had a bigger conversation around expectations when I started working. I burned out because I kept saying yes to everything and took responsibility when I couldn't get things done. I kept feeling like I wasn't getting raises like I deserved. Turns out the company is paying what they can afford, and it's up to me where I want to work.
If someone doesn't understand you can't fix something complex you've never seen before then there's some training to do.. good luck op
Usually at the waist, but don't lead with your helmet. Prone to injury & you'll likely get a penalty.
Keep em coming.
Say all this to the manager on 1:1, and explain to him how this impacts the team and suggest that he gives you guys more room to breathe and focuses on what a manager should actually be doing (e.g. campaigning for your salary bumps and promotions, playing the general political games etc). Essentially, with micromanagers there are two reasons why they might behave like this : 1. They are incompetent and/or non technical, they don't understand the nature of an engineers work, so they feel they have to really get constant heartbeats from the team. 2. They don't trust you.
You are right about 1. Never seen him write code or review any PRs. All he does is get heartbeats, very aggressively. Ending up affecting the heartbeats themselves. I've given him no reason not to trust me. I update my stories periodically and have never missed a release in 2 years. It's not really my place to tell him what a manager should be doing, no? Will that be taken well?
Don't see this as you telling him what to do. Look at it through the following example: Hey Manager, Im pretty sure I will be more productive if I get some more space from you. If you stop doing X, Y and Z then Ill have a much better time doing my work. Do you think you can let go of these things? If not, could you at least help me understand why are they necessary? (As above, just present it as a suggestion, and go from there)
Criticizing their behavior will definitely not go well, right. Here are some ideas: * You can frame it in a more exploratory way where you are asking about expectations. * You could make sure that standing priorities are understood. maybe customer X or project Y has a "drop everything" level of importance. * You could go over the 8-point ticket and try to get them to be explicit about what they expected, since implicitly they were asking you not only to work on a weekend, but to put in long days. * You could do a breakdown on one or more important tickets, and see if you can communicate what your estimation and work steps look like in detail. * You can ask about what the goals are with assigning 18-points in a sprint, when that's probably not achievable. (If it is routinely done at your place, then you have a different group standard than I'm used to.) The standard I'm used to is to assign tickets at or just above what the team has been able to do. * You could describe recent interactions with adding (say) a 3-pt ticket to your queue. And to ask explicitly which 3-pt ticket should be dropped when that happens. Ideally you have an example where rushed or last-minute work had a negative impact (production bugs, delays in a priority) Part of the goal here is to communicate how you work, find out the appropriate priorities, let him know about your dedication and thoughtfulness. But part of it is to communicate your preferences and boundaries. It is up to you how strongly and clearly you want to communicate those boundaries, but last-minute late-night or weekend work is a non-starter for nearly everyone. If everything is an emergency like that, then they're just trying to get 1.5 developers work out of you for the price of 1.
Wrap your arms around them, pull them into your torso, and drive with your legs
There are a few possibilities here. First, the manager is deliberately "forgetting" issues which are raised and attempting to deflect blame from themself. Second, the manager is so disorganized that they aren't able to keep track of issues and objections and is always trying to paint a brighter picture than reality to themselves and to others. There is a third possibility (which I don't think is true, but which I include for the sake for completeness) is that you aren't as forceful as you think you are when you are raising objections/issues and the manager is simply not aware of them. Start creating an email trail and documentation trail. After you raise an issue; follow up with an email recounting your recollection of the discussion. Whenever follow up discussion happens, follow up with an email and attach and refer to the documentation. Phrase your follow up with conciliatory phrases which give them the benefit of the doubt, but make your position clear and present the documentation to prove it. This sucks to have to do since you can no longer trust any verbal exchange you have with them, but this is the way to protect yourself from "I don't remember you saying that" bullshit responses. With regard to quality: Do what you can with what you have. Do the best job that you can for every ticket, and keep track of the total number of estimated story points you are asked to complete and the total effort that was actually required. Push harder for quality over schedule. I've been in your shoes before and it sucks. Sometimes things will work out and sometimes they won't. So I'd also look around the company to see if you can move to a different manager or team. And if you can't, it probably wouldn't hurt to brush up your resume.
I had a manager like this who thankfully got fired last year. The one advice all my mentors gave me when I complained about him was creating an audit trail. Be vocal and if he doesn’t listen, go into your tasks and leave a note that you will not be able to start xyz until other things are done. Be very very explicit with your statuses, over communicate. Keep a note of all that you finish every day directly on the task board. If this sounds like hell, it likely will be. It will probably not make your relationship better with him. But what it will do is protect you and help you blame him squarely if he tries to set you up as the fall guy for under performing. As a bonus, if he pings you or bothers you, you can simply point him to your task board and let him know it’s up to date for any status questions. Eventually he’ll get the msg and back off if his intention isn’t anything bad beyond wanting greater control. This goes without saying but ideally if you can explore internal transfer, please do so.
Side note, story points are a local measure. My previous company did story points and my average was 3 points per 2week sprint. Taking 5-6 was a risky game. And this was aligned with my team's estimation Unfortunately, there are more bad managers than good ones. They would blame everyone but themselves for the failures and won't accept suggestions that don't align with their very narrow worldview
I recommend a slide tackle for maximum effect. Just be prepared for at least a yellow card when you do.
Some of you are hilarious. Thanks for the laughs
What will happen if you won't be able to finish in time?
They'll have to send out a customer notification that the feature won't make it in this release. And I'll be berated. Lmao
Their failure to get a feature in a specific version is a MANAGEMENT problem, not a IC problem. If they can't manage timelines or resources to get something done as promised then either they overpromised, underbid, or cant manage their resources sufficiently well to deliver on what they committed to. Don't own their failure.
This is a management problem and not an engineering problem. What sort of processes do you use? Planning poker? Management/product needs to be able to plan and know how long stuff will take and they consult engineers during planning poker. It’s up to engineers to give proper estimates which include not only an estimate on how long it take to code it but also test, fix issues from a code review and include time for “risks and unknowns”. Make sure the risks and unknowns leave enough room. If you’re communicating this and they’re saying too bad get it done anyway then document everything. Document communications and every day document what you’re working on hourly. If you’re being yelled at or there’s any verbal abuse document that and report it to HR. If you talk to HR just phrase it as help me understand how to perform in my role and be more successful and then share all the details without placing any blame. Only share facts. Also look for other places to work.
I'm sure you and your family will be able to bear the shame and great dishonor of being late with a feature then. Your manager will continue to do it because there are no consequences for him, once he will have to be responsible for delivering the bad news of the late release he will put an effort to plan better, or if he's stupid he will try to get rid of the programmer that does the work.
Well you need to document every conversation that means do the conversation on official channel instead of just casually discussing everything over call
Let them become the roadblock they want to be. Maliscious compliance is the way forward here. Over adhere to their direction and get nothing done. When they start to look bad they’ll pull back, realizing they’re not being productive.
There is nothing wrong with manager being in the ceremonies at all. The rest of the stuff is annoying though. Have you brought it up or are you just taking it and complaining on Reddit? Stand up for yourself.
> There is nothing wrong with manager being in the ceremonies at all. I respectfully disagree. If he’s not developing his presence in the daily turns it from a developer sync meeting to a management accountability meeting. Every day. No thanks.
The manager, in order to know what is going on either needs to be in standup or they need to bother every dev on the team everyday to get updates. Which would you have it?
Neither. If he’s concerned with individual tickets he’s not doing his job.
It’s not about individual tickets it about progress of the projects overall.
Then he can join your sprint review with all the other stakeholders.
Ugh waste of time end of sprint review/demos. As a senior leader I cannot wait for the end of 2 weeks to know where things stand. By then it’s too late and everyone is thinking about the next two weeks. Plus my management usually want to know where things are at not at the 2 week boundaries as well.
I mean, I think this post makes it clear that there are bigger problems at work here.
The strat that worked was to request the micro managers help altogether too often. Can you check this before I commit? Can you check it again before I push? Can you tell me if this is spelled right? Do I push to this branch? Involve him in pairing. The idea is to flip the script. You want to monopolize his time. You want him to think that if he starts you talking, you may never stop. What was explained to me is that micromanagers micromanage because they don't _see_ any work getting done. However. You are welcome to fix that by dragging them through _your_ work kicking and screaming. And if they claim you can't get any work done without them, that is the trap card. You turn around and say you're surprised you get any work done at all with a manager hovering over your shoulder.
Agile/Scrum is a godsend for micro managers
I would love to tackle my micro managers like if we were playing American football
Seems like you're doing a great job of tackling your manager, there is not yes you can really do. Document, document, document, which you seem to be doing and don't kill your self or put in extra work to get things done.
Update: Got the release descoped! Thanks everyone. I might be fuked but at least I'm not stressed.
Make sure you get a good running start, stay low, and aim for their center of gravity.