The Org Chart Trap: Why Your Company Structure Is Silently Killing Velocity

We need to talk about org structure. Not the theoretical kind you’ll find in business school textbooks, but the messy, real-world kind that determines whether your engineers spend their days writing code or writing emails requesting permission to write code.

As the management thinker Peter Drucker once observed, “The best way to predict the future is to create it.” Yet most companies do the opposite with their organisational structure — they let it emerge haphazardly, layer by layer, until one day they wake up wondering why it takes three weeks and seventeen approvals to change a button colour.

I’ve spent over a decade building and leading engineering teams here at Agoda in Bangkok, and a decade before that in Australia, and I’ve watched the same pattern repeat across companies of all sizes: they start flat, fast, and collaborative, then gradually calcify into something resembling a Soviet-era bureaucracy. The good news? It doesn’t have to be this way. The bad news? Preventing it requires active, deliberate effort from day one.

Keep It Flat Until It Hurts

Here’s my first piece of advice for anyone scaling a tech company: keep your org structure as flat as humanly possible, for as long as you possibly can.

I know what you’re thinking. “But we need managers to coordinate! We need layers for career progression! We need hierarchy to handle complexity!” And you’re not entirely wrong — at some point, you’ll need structure. But that point comes much later than most companies think, and the structure you need is almost certainly less than you imagine.

Every layer you add is a layer of latency. Information that flows up must flow back down. Decisions that could be made in minutes get scheduled into meetings. Context gets lost in translation. The physicist Richard Feynman once said, “The first principle is that you must not fool yourself — and you are the easiest person to fool.” Companies fool themselves constantly about how much hierarchy they actually need, confusing organisational complexity with organisational maturity.

Flat structures bring real benefits: faster decision-making, clearer accountability, and that intangible sense of everyone being in the same boat. When engineers can walk up to a VP and ask a question, when product managers can make calls without committee approval, when the distance between “idea” and “implementation” is measured in conversations rather than calendar invites — that’s when magic happens.

When I first started at Agoda, the CEO and CTO offices were on the same level as the engineers. Most of the day, their doors were open — you could just walk in and talk to them. And I did. I was having a conversation with my boss one day about buying a license for GitHub, and he remarked, “If you want to do that, I’ll have to ask Yaron for money.” There was a tone in his voice — I knew he didn’t want to do that. So I simply said, “Well, I’ll go do it.” He paused, then said, “Okay, fine.” And I walked into the CTO’s office and we started talking.

That’s what flat actually looks like. Not an org chart with fewer boxes, but a culture where a mid-level engineer can walk into the CTO’s office and have a conversation about tooling without scheduling a meeting three weeks out or preparing a twelve-slide business case. The barrier between “I have a problem” and “I’m talking to someone who can solve it” was measured in metres, not management layers.

The challenge, of course, is that flat organisations require something that doesn’t scale naturally: trust. You need to trust people to make good decisions, to escalate appropriately, to use judgment rather than waiting for instructions.

When I first set up TeamCity at Agoda, we gave all the engineers admin access. Every single one of them. We trusted them. That build system was in place for seven years. In that entire time, we had exactly two production incidents: one from an engineer installing a plugin that failed, and another because an engineer on his first day pressed the “update” button, thinking he was on his own instance. Poor guy.

Two incidents in seven years. Hundreds of engineers with admin access. We trusted them, gave them responsibility, and they took ownership. That’s what happens when you treat professional people like professionals. The alternative — locking everything down, requiring tickets for every change, making people ask permission to do their jobs — doesn’t actually prevent incidents. It just makes everyone move slower and feel less invested in the outcome.

And building that trust requires something else entirely.

The Case for Colocation (Yes, Still)

Let’s address the elephant in the room — or rather, the elephant that used to be in the room before it started working from home: remote work.

I know this is controversial. I know the pandemic proved that remote work is technically possible. I know talented engineers live everywhere, and I know there are legitimate reasons people prefer working from home. But after watching multiple cycles of this experiment play out across the industry, I’ve come to an uncomfortable conclusion: remote-first rarely makes for a productive workforce, particularly in environments that depend on high-bandwidth collaboration.

This isn’t a new debate, by the way. We’ve been trying this every few decades and rolling it back. IBM pioneered telecommuting in 1979, grew their remote workforce to 40% of 386,000 employees by 2009, then called everyone back to the office in 2017. Yahoo banned remote work in 2013 under Marissa Mayer. Best Buy killed their famous “Results Only Work Environment” programme the same year. The pattern keeps repeating because the fundamental tension never resolves: there’s something about physical presence that we haven’t successfully replicated digitally.

That something is what I call “accidental communication” — the water cooler conversations, the overheard problems, the spontaneous whiteboard sessions that happen when humans occupy the same physical space. When you’re co-located, you absorb context through osmosis. You learn what other teams are struggling with. You notice when someone looks frustrated and offer help. You build relationships that make future collaboration frictionless.

I was talking to one of my engineers recently about cross-team dependencies. He mentioned that whenever he’s waiting on a code review from another team, he just walks over to their area. “What if they’re busy?” I asked. “I sit down at a desk near them and wait,” he said. “Isn’t that a bit intimidating?” I pressed. He smiled. “Well, I do bring them snacks, so I don’t think they mind.”

It was a brilliant example of people using colocation to its full advantage. Not just cutting through red tape, but doing it with empathy — and understanding that Thai people are self-confessed foodies helps. I smiled realising this expat had cottoned on to the cultural nuance and was using it effectively. That kind of organic, relationship-building problem-solving simply doesn’t happen in a remote-first environment where everything requires a scheduled Zoom call.

