Coaching is such an integral part of our product delivery model that it’s very easy for us to forget the role of a Team Coach isn’t standard in every digital studio or agency.
A few years back, ustwo re-evaluated some of our most foundational ways of working – here's what we wrote about it at the time. As a result of research and experimentation with Agile/Lean methods, we began to transition from teams led by project managers to a coaching-led model.
In moving away from a more traditional approach, the problems that arose in teams were less bureaucratic (schedules, budgets) and more people-centered (communication, team building, collaboration). Coaching allowed us to better address the complexities of these more nuanced dynamics.
While influenced by Agile, coaching for us does not mean a wholesale embrace of the methodology. Nor does it mean simply ‘managing’ people rather than tasks. It’s about a flexible approach that uses subtle, human-centered thinking to make teams work.
Our embrace of coaching sustains not only our internal teams but also our business relationships. Increasingly, clients look to us for Agile transformation support. We empower our partners to implement change that continues well beyond a project's completion by shifting their focus to values and outcomes, rather than feature lists.
So, if you're new to the concept of coaching and how it can significantly improve product delivery, here are some answers to questions I'm frequently asked by new clients.
How do you bring coaching into well-established product teams?
Bringing a coach into a well-established product team is mainly about two things:
- Ensuring there's buy-in at all levels for the use of a coach
- Clarity about what the coach is there to accomplish
But – I suspect – there is a slightly different question you could ask here, and that's: How do you bring contemporary ways of working into well-established product teams, of which coaching is only one part?
Well, it's very helpful to bring in a team coach who understands how to support teams making a transition to a more collaborative, incremental approach.
The coach will help the team understand the reasons for making the change and identify the starting point for the journey. This kind of change depends so much on behaviour and mindset adjustments, not only for the team but for those who have influence on them.
Which brings me to my second point: behavioural and mindset changes (the people part) take time, so the change must be taken in 'baby steps'. It's usually very difficult to move wholesale to a radically different way of working. And if you do, it's usually not long before teams revert to their previous ways. And remember, for some, even small steps may seem radical.
How do you deal with really big teams?
The key to dealing with really large teams is to split them into smaller teams of no more than nine. We aim for each smaller team to be able to deliver a working increment of the product themselves, commonly referring to them as ‘Feature Teams’.
On a large project, say 80 team members across eight teams, it's also important there are structures in place to ensure adequate communication across teams in all areas – design, product, technical, ways of working and so on.
How do you maintain collaboration when you've designed ahead?
When we see that a development team is able to proceed without needing much designer time, there's a tendency to want to keep designers busy by giving them additional features to work on, while the developers and testers get on with it.
The propensity to keep designing ahead stops when we realise that we've reverted to designing features without adequate involvement from the rest of the team. That leads to two classic problems:
- Having inadequate input from the tech team, to ensure the feasibility of our designs
- A reduction in engagement from tech, as they've had less opportunity to contribute to the designs
The key to staying out of that situation is to value keeping the team working together on features. To use the analogy of a relay race: watch the baton, not the runners. Care more about the pace at which the work is being completed, rather than how busy everyone on the team is at every moment.
How do you keep politics out of a coaching role?
It's important that the role of coach is not political. They can have a great deal of influence on the organisation and therefore should be looking out for the best interests of the company (which usually means the product team). Good coaches will do exactly that.
In my experience, the concern is less about the politics of the coach role, but rather the degree to which the coach can sustain being a change agent. How long can they try to bring about change in the organisation, before they start to accept the status quo?
It's for that reason that many have said – myself included – that organisations should use external coaches. There’s more of a chance the organisation will be challenged on how things are done today, than with a full-time permanent staff member.
How do you get siloed groups to collaborate?
Collaboration between discipline groups (product managers, designers, developers), is often hampered by the organisational structures that isolate these disciplines into departmental silos.
To a certain extent, it makes perfect sense to concentrate skills and provide that skill as a service to the organisation. However, this model places a limit on the collaboration required for today's product development.
It does so by splitting the focus of individuals across multiple products, decreasing efficiency due to context switching, reduced delivery predictability, reduced engagement with the products and reduced cohesion as a product team. This ultimately means the creation of inferior products at a slower pace.
This model is systemic. It can only change when we climb high enough in the organisation where someone responsible across all silos decides to make the change. In some organisations, that's the CEO.
If that person isn't ready to make changes remember that senior people responsible for individual silos, can also decide to work beyond the ‘boundaries’ of their areas. On all levels however, compensation models, and fear of losing power and control, can act as additional inhibitors to collaboration.
How do you deal with conflicting priorities?
When teams have to coordinate across team boundaries, each team will have its priorities and scheduled commitments. When these don't align – you get conflict.
The way to minimise this is to structure teams around products, not around skills. Even with teams structured around products, you will still encounter dependencies across products, but there should be fewer and they should be easier to negotiate.
How do you remove friction?
When attempting to move towards collaborative and incremental product delivery, the established way of doing things will cause friction, impeding your progress. That’s natural. This is why it’s essential to have senior stakeholders on board with change. Without active senior support, you can’t expect a team to change their ways of working or inspire others to follow suit.
In many organisations, the pitch for making the change is presented as "we should be using Agile", or some variation that evangelises a way of working instead of rooting the pitch in addressing business challenges.
A far more persuasive method is to focus on the quantifiable benefits of a new approach. When clients have seen how a one-team approach can bring a new product, or product feature, to market more quickly, the senior teams will find it more difficult to refute a substantial metric and demonstrable benefit.