I don’t know if it is still common, but “back in my day,” there was a distinct stage in an engineer’s career: the complexification. That was when one would first find out about some topic, often the phenomenal Design Patterns book, and go into a frenzy trying to force one’s newfound knowledge into use. It’s better than having only a hammer, but it still boils down to a compact toolbox. That is how you end up creating an overly complicated and too clever codebase filled to the brim with facades, flyweight objects, and builders of factories. You’re likely grinning, thinking back about your own such adventures of yore and spotting the equivalent taking place for some of your junior staff. The problem is that a similar malady seems to hurt R&D teams.

I notice two typical scenarios in my work where teams go overboard with complexity in their processes and culture.

Case 1: The Second System Syndrome

The “second-system syndrome” comes from The Mythical Man-Month, where Brooks describes how people tend to make their second big project overly complicated because they are trying to apply all of their lessons from past mistakes. This well-intended practice often ends up in a death spiral, as the project becomes cumbersome and slow to move from its initial phases.

The organization equivalent is when a new team or group attempts to bring in practices and processes from their Big Tech past (or merely copying what’s published publicly). That’s how we end up with departments where there are sometimes more managers than ICs, hiring processes that are unsuitable for the company’s stage, or a delirious commitment to generate copious amounts of documents at every step of the SDLC.

From the outside, it looks like an attempt to put on running shoes and gym clothes on newborns to prod them to run before they can hold their own heads. Cute in a weird way, but futile nonetheless. Instead, we want to use our experience and yet remain open to evolution. Like second-time parents apply their experience yet accept that each child is different.

Case 2: The Pendulum Swing Overcorrection

This other typical case starts completely different. The team embraces agility and less structure in its early days and gets by. This simple setup works for a while, but when most structure, planning, and processes are religiously pushed aside, it eventually harms productivity.

These startups find themselves grinding to a halt a year or two after kicking off (and sometimes much sooner). It is at this point that people overshoot their efforts to correct the situation by starting to nail down processes, specifications, and “communication protocols” between people in the team. What used to be a “fun startup” morphs into a bureaucratic kingdom within weeks.

The Case for Common Sense

Both of the above scenarios have the same solution or way to avoid them: to accept the evolutional nature of organizations and teams. There is no “one true process” or manner of doing things. There’s no point in which you, as an executive, get to put your legs up and declare that your work is done, and the team can go on cruise control from now. Things are constantly changing and evolving, and so we have to work on processes regularly.

To ensure that your team doesn’t put in place too many processes or neglect them for too long, the only answer that I have is that we should make this a part of our daily jobs. After thousands of conversations with executives, what I know that works is common sense. Treat your team as adults rather than seeking assurances in the form of overly complex processes.

You should avoid creating detailed procedures when human interaction can suffice. For all but the truly large organizations, allowing teams to have the leeway to define their preferred modes of work and baking agility into the culture is likely the right way. Don’t assume that others are not going to do their part. Don’t create a DMV-like ambiance. Demand that the people collaborate responsibly and routinely review and inspect how things are going to spot areas for improvement. Allow things to form organically, like a lobster’s shell: It doesn’t harden immediately but takes time. This might sound like common sense. It is!

<shameless-plug> If you’re looking for more practical ways to make your team better, reach out or check out the London Leadership Leap this July: An exclusive masterclass for tech executives who want to propel themselves to newer heights, dramatically improve their performance, and start on the path to triple impact-per-engineer. </shameless-plug>