The Remote Work Exception That Proves the Rule

Now, I’m not saying remote work never works. I’ve seen it work only once or twice in my career, and the circumstances were instructive.

Years ago, I worked with an online gaming network called Game On. We ran Counter-Strike: Source tournaments for semi-pro gamers. The entire staff were gamers themselves, and we sat together in a Ventrilo room using push-to-talk audio. Push a button on my keyboard, and I’m talking to you — instantly, no scheduling required. Everyone was in the room, so you got the accidental communication you’d otherwise miss from being co-located. It was immediate, low-friction, and always-on.

That’s what made it work: the tooling matched the culture. Gamers are already conditioned to communicate in real-time through voice chat. They understand push-to-talk etiquette. They’re comfortable with ambient presence — knowing someone is “there” even if you’re not actively talking to them. It felt natural because it aligned with how that particular group of people already operated.

But here’s the thing: most remote workers don’t use tools this way. They schedule Zoom meetings. They send Slack messages that require context-switching to read and respond. They create formal communication patterns where informal ones would serve better. And if I’m being brutally honest, the people who struggle most with remote work efficiency are often the same people who’d struggle with office efficiency — the tooling just makes it easier to hide, and thereby I’m less able to help them as their manager.

Remove the Red Tape, Create a Bias for Action

Whether you’re co-located or distributed, the real enemy is bureaucracy. Every form, every approval process, every “please submit a ticket” response to a simple question — these are friction points that accumulate into organisational drag.

The economist Milton Friedman noted that “one of the great mistakes is to judge policies and programs by their intentions rather than their results.” Every piece of red tape was created with good intentions. The change review board exists because someone once deployed bad code. The three-layer approval process exists because someone once made an expensive mistake. But the cumulative cost of all this well-intentioned process often exceeds the cost of the mistakes it was designed to prevent.

At Agoda, I try to cultivate a bias for action. This sounds like corporate buzzword soup until you see it in practice. It means that when someone identifies a problem, the default response is to fix it, not to schedule a meeting about fixing it, or create a JIRA ticket and discuss with your PO at a late date. It means empowering people to make decisions at the lowest possible level. It means treating “asking for forgiveness rather than permission” as a feature, not a bug.

This is much easier when people are co-located. When you can tap someone on the shoulder and say “I’m going to do X unless you see a problem,” you get immediate feedback. The cycle time between idea and action shrinks dramatically. And managers can practice what Toyota calls “gemba” — “go see” — walking the floor, observing actual work, and understanding problems firsthand rather than through layers of filtered reports.

The famous Toyota chairman Fujio Cho summarised the gemba practice in three phrases: “Go see, ask why, show respect.” In a co-located environment, this is natural. In a remote environment, it requires deliberate effort that few managers actually put in.

My old boss Pete was a perfect example of gemba in action, even though he’d never heard the term. He was intensely curious and used to walk around the floor constantly between meeting rooms. Occasionally, something on an engineer’s screen would catch his eye, and he’d immediately sit down and say, “What is that!” And they’d start talking about the code. Usually he’d pick up antipatterns or bad practice this way — things that would never surface in a status report or a sprint review, but were obvious if you just looked at what people were actually building.

Pete didn’t do this because he’d read a book about lean management. He did it because of his personality type. But it was a perfect example of why colocation helps tech leadership. You can’t catch a problematic architectural decision in a Slack message. You can’t spot that someone’s about to introduce a maintenance nightmare from a Jira ticket. You need to see the work.

Personally, I know enough Thai to get context about conversations between my engineers at the office. So when they start talking about Postgres replication in Thai, I can overhear and know I need to step in. That ambient awareness — understanding what’s happening without requiring formal updates — is almost impossible to replicate remotely. It’s the difference between being informed and being present.

When You Must Have Multiple Locations

Reality doesn’t always cooperate with our preferences. Sometimes you need teams in multiple locations — for timezone coverage, for talent access, for business requirements. When that happens, plan deliberately.

The worst pattern is scattering teams randomly across locations. If your frontend engineers are in London, your backend engineers in Singapore, and your product managers in San Francisco, you’ve created a collaboration nightmare. Every decision requires asynchronous communication across multiple timezone gaps. Context gets lost. Misunderstandings fester. Simple problems become complex problems because nobody can get in a room together and sort it out.

The better pattern is to keep teams that need regular communication in the same location. If a team needs to work closely together, put them together — physically. If you have multiple offices, think carefully about which functions belong where, and optimise for minimising cross-location dependencies.

The Bottom Line

As the architect Christopher Alexander wrote, “When you build a thing you cannot merely build that thing in isolation, but must repair the world around it, and within it, so that the larger world at that one place becomes more coherent.” Organisational structure works the same way. Every decision you make about hierarchy, location, and process ripples outward, shaping the culture and effectiveness of everything built on top.

Keep it flat until you genuinely can’t. Keep people together until you genuinely must separate them. Remove friction wherever you find it. Create an environment where the default behaviour is action, not permission-seeking.

And if you absolutely must work remotely, for the love of all that is holy, stop scheduling meetings and start using always-on communication. Get in a virtual room together. Make presence the default, not the exception.

Your future org chart will thank you. Your engineers will definitely thank you. And maybe — just maybe — you’ll build something that ships while your competitors are still filling out their change request forms.

Now, if you’ll excuse me, I need to go approve some laptop pruchases. Apparently we’ve added a new layer of hierarchy and I’m suddenly the bottleneck. The irony isn’t lost on me.