From gatekeepers to enablers

Every organization goes through a stage in its life where boundaries between teams start appearing: developers do the development, infrastructure handles the admin, testers do the testing, etc.

With the specialization comes a redefining and splitting of responsibilities. And time and time again, the whole process comes with a corporate exercise of wall-building between teams: you need release documents, you need a UAT phase, you need to fill this form here or request that deployment there.

In itself, a more structured communication is not an issue, quite the contrary. Generating artefacts in a project to describe processes that cross teams is an important step to take in ensuring maintainability.

Where the team-splitting becomes an impediment is when teams start allocating themselves exclusive competencies: developers shouldn’t know about build scripts, release teams shouldn’t know about development, testers would build their own test scripts and not share them…

Why are teams claiming exclusive access?

Often, teams start by holding many responsibilities. Start-ups are full of people that know everything from coding to deployment to admin. They’re not experts in any particular topic, and they may do mistakes, but they have an involvement in all parts.

As the teams grow, those skills get dissolved. And as products become larger and more complex, and as companies gain visibility, the required skills become more specialized too. Failing a deployment in a small start-up has less impact on the business than when you have signed those 4 or 5 9s contracts with a corporate client.

The immediate reaction at this point is to create a specialized team and focus the skills of team members. Those teams are now responsible for only a small part of the project lifetime, and are judged on the reliability of *their* process rather than on the project itself.

You end up in a situation where the cross-competency skills have already been dissolved because of a larger team with more specialized skills, and what skillsets were present have now been moved in a separate team, diminishing the spread of skills even more. Of course, this will mean that more mistakes will be done by a less-skilled team in a specific area, and the team responsible for that competency will start building walls to protect itself from the resulting unreliability.

Doing some root cause analysis

You’re now in a situation where each team has built walls around it to enforce any phase transition through gatekeepers.

I am convinced that gatekeepers are a symptom of a wider problem in your software development lifecycle. Gatekeepers become a bottleneck, be it because of resources or because the gatekeepers usually know what’s inside the castle but have less knowledge of what is outside the castle. This is true for each competency needed to deliver a project: analysts, testers, build masters, developers, project managers…

How do you solve a problem like Maria?

The first step to resolve those bottlenecks is to take a courageous stance: recognize the competency of teams while preventing them from isolating themselves from the other teams.

There’s usually a lot of hidden pain, a lot of untold mistrust to resolve. Empowering teams starts by recognizing that every single person in the company *is* a skilled professional and *wants* to deliver better software. No buts allowed. You need to start addressing why you hear “those idiots have done this in that way, we can’t trust them”. Why did they do it in such way? Could it be prevented in the future? Can the chain of events that lead to the deadlock be resolved?

Once everybody has gone over their distrust for others, teams need to move from being gatekeepers to being enablers. Instead of building walls and processes, teams should be providing the tools needed by other teams to deliver. Developers provide the tool for the business to make money, analysts provide a tool to help developers understand requirements better. Testers provide the tools for developers to understand what success criteria are defined, and developers will provide testers tools to remove the manual steps involve in their job.

You do everything in your power to avoid groups becoming optimized at their job without the full chain of production being efficient. This is what avoiding local optima is all about.

Ideally, the organizational structure of a company gets changed: people work together on a per-project team. They don’t get shuffled around randomly, and they don’t get judged on metrics specific to their competency.

If a project fails, it’s the team’s responsibility. If a project succeeds, it’s thanks to the team. The project metrics are the only ones that matter. By empowering people and focusing them on project-based success metrics, you not only ensure that everyone has the same objectives, you also cross-pollinate competencies across the company.