Tools and process can help you manage complexity. But they also can serve as a complexity enabler.
https://www.seriouspuzzles.com/krypt-silver-654pc-hard-jigsaw-puzzle-by-ravensburger.htmlTake the ability in Atlassian
’s Jira to add dependencies between tickets across projects. This allows you to create many interrelated projects, and to coordinate activities across teams, but it doesn’t answer whether having those dependencies is a good idea. And it certainly doesn’t put pressure on you to remove them.
Consider the impact of having a team of project managers available to manage “complex projects” that span departments, locales, teams, silos, etc. Sure, this oversight might be important. But it also incentivizes the organization to take on complex projects when they might not be necessary, and to institutionalize hand-offs and larger batches. The projects may run “smoothly”, but it doesn’t mean the arrangement is ideal or resilient to future challenges.
How could those efforts be mediated automatically / with technology vs. a human coordination layer? How could you have mostly autonomous, two pizza sized teams?
Other examples come to mind like your org chart, reporting structures, scaling agile frameworks, tools for creating high fidelity prototypes/wireframes, and certain programming languages / development frameworks. Or something as simple as a having a team of on-call firefighters to keep your product from falling apart.
Even continuous delivery can encourage the buildup of complexity beyond our ability to tame it.
My point isn’t that these things aren’t effective. They are … to a point. But they can blind you to growing complexity, and lull you into not resolving the buildup of complexity in how you work or decoupling units of complexity. Before you know it you’re drowning in complexity, and your systems are ill-prepared to deal with it.
So: always keep in mind how you can battle complexity, create team autonomy, and work down the various forms of debt (including learning, technical, organizational, etc.)