What we have done is to make it dramatically easier to navigate the corporate ladder

Conways Law

Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the organization’s
communication structure

— Melvin E. Conway

I’ve blogged previously on the topic of Technical Debt and ways to prevent and or overcome it. I’ve used my brilliant PowerPoint skills for pictures like this:

But what I forgot is one of the most important drivers of them all… communication! And how organisations either facilitate that or (unknowingly) hinder that.

Study by The Harvard Business School

In a study conducted by The Harvard Business School various codebases where examined to confirm the hypothesis. The codebases had similar functional purposes. They compared results from loosely-coupled open source teams with tightly-knit teams. The study revealed that tightly-coupled product teams tended to produce tightly-coupled, monolithic software. And, open source projects leaned towards adopting more modular and decomposed codebases.

Reorganisations

There is a growing trend around company reorganisations with Agile and Scrum. Many organisations aim towards a similar structure made popular by the Spotify model. They are converting into Squads, supported by Chapters, organised in Tribes and Guilds. These autonomous teams have end-to-end responsibility for what they build and deliver. This reorganisation is a great example of managing this connection between organisational structure and the software the teams produce.

So, if organisations design systems that mirror their own communication structure. What does that look like in Salesforce? What kind of teams do we see? What kind of Technical Debt does that create or solve?

Salesforce teams

In Salesforce implementations we organise for the functional domains and their supporting Clouds. So: Marketing, Commerce, Sales & Service. These teams can be very autonomous but only up to a certain point they all need to deploy to the same Salesforce Org. There are often discussions on who builds the interfaces. Do these integration developers sit in the Salesforce teams or do they have their own team?

Impact on Technical Debt

I have talked often on Technical debt and I like to define it as “the accumulated consequences of taking shortcuts during development to meet deadlines or other constraints“. When an organisation’s setup and structure promotes fragmented communication and isolated decision-making, it can lead to technical debt in several ways:

1. Inconsistent Design: If different teams work in silos without communication and collaboration, the overall architecture may lack coherence and consistency. Inconsistent design and architectural choices may accumulate over time, making Salesforce harder to maintain and deliver new functionality.
2. Communication Gaps: When teams work independently, they might not be aware of changes or updates made by other teams, leading to communication gaps. This lack of awareness can result in conflicts, redundant efforts, and integration challenges, further exacerbating technical debt.
3. Knowledge Silos: Conway’s Law also plays a role in knowledge sharing. Isolated teams may develop specialized knowledge about specific aspects of Salesforce, creating knowledge silos. When team members leave or move to other projects, this specialized knowledge may be lost, hindering the understanding and maintenance of the software.
4. Delayed Integration: Tightly-coupled designs often result in fragile point to point integrations. These require constant and extensive testing efforts. As a result, changes might lead to integration problems, regression bugs, and time-consuming rework.

Conclusion

By understanding the unintended effects of Conway’s Law, organising and facilitating teams to have a single purpose and responsibility, but still collaborate and communicate effectively: organisations can have a great Salesforce implementation that fit their needs.