The gods among us

Have you seen, or are you in an organisation or team that has a “Team God”?

I probably should explain. I’ll illustrate by way of the software development sector, although you may recognise similarities in your own business or workplace. Brian (with apologies to Monty Python, for it is usually a “he”) is a lead developer. He’s done several years in the business and through longevity and some office politics is now the expert and conduit for all his department’s activities.

The business funnels all projects and queries through Brian, circumventing the usual roles. Brian becomes not only technical lead, but also test lead, scrum master, business analyst, subject matter expert, application and solution architect. Brian may also become line manager to the development team, controlling team resourcing.

Brian is usually in high demand, spending most days in back-to-back meetings, engagement in other side projects of the business, helping colleagues, customers, and management understand issues, both technical and non-technical, as well as doing his actual job of lead developer.

Typically, Brian works long hours, frequently even weekends. He must plan carefully to take any extended time off, sometimes even calling in or being contacted whilst on holiday or leave. On his return, Brian has an overflowing inbox to tackle. Brian is instrumental in controlling the quality and quantity of work of the rest of the team, including nontechnical members, often having little choice but to drive co-workers to his own feverish intensity of work to mitigate shortcomings in process, skills and resource in his own department and the wider business. And to make up for the fact that Brian is nearly always overworked.

If Brian wants to maintain the little empire that has been built around him, he must keep delivering, and not rock the boat with too much change. Brian certainly doesn’t want to make things better. A smooth-running, well-resourced team with knowledge and skills held collectively would shatter his special position.

For their part, those around Brian like the idea that they can get quick answers and solutions from a single point of contact. People find that their own objectives are streamlined by feeding Brian’s ego. They can delegate ‘difficult’ problems to him without having to make great efforts themselves or take responsibility for those solutions. The business can avoid the cost of filling the roles that Brian appears to juggle so well.

Brian ensures he has the support and respect of a core of his team members and his immediate line manager. Together they plaster over the cracks that inevitably appear and do just enough to ensure that the wheels don’t come off.

The wider business doesn’t care how the work gets done, because it’s the results that count, right? They prefer to look at “the big picture” and in any case, the business’s bottom line looks healthy. After all, they trust Brian and his team.

A Team God is born

Most people and businesses know that having a Team God is a bad thing.

Having such a concentration of knowledge, skills, and control in one individual is extremely dangerous, yet a Team God like Brian is one of the most effective ways to solve the issues caused by nearly every shortcut a business may take.

Few businesses set out to create a Team God; it just happens under circumstances of poor management and a persistent culture of short-term thinking and inadequate resourcing.

1. Brian starts in the business as a senior developer, for example.

2. The business or department grows rapidly, and Brian’s knowledge and skills make him critical to some projects or products that had to be developed quickly to match the pace of growth.

3. Management and new staff find it easier and quicker (and cheaper) to simply refer their questions to Brian. Brian offers a quick fix or a quick answer.

He just knows, you see.

4. Knowledge become concentrated in Brian. Whilst, others know a part of the picture, or even large parts of it – only Brian understands the full picture and the critical, fragile parts of the systems.

5. Brian becomes Team God.

Depending on the size and type of business, Brian’s successes or failures now become directly linked with the success or failure of almost every project.

Team Gods deliver

A Team God is expected to do it all. And he usually does.

No business analysts? No problem. Brian has worked in this department for years and knows the business and systems like the back of his hand. We’ll invite him to the project kick-off meeting, and he’ll take it from there.

No plan? Well, we have a deadline, so we’ll make sure Brian knows how critical it is for us to get delivery by then. Brian has a can-do attitude. He’ll manage his team resource and make this a priority.

What about time for testing and quality assurance? We haven’t written any acceptance criteria or bottomed out all the requirements, but Brian’s done this kind of project for this kind of client before so knows what’s expected. He’ll make sure the testers know which bits are critical to test.

Team Gods are not eternal

Eventually Brian will leave. It might be for personal reasons, a new job, or stress and burnout. Those are the positive reasons.

On the negative side, Brian may leave because of a rise in friction or falling out with other team members or management.

Brian’s future might be sealed when a dramatic system failure or incident exposes the precarious way the business has been operating. Since Brian is central to almost everything, the axe will fall on him. Brian’s reputation will probably not crumble instantly, but questions will be asked. Efforts will be made to dilute the over-reliance on Brian. With his authority gone, Brian’s position becomes untenable, and he almost inevitably resigns.

Initial attempts to recruit and retain a like-for-like replacement Team God inevitably fail. Brian’s role finally gets properly defined. A significant and expensive team restructure invariably follows. New blood is brought into the team; people who have never known the Team God and are intent on change.

Systems and processes are finally improved with great cost and disruption as the team and business grapples with gaps in knowledge and process, exposed technical issues, drops in productivity and quality, and even reduced customer satisfaction.

Inspiration

In “The E Myth Revisited” (Chapter 5) Michael Gerber touches on the risk of creating a ‘Harry’ or ‘Elizabeth’ – a person given too much control over a small business because the owner doesn’t have the ability, courage, or desire to get involved himself.

This article is inspired by my real-world experience of that phenomenon in the business of software development.