TL; DR:
Strive for a blameless culture.
Join my livestream about migrating WordPress to Blazor on Tuesday, October 15th at 7:00 AM PST!
Join my livestream discussing this article on Monday, October 14th at 7:00 PM PST!
DotUltimate Giveaway!
You can win a FULL YEAR license for dotUltimate! I’ve given away licenses earlier this year and I have a handful more to give away before the year ends! Now’s your chance to start earning entries here:
What’s In This Issue
Exclusive Article: Radical Accountability vs Blame Culture
It’s Your Fault
You’ve been working on a feature now for 3 weeks and you’ve finally gotten the necessary sign-off on your PR to get things pushed to production. This feature has been challenging because you had to make sure you could work with the product owner to understand the requirements more clearly — they seemed quite ambiguous to start with.
Things became more challenging when the two senior engineers on the team originally had some conflicting advice for you during some of the early design phase. You had done your best to get a quick design doc together to outline how you planned to integrate the feature into the existing code, and you even had the product owner check out the doc before you got technical feedback.
After settling on the right approach with the more senior engineers, you worked on coding up your solution. You showed a working version of the feature in the product to the product owner and they agreed it looked good to go.
But you know the pull request is still going to be a pain in the butt — you need to get those two senior engineers to sign off. After a few days of making adjustments, it’s time to merge the pull request and deploy. A great way to finish a Monday!
Wednesday morning you login to continue working through the requirements of your next feature. Your messenger dings as soon as you’re online. It’s your manager.
“Hey, we need you to get on this incident bridge right now. Workflows for users are completely broken and we’ve traced it back to your change”.
Not a great start to a Wednesday. Dammit.
On the bridge, one of the senior engineers from your team explains that they’ve already rolled back your change to mitigate customer issues. They ask, “Why didn’t you flight this change out? Didn’t you think about the fact that you could break our product for all these users?”. Your manager adds, “Not only was this blocking their workflows, but we’ve had several customers contacting support that this feature doesn’t make any sense. This needs a complete redesign because it’s confusing and conflicts with how they are trying to use the product. We’ll go over this in the post-incident review”.
The senior engineer was right that it should have been flighted. How did that get missed? And the customers find this confusing? But the product owner worked on this too. But a post-incident review should help everyone understand where the problems occurred so everyone can get better for next time.
Wrong.
Friday’s post-incident review starts off with your manager giving a speech about how the team will start a zero-tolerance policy around non-flighted features. Your change was the catalyst. And now the spotlight is on you, “So, tell us: How did you manage to ruin the experience for so many of our users with just this single change?”
That great Monday seems like it was an eternity ago. You feel like closing your laptop lid and curling up under your desk.
Blame Culture
The example above demonstrates a culture centered around blaming others for things going wrong. Hopefully, it feels like an exaggerated example, but unfortunately, I would suspect that at least one person reading this feels like they’ve probably lived through something like this.
Let’s pick apart some of the things that are likely being experienced as this scenario played out:
Embarrassment: Nobody likes being singled out in a group of people to be talked about poorly. The senior engineer was right about fighting changes, but that was embarrassing.
Unsupported: When the manager piles on more challenges with the problematic feature, this leads to pile on the feeling that there is no support.
Isolation: Not supported and embarrassed? Probably feeling isolated — even though you’re on a team that’s supposed to have the same charter.
Imposter Syndrome: Even someone who is technically sound and experienced in their role is likely to have some Imposter Syndrome triggering as a result of an experience like this
Frustration, Anger, Sadness, etc… You get the idea.
There are a lot of missed opportunities when a culture is centered around blame. Especially when doing a process of reflection like a post-incident review, instead of focusing on learning opportunities it’s instead an opportunity to shine a light on everything that went wrong. It’s all the things that shouldn’t have happened in the spotlight and little to no emphasis on a path forward that’s constructive.
This also propagates a culture of fear — nobody wants to live through a scenario like that again. Sure, flight the changes next time, but what if something else goes wrong? What if the customers hate your next feature too? This has an effect not only on the person being singled out, but all the other people observing how this scenario plays out. There’s no way in hell they want that to happen to them either!
Who Was Actually At Fault?
The confusing answer here is nobody and everybody was at fault — but that’s because of the word “fault” and how you choose to look at it. Instead, I would say that everyone had some level of responsibility or accountability in a change rolling out — more on this soon. Let’s go through it step by step:
The project was carried out by an individual developer. They played a role.
The project requirements were clarified by the product owner. They played a role.
There was a design document by the individual developer and they chose who to share it with. They played a role again.
The product owner reviewed the design document. They played a role again.
There were two senior engineers who reviewed the document and had feedback they needed to align on. These two engineers played a role.
The individual developer coded up the solution. They played a role again.
The individual developer demonstrated the working feature to the product owner. They both played another role here.
The individual developer put the code up for review. They played another role here.
The two senior engineers reviewed the code with feedback. They both played another role here.
The individual developer corrected the changes. They played another role here.
The senior engineers approved the pull request. They played another role here.
The individual developer submitted the pull request to be built and deployed. They played another role here.
Now it’s not about tallying up who had the biggest role — it’s about who had any role to play along the way. But despite that being a BIG list of roles to play, we’re still not done. Let’s dig a little bit deeper:
The senior engineers approved the pull request for the more junior individual developer without checking about fighting. They played another role here.
Neither the individual developer nor the product owner did any follow-up with the feature once it was deployed. They both played another role here.
The individual developer didn’t write any coded tests for their feature. The senior developers never checked or asked about this — a missed opportunity. All of them played a role here. (Notice that this is the first time the word “test” has shown up in this article)
The team doesn’t have any automatic gates in place for new code getting some degree of testing. The team, in particular the manager, has a role to play here.
Now the scope of responsibility is getting wider and wider. Without dragging this example on much longer, let’s quickly reflect on the post-incident process. Ultimately the manager takes an enormous amount of responsibility in the effectiveness of that post-incident review process. I can say confidently that the way it was conducted is not creating a positive feedback loop and will result in:
Development grinding to a halt over time because of fear
Continued decline in morale
A shrinking team
Radical Accountability
Remember when I asked who was at fault? Did you feel like nobody was at fault or that everybody had some role to play? Let me introduce Radical Accountability.
I don’t know if I’m the first to use this phrase (sorry if you did before me), but I am borrowing it from Radical Candor. And the idea is quite simple:
It’s nobody’s fault, but it’s everyone’s responsibility to improve it. Everyone should be accountable for making sure that going forward, things are in an improved state—regardless of the situation that occurred.
Failures are an opportunity for everyone to improve individually, as a team, and via processes (as necessary). When everyone takes accountability, the entire team can help own and drive improvements.
Everyone wins instead of one person losing.
Everyone can feel safer knowing they’ll be supported if they fail.
Everyone can help build confidence instead of one person being torn down.
Things don’t grind to a halt because people are afraid. Instead, things constantly improve because everyone wants to help improve the future state, and everyone understands they have a part to play.
Instead of working through scenarios and finding someone to blame, everyone can start thinking about what they can do or what the team can do to improve things going forward.
Unless you’re a solo software engineer working on something, it is never one person’s fault. You’re a team and you can all learn and improve together. So then it’s your manager’s fault if they aren’t creating this kind of environment for you and your team, right?
… or maybe you can take some radical accountability and try to make your team better by suggesting you move away from a blame culture.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this course on nailing the behavioral interview:
Weekly Recap
Crucial Coachability Lessons In Software Engineering – Interview With Noah Cantor
What’s one sure-fire recipe for disaster when it comes to coaching?
Not being coachable.
This could come from a lack of self-awareness or not being willing to be coached — but if you’re not ready for it, it’s going to feel like friction.
In my conversation with Noah Cantor, we walked through the various considerations that come into play when it comes to getting coaching and mentorship.
Noah’s framing certainly helped me see how you can try to take all the right steps, but the order and reason behind the steps can REALLY make a difference.
Thanks for the chat, Noah!
Destroying Momentum For Innovation – Principal Software Engineering Manager AMA
What’s the most dangerous phrase for engineering teams?
For a long time, I’d jump right in and say it’s:
It’s always been this way.
That’s a statement that without any follow-up can lead to stagnation and stop curiosity right in its tracks.
But there’s one more phrase that I think is even more dangerous:
“It can’t be done. It’s technically infeasible”
Now I’m not saying we should expect to make the impossible possible, but I am saying that this attitude is what destroys momentum in scaling companies.
Let’s talk about it.
As with all livestreams, I’m looking forward to answering YOUR questions! So join me live and ask in the chat, or you can comment now and I can try to get it answered while I stream.
Today we focus on:
My newsletter focused on iterating from interviews that didn’t go as planned
Jumping into articles/posts from LinkedIn & Reddit
Answering YOUR questions
LIVE CODING – Bye Bye, WordPress! Let’s Start Migrating To Blazor!
It’s time! WordPress on AWS LightSail has been non-stop problems for nearly 2 years now.
Time for a change.
I’ll be looking into using LinkDotNet.Blog by Steven Giesel as my blog engine of choice. But migrations are never easy, so this will be the first of many sessions trying to figure out how I can get my blog setup before going live.
Remember — I need to keep as many links active as possible so I don’t ruin my SEO!
Crack the Code: Breadth vs Depth First C# Iteration Explained
Struggling to understand depth vs breadth-first?
Let’s try a hands-on practical example!
I always found the mathematical or computer science version of these things trickier to understand — but when we have some code to walk through for a real scenario, it seems to click better for me.
Join me for this introductory walkthrough of depth vs breadth-first iteration of a file-folder hierarchy.
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram