The teams were not the challenge

I have repeatedly inherited teams described as challenging, slow or unwilling to follow instructions. I never assume the label is true. I find out what is actually stopping people from doing good work.

In company #1, experienced engineers had too little room to use their judgment. In company #2, delivery pressure was competing with legitimate platform and compliance risks. In company #3, too much influence had become concentrated in one senior voice. Different challenges needed different interventions. Blaming the team would have fixed none of them.

I listen first, make expectations clear, protect useful disagreement and hold the quality bar. Once people feel trusted and understand what good looks like, they usually take ownership and delivery follows.

I joined a very senior product team that had been described as slow, underperforming and challenging. It was remote, multicultural and working across a large organisational divide.

The challenge was not lack of ability. Experienced engineers had too little room to use their judgment and take ownership. I earned their trust, reduced the surrounding noise and gave them the stability and clarity to concentrate on the work.

The team went from being called slow to repeatedly surprising stakeholders with what it delivered in PI reviews. We also delivered the product's first hybrid on-premises arrangement, keeping the necessary connection to the main platform.

When one frontend developer asked how to move into management, I spent many hours helping him identify what to develop and change. He later moved into management and is now an Engineering Director.

I joined a senior engineering team whose concerns were being interpreted as resistance to delivery. When I listened, I found they were raising valid issues around technical debt, unsupported libraries, Java migration, performance and compliance in highly regulated clinical-trial software.

I became the bridge between the team's technical reality and the company's customer commitments. We secured time for the necessary platform work and built a credible feature plan instead of pretending either side could simply be ignored.

When a major customer needed the platform for a high-profile trial, the existing system could not yet handle the required scale. I worked through the challenge with the team and architects, helped align the technical plan with management, and the platform successfully supported the trial.

Before I left, one frontend developer asked whether she could take over my PO responsibilities. I mentored her through the role, and she has continued happily as a PO.

I led a distributed development team working with global customers. Too much influence had become concentrated in one senior voice, and other people had gradually stopped contributing.

I made it clear that everyone's knowledge, opinions and work mattered. The rest of the team started speaking, questioning and taking ownership. The senior developer shifted towards a more useful mentoring role.

The result was not obedience. It was a happier team that understood the work, cared about it and wanted to contribute.