Because if it’s the former, it’s possible that the issue was not addressed because it wasn’t deemed high-priority compared to other tasks, regardless of the number of user complaints.
If it’s the latter, well, I don’t know. Congratulations on completing an assigned task at your job?
At least that's the workflow I imagine when reading this and from working at similar places.
Also, I advise leaving a place that requires your manager to dictate which tickets you work on. Sounds like a crappy place to work.
As someone who recently left a place like that: I agree. I'm a highly-paid professional; it was really frustrating to feel like my manager didn't trust me enough to figure out what I needed to work on.
1. does what you are shipping have lots of international regulations and compliance requirements per country it will be available in with new countries being rolled out on a planned basis -> your manager will determine what you should work on
2. Are there things being released on a set date due to some sort of legal requirement, business deal? -> your manager will determine what you should work on
3. Is it basically the same product in all markets / countries other than internationalized text with not pending contracts or business deals requiring specific functionalities impacting the company? You should be able to determine what you should be working on.
If your manager needs to know all these details and can tell you "no, you can't fix X to build Y" then I really think that is a crappy place to work; not just due to the politics involved, but also the code must be absolute crap.
It's a giant pain and makes my job 10x more difficult when I tell another team that something that's low priority to us but high priority to them that something will be done, and instead find it sitting in in-progress with a tech debt bugbear of theirs in review.
The priority on the ticket was set for a reason, it was assigned and scheduled for a reason. There's only so many hours in the day to explain why some things are prioritised. If you think that's wrong, be a professional and talk to me about it.
I promise you, I want to have the conversation that you need to actually work with your team far less than you want to fix that JSON output.
If it’s a low priority for you but not for someone else, you are prioritizing wrong. Don’t complain because someone doesn’t want to play politics with you. Learn your team, play to their strengths.
My job is to make sure the teams priorities are straight, and I can't do that if you or someone else are subterfuging my efforts to do so.
Unless otherwise demonstrated, I trust that you (my team member in this case) are a smart, well intentioned person, and I ask that you assume the same of me. Going behind my back because you don't like what I'm asking you to do is "otherwise demonstrated".
Would that not depend greatly on the type of ticket and the type of developer? In my experience some developers are happily working on tickets with minor impact while there are high priority tickets, where a customer is really losing money, which get no attention from them.
The manager is there to prioritise, to make sure everybody has the same understanding of the priorities, and to unblock progress, among other things. As a manager, I am not telling people how to do their work, I am telling them what I think it is important to deliver. I don't even make the feature list, that is the job of a product designer.
Absolutely nothing in the "code test" provides any insight into how a developer would prioritise work within a product - it only tells if and how the developer can develop code up to the standards.
So I think in this regard the manager assigning the task is the correct choice - the product has a deficiency, and the manager is directing a team member to fix the deficiency. If some developer wants to make their own product prioritisation decisions, they are more then welcome to develop their own product, possibly inside the same company.
But if you're questioning every priority, and ignoring the priority, then you're not doing your job. You're doing my job without the information that I have.
Granted, I’m not going to go behind your back unless you tell me to build a shack that looks like a house because you don’t want to put down a foundation. (It’s like asking an accountant to cook the books because you don’t want to pay taxes)
POC, MVP, and prototype code excepted.
If I'm telling you to prioritise a particular room in the house, and you do another room instead, you're not doing your job. I hired you to because you're a professional who I can expect to follow instructions and deliver.
I was trying to avoid goinh into all the edge cases where this might not wholly apply, that we build these priorities out together, you have autonomy in a range of things, you're part of a team not an individual, etc.
It's my job to share the priorities with you, it's your job to accept those priorities sometimes. I don't like being told by _my_ boss that we have a surprise deadline any more than you do, and by the time I come to you saying "hey you need to do Y instead of X, it's because I've spoken to the other leads/PO's and we've figured out that this is what's best for the team and project. You might not agree because the crash you want to fix is high priority, or the thing hosting the widget needs a refactor rather than another special edge case, but at that point im not asking, I'm telling. I promise, (and I've shown this with my team) that if you do this when I do ask, we can do your pet stuff next, and I'll pull you off the critical path for a little bit.
Its the prisoners dilemma, and works when everyone works together but the minute someone stops trusting me and the team, it wrecks it for everyone.
1. You're not acting in the role of an engineer. You don't know (intrinsically) what needs to be done. You just know what you want done. Engineers are probably doing shit behind your back and you'll never know except that your velocity seems slower than normal occasionally. You probably won't even have a slight clue unless you are an engineer yourself. Some hints might be when you prioritize a bug and your engineer tells you 'oh, that got fixed when we did X which seems totally unrelated to X, or just barely related'. POs understand this when the customer wants X but really needs Y. The same thing applies to you, engineers know you want X, but really, you need Y. When you pressure them for X, and you're not listening when they tell you you really need Y ... think about that for a bit. Have a conversation with the POs.
2. You should never, ever, ever, agree to anything without discussing with the team first. There should never be any surprises, because when you get surprised your response should be "let me discuss this with the team and get back to you before I give any commitment on that, but I'll get back to you before the end of the day." A key question on any kind of deadline is "is this a soft- or hard-deadline and why? How much wiggle room do we have?"
3. If you are getting surprises on any kind of annual basis or more, it's because you've become a "yes-man" and your team is paying the price. You're allowed to say "no" or "we're dealing with too much, can you help reduce the load" or "we can do it, but it will be two weeks later than you need it, here's what we came up with to get most of it done by X, and complete it by Y.".
4. Don't be a dick. Software Engineering is a 24 hour job. You dream about the problems you are trying to solve sometimes. It really sucks to come in to work, with a solution you've been thinking about all night and all morning, only to be told you can't do it because you've got a dick boss who agreed to some bullshit without even talking to you about it.
> Its the prisoners dilemma, and works when everyone works together but the minute someone stops trusting me and the team, it wrecks it for everyone.
It goes both ways, you have to work with the team as well. And regardless, nobody is a prisoner... hopefully.
It would take the average engineer a Saturday afternoon. During the technical interview, one of the topics was what they thought about the order of the tasks. Thus we got a window into how they thought through what was important or not important and why. There was no wrong answer, we just wanted a balance between “feature first”, “bug first”, “security first”, and “debt first” on teams.