A healthy technological ecosystem

Ask most teams to describe their technology ecosystem and you’ll get a list of tools. Languages, frameworks, the cloud bill, whichever dashboards are in fashion this quarter. We’ve sat through plenty of those audits. The list is real, but it’s the visible tip of the thing. The ecosystem that actually decides whether software is any good is made of people: the ones who build it, the ones who keep it alive at 2 a.m., and the ones who have to live inside whatever we ship.

That sounds soft until you notice how structural it is. There’s a famous observation from 1968: any organization that designs a system will end up producing one whose shape mirrors the organization’s own lines of communication.¹ Read it the unflattering way and it stings a little. If the company is tangled and anxious and siloed, the software will be too. The architecture is a portrait of the people who drew it, whether they meant to sit for it or not.

The stack is mostly people

For a mission-oriented company this matters twice over, because the mission doesn’t live in any single person’s code. It lives in the seams between people, the handoffs and the half-sentences in a thread. We’ve watched a good feature quietly get worse, not because anyone wrote bad code, but because two teams had stopped really talking, and the product reproduced the gap with perfect fidelity. So the first thing a healthy ecosystem needs isn’t a tool at all. It’s the wiring between the humans, and that wiring is infrastructure whether you maintain it or not.

What the makers need

If the people are the system, then supporting them is engineering, not charity. Google spent years on this, an internal study trying to find what separated their best teams from the rest. It wasn’t talent, or seniority, or who was in the room. The strongest predictor was psychological safety.² The phrase comes from the researcher Amy Edmondson, who defined it as a shared sense that a team is safe for taking interpersonal risks: the ordinary confidence to say “I don’t understand this” or “I think we broke it” without paying for it later.³ That’s not a soft perk. Bugs breed in exactly the places people are too nervous to point at.

The longer-run data says the same thing from another angle. A decade of research across tens of thousands of engineers found that the teams who deliver best are also the ones reporting less burnout and more satisfaction, and that this tracks closely with steady priorities, supportive leaders, and tooling that removes friction instead of adding it.⁴ Good tools, in this reading, aren’t about going faster for its own sake. They’re about handing people back their attention. A healthy ecosystem protects the people inside it. An unhealthy one taxes them quietly, a few minutes and a little morale at a time, until the ones you most wanted to keep are the first to leave.

A frantic team ships frantic software. The user feels the org chart they never see.

It reaches the other end

None of this would belong in an essay about technology if it stayed inside the building. It doesn’t. A study from 1994 traced that the quality of the support employees receive turns, link by link, into the quality of service customers feel.⁵ Wear a team down and the software wears down with it. A supported one tends to build things that feel tended. Your users will never see your org chart, but they feel its temperature in every loading spinner, every error message that does or doesn’t explain itself, every edge case somebody either had the room to handle or didn’t.

So when we say we care about a healthy technological ecosystem, we don’t only mean the stack. We keep teams small enough to actually talk. We treat “is anyone dreading this?” as a real engineering question. A healthy ecosystem is people, the ones who build it, the ones who keep it standing, and the ones who live in what we make. Get the people right and the technology finally has a chance. Get them wrong, and no stack on earth will cover for it.