Software Engineering won't be over | timomeh.de<br>Skip header to navigation

this meeting could've been a boundary violation with<br>Timo Mämecke

Skip navigation to main

Back

Jump back to navigation<br>Engineering, Reads<br>May 25, 2026, 10 minute read

Software Engineering won’t be over

Every few months, software engineering will be over in a few months again. It can’t be, but for reasons you might not expect.

When coming back to work in the beginning of 2026, organizations everywhere were going crazy. So many people, including lots of upper management, had used the winter break to build software with AI and felt that software engineering was over. They had experienced it first-hand. Everything had changed, because look at what they built! Why couldn’t work feel the same?

Their experiences were real, but they happened in isolation. Building software by yourself is orders of magnitude easier than building it in a team, or across multiple teams. The hard problem at work was never just about writing code. Their experiences didn’t reflect the challenges of the organization they worked in.

Organizations divide ownership

Organizations aren’t challenging simply because their structure is wrong and they need to fix it. Their structure might be wrong, but every structure is wrong for someone. If you were ever part of a reorg, you probably saw that some people thought it solved the problem, while others thought it made everything worse.

Still, organizations have to structure themselves somehow. Not everyone can know everything and work on everything. So they divide the work into domains, with a team for each domain. Over time, each team builds deep knowledge around its domain and develops a vision for where it should go.

This is good agile software development: people take ownership, plan, build, adjust, and learn from what happens. But those domains are never fully isolated. They overlap or depend on each other, and they keep changing as the product changes.

The tension in ownership

This ownership model that produces great results is also the main reason why organizational structures are so difficult. It’s hard to give teams a lot of autonomy to materialize their own vision, while also making sure that they don’t create issues for other teams and largely follow the grand vision of the company.

These are the two values autonomy and alignment . We need both values not simply because they are good values to have, but because each one solves a failure mode that the other one creates:

Pure autonomy without alignment results in teams that move fast in incompatible directions. You ship a lot, but it doesn’t add up to anything coherent. Eventually you accumulate so much inconsistency that the organization slows down anyway: integration nightmares, bad user experiences, duplicated work.

Pure alignment without autonomy results in an organization that knows exactly where to go but can barely move. Every decision needs sign-off, every team is blocked waiting for consensus. And after waiting for so long before shipping anything, you learn from your users that you shipped the wrong thing.

Autonomy and alignment are in tension, but this tension is important, even if it feels frustrating. It feels frustrating because the symptoms look like problems we need to fix: the meeting that should have been a Slack message, the RFC nobody reads, the three different date pickers that all don’t work for what you need. Some people ask for more process, trying to create alignment. Others want to strip process away, trying to restore autonomy.

The tension never goes away. It cannot go away. It just moves closer to one of the failure modes.

Tension needs to be felt

It’s tempting to use AI to skip the tension that we feel. Instead of talking to another team, we can describe their boundaries to an agent: what it can touch, what it should avoid, what vision it should work towards, and generally how it should behave around their domain.

But when the agent needs a change that crosses these boundaries, it will not negotiate. It doesn’t feel awkward about stepping into someone else’s area. It will work around the boundaries instead. It can easily copy some code from another team, paste it into the area without these boundaries, make the small change there, and move on.

For a senior engineer, that would feel wrong. The consequences are immediately obvious: now you have to maintain that new version, the two versions will diverge over time, and bug fixes will eventually be applied to one version but not the other. This feeling is worse than the discomfort of going through the tension with the other team. So you reach out and explain what you need. And somewhere in that conversation, your work shapes their domain, their context shapes your solution, and the organization becomes slightly more aligned than it was before.

The human feeling is important. It is what makes you stop before turning tension into a bad decision for the organization. It...