How do your teams take accountability for previous poor decisions that cost the team?
Posted by DirtyOught@reddit | ExperiencedDevs | View on Reddit | 28 comments
joined this small engineering team where there’s no real tech lead, no clear ownership, and decisions basically get made by whoever speaks the most convincingly that week. Since everyone but myself is young, no one knew when they were doing the wrong thing. And it is absolutely catching up to us.
A while back, the team decided to use their “tech debt allocation” to do a completely unnecessary framework upgrade. And not a small one. They pointed to the new cool things the updated version gave us.
Fine. But our app doesn’t use any of that. Didn’t need any of that. and the old version worked PERFECTLY fine.
But instead of spending that time on real pressing matters or writing a single test, they poured it into a vanity migration no one needed.
They got like 1/3 of the way through it, realized it was huge, paused it, and then just… never touched it again. For months. So we ended up with this half-migrated, fractured, Frankenstein codebase that’s now causing actual production issues.
Now I’m the one who has to finish the rest of this monster migration just so we can fix these issues caused by it. And apparently I’m the only one absolutely pissed about it. Everyone else is just like:
“Yeah that happens, engineering is messy lol.”
No. This isn’t “engineering is messy.” This is what happens when no one owns decisions, no one is accountable, and people make giant architectural changes because they sound cool rather than because they solve a real problem.
Meanwhile my time and days are getting shredded by bullshit decisions that never should’ve been greenlit in the first place.
How do you handle accountability in a situation like this?
If I press and ask why we did the migration, I’m an asshole and “it’s already half done so what’s the point at complaining”. And Yes I like “blameless culture”.
But a team with no accountability is arguably worse.
AshamedDuck4329@reddit
sounds like chaos, no leadership, accountability is key, but maybe propose a retro session, discuss impacts openly, might help, worth a shot.
Material_Policy6327@reddit
This sounds like most corporate jobs I’ve seen sadly
dgmib@reddit
What outcome do you want to see?
An obviously bad call was made. The things to consider now are where to go from here, and what can we learn from this.
DirtyOught@reddit (OP)
“Obviously”
It’s not so obvious to the team. They still think it’s was correct
Material_Policy6327@reddit
Are you just wanting to prove the team Was wrong and you are right? Like what do you want to actually happen?
dgmib@reddit
I think you're focusing on the wrong thing. You seem more concerned with proving to the team was wrong rather than solving the problem. If you put people in that situation they will dig in and try to prove they made the right call to start this migration.
You want to side step that argument.
Presumably the team at least sees that this migration is costing more than they originally anticipated. In light of that observation alone, discuss what to do from here.
Broadly speaking the options will fall in to three major categories:
1) Finish the migration
2) Adopt a plan that abandons the migration and cleans up half-finished mess
3) Live with the mess as is
From the business' perspective this should come down to simple cost benefit.
The business decision needs to focus on what value is delivered in each option vs what the cost of each is.
Assuming this is a for-profit business. The value needs to be one of three things: (a) reduce the business's expenses (b) increase it's revenue or (c) reduce it's risk, any strategy that doesn't do at least one of those three things isn't delivering any value and should be abandoned.
The team needs to show that their decision from this point delivers more value than the cost of the plan at this point.
flavius-as@reddit
The right approach is to gain capital with management due to this.
This very monologue you wrote here, you should do to the manager and ask him to put responsability in place from now on.
This gives you power over time and hopefully more weight into technical decisions later.
BuzzAlderaan@reddit
That’s the neat part, we don’t.
TopSwagCode@reddit
"no real tech lead, no clear ownership, and decisions basically get made by whoever speaks the most convincingly that week" - Sums up your problems :) Thats exactly why you have a tech lead. Someone who is responsible and can take these decisions.
Thats also why you have managers, product owners, etc. Someone who is responsible in different fields.
dnult@reddit
It won't be the last time that a hard lesson is learned, provided you actually learn from it. Mistakes are inevitable and hopefully they lead to a better future. Focus less on blame and more on what that endeavor revealed. Use it as an opportunity to grow while preserving trust.
Visa5e@reddit
More red flags than a Soviet May Day parade.
So theres no tech lead, but presumably you have a boss, right? So thats your first point of call. Takje everything you've written here, explain whay its bad and, heres the most important bit, explain how you would have done it differently.
Dont be phased by being junior, you have as much right as anyone to speak up.
Oh, and blameless culture doesnt imply nobody is to blame. It only works when people are accountable.
08148694@reddit
Small eng team, no clear lead, everyone younger than you
I have to ask: why join this team? It seems like a poor culture fit for you. Since you’re older and more experienced, yet (presumably) hired at the same level as the other team members, will you resent one of them becoming the lead? Can you quickly step up and become the lead? Why weren’t you brought in as the lead?
foresterLV@reddit
framework upgrades almost always make sense because getting stuck on non-supported/legacy version will cost more in long term. the rest is just your skill on how fast it can be achieved. frankly I do not see how framework upgrade can be so problematic unless it's something like windows net to linux/container core move.
if you think it's too much changes at once just split it into multiple steps/iterations. there are always solutions available, however if you work from position "not my decision/I don't like it" this sounds more like not a team player problem.
DirtyOught@reddit (OP)
“Legacy”
because updating my framework to support react server components is exactly what we need and if we don’t we will become LEGACY!
/s
and we don’t even use RSC now which is hilarious part about it.
This isn’t some legacy migration this is the state of FE engineering and is god awful.
sudoku7@reddit
I may be a bit of a contrarian here, but bear in mind, I'm just presenting an alternative. I've been in an environment with the reverse problem. Refusing to update our framework when EOL was 2 years off because we let the effort climb to the '6 month+' window to accomplish. Resulting in having to continually pay that technical debt interest which gets increasingly expensive as we continued to go past that EOL period by years. The problem becoming worse and worse.
Now, I'm not saying this is the case in your scenario, but it is something that jumped to my head perhaps because I have been burned by the opposite. However, all of that to say, it may be helpful to reframe what you view as the problem. The problem may not have been updating the framework, but instead doing so in a half-assed manner that left it in a partial state. Being left without that commitment to finish the migration even after work for it has been merged to main.
alohashalom@reddit
Accountawhatnow?
scataco@reddit
They say that these kinds of cultural traits are the result of forces higher up in the organization.
For this reason, realistic expectations are hard to come by in large organizations. In small companies, managers usually have the same style of management as the owner. And so on.
There is a way to escape from these forces on a team level, but it requires a manager who is willing to do the work to keep them out.
rover_G@reddit
Treat it like a production incident with a retrospective and action plan to prevent similar issues in the future. For poor architecture/framework decisions the solution usually ends up being to review major decisions with an architect.
Sad-Salt24@reddit
I try to document everything clearly: what was done, why it was a problem, and what the impact is. That way when you push for fixes or better practices, you’re not just complaining, you have a concrete record. It also helps when you eventually have to advocate for proper code reviews, ownership, or even just slowing down before the next “cool” change.
theonlyname4me@reddit
Sounds like you joined a team where you outpace everyone as an engineer.
If you’re getting paid crazy well, cash those checks and be happy!
If you aren’t quit and find a better job where you’ll continue to grow as an engineer.
Your career should have earning AND learning stages; you’ve got to decide what’s important to you.
BTTLC@reddit
This just sounds like a cultural issue and the result of a technically immature team. If your team is as bad as you make it sound, it would probably be easier to just find another role in a more technically mature team and company.
drachs1978@reddit
The only thing particularly weird here is that the person who was excited for the migration and started the migration bailed on it and it was dumped on someone who clearly thinks the idea is bullshit.
diablo1128@reddit
I've only worked at non-tech companies in non-tech cities, but this was pretty much my experience as well. Bad decisions were made and nobody really cared. There were definitely no retrospectives to determine how we can be better in the future.
These were not some fly by the night companies, but profitable companies that has been around since the early 80's. I guess since the private company was swimming in cash they just use money to solve their problems and not worry about it.
In you specific situation I wouldn't blame anybody. I would just be the "asshole" and push to roll it all back to whatever you had before with reasons why. Since nobody wants to complete it then they must all see it as a mistake as well.
It sounds like you are the most Senior person on the team. If so then, if I was you, I would just play the role of the lead since management doesn't want to have an actual lead. That is if I really cared enough to want to change things, depending on the situation I may just not care enough and watch the world burn.
By play the role of the lead I would just shut down down decisions like this so they don't cause the issues you foresaw coming. Work is not really a democracy where people get to vote on what they want to do, somebody will have the final say on things.
If your co-workers want to complain to you boss then let them. I would just explain my actions to the boss when time comes and how I had what was best for the project in mind. If your boss is reasonable they will understand and if they are not then you know what kind of company you are working for and can decide if you still want to work there long term.
Far_Archer_4234@reddit
Y'all have git, right? Maybe consider rolling back a few months to when the app was stable, and cut your losses?
codescapes@reddit
Document, document, document.
Take the top 5 things and write a 1 pager about why they need fixed and "t-shirt size" them (small, medium, large, extra large). In doing the writeup you might find some of this is less of a problem than you first thought. Anything extra small but important just do yourself without asking permission.
Communicate the list to your manager, product owner if applicable and depending on relationship your skip-level. Justify the work based on business value or systemic risk.
Do it in a way that does not blame anyone or name names, just acknowledge the stuff that's bad. Things that won't scale (and will need to), use of old dependencies on core libraries, lack of documentation / knowledge silos around e.g. release process, improper test coverage...
It's all fair game. And do it sooner rather than later because once you've written it up it somewhat absolves you of blame and gives you something to reference if the work isn't prioritised and later trips the team up or slows down delivery.
johnpeters42@reddit
I would make it less about who greenlit the project (probably messy to untangle who started it and who just went along with it), and more about what decisions were or weren't made in the process, specifically in the context of "What can we all do going forward to avoid this sort of thing happening again".
throwaway_0x90@reddit
Management problem.
Far_Archer_4234@reddit
Blameless culture only works when someone is terminating the non-performers sonthat you don't have to blame them.