De-risk the Team—Behind the scenes on team coaching, part one
A glimpse into my coaching work
Today’s Crafting Tech Teams issue gives you a glimpse into how teams use coaching and technical training to their advantage. This is a condensed overview of what to look for when you are researching how to perform cultural shifts in your product engineering department, especially on a team level.
These contain questions and insights from my interviews with EMs and heads of engineering. Adding some secret sauce from my own experience, you’ll also find my commentary with advice to coaches. You will learn the following:
Three pillars.
A tech team is a complex system. It is best nurtured by multiple, overlapping incentives in aggregate.
Pillar One: Leadership. Cultural changes have a single point of failure: the leader driving the change. Expose the good and bad habits. Stop the risk. Build more responsibly.
Pillar Two: Team Strategy. Does the team understand how they fit into the business processes? How to set up incentives that open doors and enable collaboration with domain experts.
Pillar Three: Team Tactics. The rubber hits the road quickly during coaching. This isn’t a workshop with isolated katas. The team needs new tools, new ways of thinking and new responses to the incentives and inter-department collaboration.
Three Pillars
There’s nothing worse than ineffective training. Attend a conference, read a book. Fly someone in to host a workshop. You take the day off to attend, forgetting the complexities of the project you’re working on to join a clean, isolated kata. When you return, you forget the complexities of the kata and understanding it carried for you and you isolate yourself on your project once more. Euwgh!
The main questions to focus on overall before we get into the main pillars:
Who owns this transformation?
Who has the most skin in the game?
What’s the desired outcome?
How will the business notice we’ve achieved it?
Why is now a good time?
What is the tangible opportunity cost of leaving things the way they are?
Who needs to be involved with buy-in in order to guarantee success?
Focus on knowing: apply and practice your understanding. Learn just enough so you can apply it and experiment with it. After all, that’s why 95% of software engineers joined this field. It took me a few to find a tech and leadership coaching strategy that aligns with this. But the teams I work with respond very well to it and show immediate change. This form of learning is naturally intuitive. I went into a bit more detail on learning intuition in a previous article👇
Stop Blocking your Team's Intuition
Pillar One: Leadership
Regardless of your title—senior engineer, tech lead, engineering manager, VPE—you will find that efforts to implement fact-based productivity changes based on team behavior and habits is a fool’s errand. While your efforts are benevolent, they are not the first step to success. Success starts with leading with intention and to serve the team.
The greatest risk software projects face is whether their developers can work as a team.
For example, It’s impossible to instil a culture of better craftsmanship in a team that is constantly feeling overwhelmed. A more useful approach is:
Ask why are they overwhelmed?
What prevents better practices?
What is the perceived scarce resource for your teams? Is it time? It could be focus. Your team may have been accidentally incentivised purely by stress and money and got stuck there.
Are processes in place that only make sense for slow teams?
Who on the team is overwhelmed or feeling unsafe, unheard?
What are the personal aspirations of each members?
How do their growth plans complement and overlap with company goals?
What do your KPIs tell you? Are they being gamed? Is it time for different ones?
A coach will address such issues with you on a weekly basis. Transformation may take years, but improvement should be every day and every week. Small things count. A leader seeking exponential growth and opportunity requires a still, focused mind. That is attained once these questions and processes become second-nature than can be delegated or automated.
Note to coaches: The leader is wearing many hats. Try to find out which hat has the most leverage and what other fires require ongoing involvement. You’re building a relationship, not just fixing a problem. Put the human in front of you and their needs first.
Pillar Two: Team Strategy
Strategy in a team-context comes in two parts: understanding business impact and product vision. A team can follow very good delivery practices but without understanding of the product or the impact they are having on key business metrics they will always rely on top-down management, delegation and prioritisation. This need for control is what prevents such teams from embodying their full potential.
This type of team meetings are usually theoretical or conversational:
Introducing new management or architecture concepts
Discussing and documenting current processes
Setting intentions and finding overlaps with personal goals
What does each member team think the priorities are? Do they agree on this?
Are there conflicting incentives and goals being pursued in the week (or sprint)?
What important milestones is the team facing in the near future regarding their roadmap and career development? How can you help? What’s in the way?
Note to coaches: Name of the game is collaboration. Look for signals where the team “dozes off” during the call and isn’t paying attention. This isn’t caused by you. They simply have their attention on something much more pressing and concerning. Figure out what that is and reprioritise! I often get priorities and self-diagnosis here wrong even after a year of doing this. I following-up with team members more actively now and put up the strategy and tactical meetings for a vote, ie.:
Pillar Three: Team Tactics
Tactical meetings capture hands-on work that the team can apply immediately that day. Usually practical matters like coding, and refactoring, but also negotiation skills, how to lead certain meeting and story slicing, architecture diagrams.
Craftsmanship trainings have curious side-effects. As you start and peel back the layers, you arrive at a cross-roads of many different practices.
When the team wants to learn TDD they end up realising they need more practice refactoring, design and business behavior disciplines.
Focus on CI/CD and you can’t get far without understanding and re-shaping communication structures in the organization along with management incentives and project visibility.
This will bring about moments of vulnerability that may trigger impostor self-talk and lower confidence. The coach will help set up an environment where such vulnerability and knowledge-leveling is welcome. Rebuild the negative emotional loops that prevent new learning.
I do this a lot with the book club when teaching speed reading. Our focus is to constantly push forward the “default reset point of comfort” while increasing the pace of reading. Discomfort always manifests during practice as the body will try to regain its control over the known. Even when it doesn’t make sense, like when reading the book upside down.
Identify where the team grapples with the past. A coach will help the team re-focus their attention. A productive team deals with present problems and future opportunities. When stuck in the past—ie. tech debt and defect triage—they are bound to recreate that same environment.
The goal is simple. De-risk the team: “Is our chosen path forward less risky than what we have been doing so far?”
Note to coaches: Optimise for the confidence of each member, rather than the complete agenda. There will be moments where someone doesn’t get something or is struggling to understand. Perhaps they get it but disagree and that makes it hard for them to speak up. Look for these opportunities and push to level the playing field as much as possible. The team wants to leave these meetings feeling confident they learned something new and can apply it from now on.
In part two we will be looking at ways to measure the team’s engagements and check the overall temperature for the team’s well-being.