true autonomy is a balancing act

So it turns out humans are, by default, pretty bad at nuanced thinking: we love all-or-nothing, black-and-white, good-versus-evil.  Feels nice and simple, refreshing in a complex world.  Too bad it's useless in most modern real-world situations.

In the tech industry, one place this shows up is around IT centralisation.

Enter Central IT and Product Team.

Central IT: "We can't let teams choose their own tools!  Otherwise we'll have to support too many different technologies, and product teams will waste time re-inventing the wheel."

Product Team: "We have to be able to choose our own tools!  Otherwise we can't build what our users need, and we won't be a real Empowered Product Team (tm)."

Exeunt omnes, in despair and frustration.

The problem is that "autonomy" isn't a binary choice.  It's a balancing act.

Central IT is right: in the absence of strong tech foundations, product teams will invent their own, because they need those foundations to build products.  Product teams are right: no single set of tools can fit all use cases, and tech foundations must evolve over time to meet changing needs.

Let's unpack this a bit.  What does it take to deliver a modern digital product?  Here's a long-but-still-partial-list:

• Infrastructure: usually cloud-based; often provisioned via infrastructure-as-code (IaC) tools; sometimes containerised
• Environments: dev, qa, prod; maybe staging; maybe even on-demand environments per feature branch / PR
• Continuous Integration + Deployment (CI / CD): often tied to source control provider (e.g. Github Actions) or cloud provider (e.g. CodeDeploy)
• Logging + monitoring: application logs, system stats, error reporting; high-signal alerting; incident response processes; SLAs and SLOs
• Analytics: page views, clicks, referrers; custom events + funnels; key metrics; dashboards to track those metrics
• Data pipelines: to get data into some data lake / warehouse, for broader reuse / analysis across teams;
• Integrations: connections to other APIs, operational data stores, or other data sources (don't you love Excel?)
• Secrets management: secure storage and delivery of third-party credentials + API keys; often tied to cloud provider (e.g. AWS SSM)
• Email notifications: often via some high-deliverability email provider; HTML templates that will actually work across common email clients
• Background jobs: for bulk data import, report generation, or anything else that takes longer than 10 seconds; often message queue + job runners
• Data stores: often managed SQL database (e.g. RDS); maybe something else (e.g. DynamoDB, headless CMS, etc.); maybe with a cache in front
• Automated Testing: unit, integration, and end-to-end testing; coverage metrics; recording, snapshots, and transactional tests for reliability
• Developer Experience (DX) Tools: linting, auto-formatting, and other static analysis tools
• Source Control Workflow: almost always "how do we use git in practice?"; often tied to source control provider (e.g. Github PRs)
• What the Users See: application framework; in-house and third-party dependencies

Whew!  It's a lot.  Reading HTMX memes and microservices hit pieces, it's tempting to imagine you can do without 80% of this.  But CI / CD, analytics, testing, or DX tooling are still Good Ideas even if you're all-in on islands architecture or monoliths.  Unless you like spending time on manual deploys, re-fixing old bugs, or code styling debates?  Didn't think so.

This list is an invitation to think: what's the right tradeoff for my team, product, and organisation?  Where will it add value for my product team to have autonomy?  Where will it add value to have foundations that Just Work?

You have to ask "where should we have autonomy?" instead of "should we have autonomy?"  The answer to the latter is of course yes, which means it's a useless question.

Where it makes sense for product teams to have autonomy, let them.  Where it makes sense to invest in proper tech foundations, do so, and approach it as you would any other product, just with internal users.  That means you reach out to internal teams, learn their pain points, prioritise, test solutions with users, and iterate.  That means you elevate and recognise work on foundational tools, whether it happens in a dedicated team or in a more grassroots manner.

And above all: that means you shift the conversation on autonomy from "can we choose our own tech stack?" to "are we empowered to define problems and deliver solutions for our users and for the business?"