People are not software, no matter how hard we try. That means that some plans and approaches that might seem nice on paper are doomed even before you send the first Slack message to talk about them. It might seem trivial at first pass, but I routinely see people try and do things in a way that doesn’t align with this truth. The bottom line is that no matter how good you think your process is, it’s only as good as how it fits your team.

Don’t get me wrong; I like me a good process flow. You all know there are a bunch of flow charts and diagrams on articles here precisely because they can be valuable in aligning people and short-circuiting issues. Being mindful of your organization’s rituals, processes, and routines is critical, and they require constant gardening and grooming. Nevertheless, you’d be very mistaken to assume that the right Confluence article detailing all steps is all that is necessary in order to scale your team, far from it.

Do any of these sound familiar?

• QA is always surprised at the end of the sprint, so every feature has to go through a senior QA engineer during planning.
• Product’s specs don’t cover every possible edge case; therefore, Engineering should be able to reject planned work that’s not properly introduced at the beginning of an iteration.
• We find that technical tasks sometimes go over estimates, and therefore require two senior engineers to review any design that has an estimate of over X points.
• The designers are unhappy with things when they see completed work, so we mandate fully detailed mockups and wireframes for every scenario.
• The product owners find that the work doesn’t precisely match their requirements, so all tickets are broken into tiny pieces that can be validated one by one.
  

Some of these make more sense than others. None of these are outright wrong, per se. My issue is that this attempts to solve problems at the wrong level.

Back to Agile Roots

Not a lot of web pages look pretty much the same for over a decade. The Agile Manifesto page is one of them. As one of the principles states, we should value “individuals and interactions over processes and tools.” This is often referred to more succinctly as “People over processes.”

People are not software. The perfect flows, abstraction, and decoupling that are hallmarks of great software engineering don’t make sense when it comes to making teams effective in scale. I understand the instinct to try these, but more often than not, when I am brought in to help companies that have these detailed processes, they tend to report that things didn’t get any better. Usually, it just created more bureaucracy and made people bitter.

The right approach to help teams become genuinely empowered and productive rarely involves making people more compartmentalized. Trying to create a “perfect” flow of work where every occurrence of someone going back “upstream” is seen as a mistake is plain wrong. What’s more, these work situations tend to conjure a world where managers are forced into being bottlenecks, as opposed to making space for other people to step up.

Instead, accept that the right approach is to stop siloing people even more. Rather than box people in, treat iterative work and collaboration as the expected flow of things. Working in cross-functional teams often helps make these feedback loops more natural and faster. It also opens up the door to scaling up as managers are not needed to pass the baton during each stage of the work rigidly.

Don’t see these friction points as a necessary evil. Help your leadership team walk the talk and leverage these for growth opportunities. Learning to work better with colleagues, creating free-flowing communication paths, and putting collaboration over strictness make the team more robust and, often, more fun. This is how we create more product engineers as opposed to more principal engineers.