High Performing Teams Report More Mistakes
Lessons from Psychological Safety and Metrics Accuracy
Today’s Crafting Tech Teams issue is all about psychological safety in tech teams. How it can impact your goals and visions. Why it impacts the team’s productivity and lessons and use cases from my coaching experience and career.
You will learn the following:
Your metrics are skewed when lacking psychological safety.
The reality of mistakes and learning.
Lessons by Coach Denis from the field.
Your metrics are skewed when lacking psychological safety
Yesterday we looked at the various forms of cultures, combining the main outliers on the psychological safety x standards axes. The axes help you as a leader understand the strategic landscape and where you can go. Understanding these concepts provides you with the much needed clarity on how to get out of those negative feedback loops.
Have a look if you haven’t already 👇
Ready? Okay.
Now let’s look at the first step that is common to all of your journeys options: understanding how your situation messes with your KPIs and metrics. Based on research findings done on Project Aristotle and the book The Fearless Organization, you can quickly surmise how teams with low psych. safety avoid speaking up about issues and reporting issues due to fear of interpersonal risk and being rejected.
This behavior is similar—but not quite identical—to overconfidence. As a seasoned tech lead or manager, you no doubt know what I’m talking about if you’ve ever asked a junior engineer for an estimate or status report.
Metrics impacted will be, but not limited to:
Logged Hours
Budget Spent
Budget Needed
Deadlines
Test Coverage
Deployment Frequency
Defect Rates
Cycle Time
Automated Test Accuracy
Deployment Speed
Meeting Notes
Delivery Estimates
Team Utilisation
Education and Growth Targets
Basically anything that is being used to avoid human conversation in an environment that is psych. unsafe or politically charged. Did the list get your attention? Good. Mark the ones that piqued your interest the most. Let me know about them while you’re at it by replying to this email. 📧
The reality of mistakes and learning
Software projects are for the most part exploratory. Discovery and learning outweigh the duplication of commodity features and repetitive output. This immediately brings us to the main topic of this chapter: connection and learning.
I’ve done my fair share of life coaching aside from being in the tech industry for nearly 20 years. I trained with the best. They helped me bring you a very simple framework that will keep you motivated on solving challenges of this nature:
Judging someone blocks your capacity to feel gratitude and connection towards them.
Feeling unsafe or defensive about making mistakes blocks learning.
Ever had a retrospective where everyone was silent? Asked your team for feedback on something that went wrong and everyone’s avoiding eye contact? Do process issues lead to conversations starting with “I keep saying we should have…”?
Yes, that pain.
Agile, Scrum, Safe, Waterfall—pick your poison. They all try to solidify a collaborative learning experience. Where they all fail is they have no inherent framework for ensuring cultural efforts towards psychological safety and judgement-free connection.
Here’s how you can transform common scenarios:
When something goes wrong…
Take responsibility as a team. Don’t judge the person that fired the shot. Changing your mindset towards your processes and procedures that allowed it to happen will shorten that gut-wrenching feeling of fear.
When someone overestimates their capabilities…
They’ll beat themselves up no matter what you do. If you rub it in, the negative long-term consequence will be 10x worse than what just happened. Instead, show compassion and help stay in the learning mindset. Rather than perfect performance, optimise for perfect consistency along the challenge. The video below by Andrew Huberman pinpoints the neuroscience behind this.
Lessons by Coach Denis from the field
Don’t think of your teams as lesser for having issues with the challenges mentioned above. It is a good sign of introspection and will help you act on it to provide a better environment for everyone. Here are some of my recent successes and failures in this field.
Cancelling Sprints
I coached a team of engineers that struggled to make a significant impact with each sprint. There was a visible gap in what was planned vs reality that no form of documentation or JIRA documents captured. Notably, this was also a pattern that showed strong consistency.
It was cultural, but local to that project.
The team was overworked, overwhelmed and the sprints over-planned. I suggested to their CTO to get the documentation of cadence and size of tickets onto the board after they were finished, rather than asking the team to estimate and log hours. In addition we setup each sprint to a strict goal as they were lacking clear acceptance criteria. What happened? The measured and reported velocity kept going down down down. Delivery speed and impact stayed the same.
The team didn’t slow down. The measurements became more accurate.
The ultimate show of commitment was cancelling a sprint for the first time ever. As the data became reliable enough to perform course corrections in real time, bigger business opportunities could be followed more closely as new knowledge was created. In essence, agile.
Accidental Anxiety
I had a coaching client, one-on-one. They were in the apathy zone and surmised that increasing their level of craftsmanship ability and discipline will help them get out of their emotional low.
I didn’t listen to my gut feeling enough and ended up doing just that. However, as their skill increased instead of getting better, the concerned moodiness got replaced with anxiety.
I failed to establish a safe space for them fast enough that would differ from their work environment and ended up stumbling accidentally straight into hustle mode. This obviously didn’t make any of their goals come closer so we changed course: focusing instead on our mutual coaching space, wellbeing and their relationship with their manager and mentor at the company.
The benefits were almost instantaneous and they managed to draw boundaries with their manager and team that helped them lower their stress levels and land a promotion in a few months.
Fake Standards
I advised a leader on an initiative in an agency. They had 3 different teams that seemed to be too comfortable. Very safe, but the lack of drive and challenges had them stagnating for years and they were facing existential problems with a looming recession knocking on the doors.
As the financial pressures increased, the foundation of high psychological safety started to wobble and get replaced with strict discipline and bolder performance requirements.
The teams were quite different in size, capability and experience levels. They measured budgets heavily by logging hours and comparing to contracts and estimates on the roadmap. The most mature and experienced team seemed to have the most metrics. That was odd as the other two teams had nearly perfect scores. So why was the company struggling?
After shadowing and surveying the teams, I noticed the two perfect teams gave little attention to estimations as they ended up not logging hours once they reached their quota. They simply did free overtime as their local leaders required that of them. This of course was not visible to senior management and I helped them discover and explore the root cause and perceived necessity of this culture.
Over the months, it became clear that the teams were struggling with the indecision of multiple parallel upstream bosses and clients who refused to compromise and prioritise. With the help of some communication, negotiation coaching and DDD event storming, they quickly established a safe environment and improved their safety and accuracy significantly over the next months while also raising standards. They are still around today.
Tomorrow we’ll explore how all ties in to dopamine, TDD and continuous delivery. There will also be a survey as I love getting feedback ♥️