Code Isn’t Slowing Your Project Down, Communication Is

You get an idea and a moment later, the code’s already in your head. And before you know it – bam! – it’s on GitHub.

But hey, it was your side project, not your day job. Because once you step into a “real job,” things get complicated by the minute.

At first, you might think, Oh, we refine the task, put it in the next sprint, implement it, do a PR, testing… and it’ll be done in about two weeks. No bam! this time, but it’s still fast… comparatively.

That speed reminds you of working alone (or with a small, familiar team) where ideas move almost as quickly as they appear. Code follows a thought, and suddenly it’s in the repo.

But once an idea crosses teams or touches parts you don’t own, time stretches. Days turn into weeks, weeks into months – not because the code is harder, but because communication is: unfamiliar code, processes, priorities, even languages.

Who you work with is EVERYTHING

Now I’m going to challenge you even more: how long would it take to implement a system‑wide feature? I’m not talking about some fancy, super‑complex, revolutionary refactor, just something that stretches across many components that aren’t yours. You don’t know them. You don’t even know the maintainers.

And let’s be honest, you don’t want to talk – you’re a programmer, after all, right? You think, Well, a couple of sprints… maybe a few months… if you’re feeling optimistic.

When you’re working alone, the only communication is between your neurons, and that’s pretty fast, isn’t it?

The same goes when you collaborate with teammates you know well. You understand each other, don’t need to repeat much, and many things are already covered by your working agreements (whether written down or just implicit) so you barely have to mention them.

But step into a new or larger team, and suddenly communication is full of obstacles. You don’t know the people, you don’t know how they work, they might speak another language – or worse, code in another language! Cooperation suddenly feels almost impossible.

It will take months, because you need to talk to the others, discuss multiple opinions, understand different perspectives and reach number of compromises. Implementation is easy-peasy. 

The less we know about the project, the more we try to handle it ourselves

Recently we’ve been implementing a very custom solution for a big client. We generally don’t provide custom solutions, but sometimes customers, especially big ones, manage to convince us somehow. 

For most of our integrations, we rely on two key components:

1. Component A handles queuing, throttling, and light request processing. 
2. Component B handles more substantial model transformations and aligns our data with the external provider’s protocol.

In this case, no major model manipulation was required. However, we couldn’t simply send data from A to the provider. We were aware of the configuration possibilities in Component A.

So the question arose: Should we stick to our usual A+B setup, following the well‑worn path? Or should we step outside our comfort zone, reconfigure Component A, and see if we can eliminate the need for Component B altogether?

If both were ours, the answer would be easy. But we didn’t know much about A – we didn’t even know the maintainers.

The temptation to stick with the usual path grew. Then someone had the clever idea to explore Component A using Claude Code. Now we know it, we’re AI-powered! We can do anything, even talk to strangers! Bring them on! we thought. This time, we did it the right way.

Jokes aside, Components A and B (and their ownership by different teams) are a classic example of Conway’s Law: the tendency to copy organizational structure into system design. The harder it is for two people or teams to collaborate, the more likely they are to build separate, siloed parts of the system (have you heard about silos?).

Still doubt that poor communication shapes architecture? Reread the first paragraph – you probably didn’t even notice it the first time. Or check out the insightful presentation The Only Unbreakable Law.

Still unconvinced? Here’s a knockout argument: think back to the last time you tried to sort something out at a government office. How many doors did you have to knock on? How many forms did you have to fill out? How many organizational units did you have to visit? And all for just one issue…

In a well-designed company, this doesn’t always need to be an issue. Why would a corporate lawyer need to talk to a DevOps engineer? Or an accountant to a UI tester?

But when it comes to software, the boundaries aren’t always so clear. In our example, the less we know about the people maintaining a given component, the more likely we are to misuse it and try to solve the problem on our own. That often leads first to overcomplicated architecture, and then to technical and organizational silos.

This is how my team fought the Conway’s Law

You’re probably thinking there must be a way around this, and you’re right. There’s an approach called the Inverse Conway Maneuver: if the organization shapes the architecture, why not design teams to build the system we want?

Sounds clever, but it’s not easy, especially in established companies.

Management must be tech-savvy and understand the right architecture, and engineers need to grasp the target design and reasoning, since changes often involve reorganizing the codebase.

Organizational changes don’t have to impact the whole company and they can be applied on a smaller scale. Here’s a simple example from my experience.

We used to work on a product end-to-end and our area was defined by the product, not the architecture. Sounds nice, right?

However, we were backend developers, and since the product included front-end applications, we also had to develop and maintain the user-facing parts. We were never front-end experts, so we struggled a lot. We knew the product and its business specifics, but our tech gaps were a constant drag.

Eventually, we decided to hand it over to front-end experts. What a relief! Product Managers got what they wanted on time, backend developers could focus on our strengths, and frontend developers had fun fixing our mistakes.

We thought everything was sorted, until later, when we all got together in one room, despite being geographically distributed, to talk about the product. During that session, we uncovered a few weird issues we hadn’t noticed before.

The key was sharing knowledge about how each part worked and how they worked together, which revealed bugs invisible when working in isolation. It was eye-opening, and I can’t overlook another benefit: building team spirit through shared activities and discoveries, which greatly improved our future collaboration.

Sit down and listen to other teams

So here’s the thing: Conway’s Law isn’t going away. No matter how hard you try, no matter how many architecture diagrams you draw, your system will always reflect how your teams communicate… or don’t.

But before you panic, remember the government office analogy: you’re knocking on doors because that’s how the organization is structured, not because doors are inherently evil. The same applies here. Yes, your architecture will mirror organizational boundaries, but it’s on you whether you knock or find a workaround.

Every time you sit in a room with people from another team and actually listen, every time you take the time to understand how the system really works, you’re actively shaping the architecture – whether you realize it or not.