⚡️ TL;DR
- Align your team’s (or company’s) technical goals with simple frameworks like the C4 model.
- Engineers and architects prototype ideas outside their “master” codebase; the same can be applied to prototyping designs.
- The C4 model provides a systematic approach to layering and modeling systems, convenient for collaboration and onboarding new stakeholders.
- Teams can rely on the C4 model in their design documents and code reviews.
Introduction
Engineers are often skeptical about adopting a new piece of technology or practice into their teams, let alone their entire company. One reason is that they have limited bandwidth to review and discuss all the options available. Most of their time is spent delivering value to their teams (e.g., design, engineering discussions, and implementation). Another reason is that they may not find strong enough signals that motivate them to “buy-in” to a new proposal and move things forward. Strong signals for a new technology could include ease of use, maturity, cost-effectiveness, or solving a developer pain point. Benefits of using the C4 model could include qualitative metrics such as developer productivity and team collaboration. More on that shortly.
In this post, we’ll share tips on how to get buy-in for the C4 model within your team.
How to get buy-in
Say you’ve read about the C4 model and sketched out a few systems using the approach. You loved the layered structure and found them useful to work with. But will your team feel the same way?
Maybe. It depends on how you propose it. Presenting it as a modern or trendy practice won’t sell. Instead, you’ll need to emphasise the value it delivers in terms of metrics your team or company cares about. For example, if one of your company’s goals is to improve ways of working as an organisation, you could frame the C4 model as a tool that supports architects and engineers in achieving that.
Examples of these metrics are:
- Developer Experience (DevX): How does this make the development team work easier?
- Developer Velocity: How does this accelerate development work?
- Culture: How does this empower our engineering team?
Thinking about these metrics will push you to think at a higher level and identify the strongest reasons why your team should buy into a proposal (in this case, the C4 model). Healthy teams tend to empower engineers to propose new ideas based on what they’ve worked with and where they see opportunities for improvement. These could be technology upgrades (e.g., Python), new ceremonies (e.g., backlog refinement sessions), or process improvements (e.g., documenting architecture). There are an infinite amount of ideas to propose but only a finite amount to buy-in. The goal of this post is to make the “C4 model proposal” an idea that is easy to buy-into.
Let’s start with the first one.
1. Emphasise the simple notation
One of the strongest selling points of the C4 model is its low barrier to entry. It doesn’t introduce a complex syntax or framework for designing architectures. Instead, it structures them by clearly distinguishing between “systems” (Context), “applications or data stores” (Container), “collections of interfaces” (Component), and “source code” (Code).
The key to proposing this framework is not overloading engineers with new terminology but showing small, clear examples of what the diagrams look like. Engineers generally prefer to build on their existing knowledge rather than learn yet-another-language-or-tool. The proposal isn’t about learning a new language, it’s about grounding architecture conversations in a consistent and clear way.
Emphasising the power of simple notation to relevant stakeholders is critical for getting buy-in. If they can see how easy it is to use, they’ll be more inclined to adopt it. Also, showing examples using C4 is perfect.
2. Measure impact on Developer Experience (DevX)
Engineering managers love to see this highlighted in proposals. If there’s a tool or process that improves the developer experience, they’re often the first to embrace it; provided you clearly demonstrate how it delivers that improvement.
This could be in the form of documentation, where engineers have a centralised point of reference for diagrams using the C4 model. It could also be in stakeholder management, where engineers can engage with product designers and managers through a shared C4 diagram. Or it could be in knowledge sharing, where senior engineers distill their expertise by modeling systems and junior engineers can follow along. Also, onboarding new joiners to legacy systems using the C4 model is a great way to show how users interact with and how data flows through the system. IcePanel provides a standardised approach for this using Flows.
If you’re the one to initiate improvements to the developer experience, your team members will notice and appreciate it.
3. Avoid mandating it for every diagram
Engineers often take time to mull over new proposals. Approaching it in the sense of – let’s use it for specific use cases without disrupting our current workflow – is a great start. If you mandate the C4 model for every diagram, including prototypes, engineers will feel discouraged at this “pressure”. Instead, approach it the same way we prototype things.
If we’re asked to scope a feature, we can first prototype by writing some code (could be pseudocode!) and put it in a disposable place (e.g., feature branch, google doc). This way of working allows engineers and architects to move fast when thinking about some technical decisions before committing to a specific project. The same goes for diagramming.
Let’s say we’re asked to think about the architecture for a new service that requires access to some third-party services and a datastore. Instead of prototyping on the “main architecture diagram”, I can quickly draw out some ideas on a white board (e.g., Excalidraw), and once all the details have been fleshed out, we can decide on the actual architectural changes and draw that in our “main diagram” using the C4 model in a tool like IcePanel. Given the C4 model is a simple syntax and easy to follow, translating it shouldn’t be a problem!
What’s great about this proposal is making a distinction between a “production” diagram and “staging/development” diagram. The C4 model can be used to maintain the architecture of production-grade systems, where different stakeholders can review it, while simple whiteboard tools (e.g., Excalidraw) can be used as a sandbox for engineers. Even better, IcePanel has a Drafts feature where users can maintain multiple versions of the diagram (like a feature branch) without changing the main version.
4. Show how it improves engineering culture
Building a strong engineering culture is extremely important. It is the main driver for having low attrition/turnover, and it empowers engineers to perform at their best. Proposing the C4 model as a way of using it to deliver new projects (e.g., building a new service), building strong team inclusion (e.g., product designers), and stakeholder management is a plus.
Another aspect that contributes to a strong engineering culture is encouraging ownership and accountability. Adopting the C4 model empowers teams to own and communicate their architectural decisions and become experts in their domain. For example, platform teams can use C4 diagrams to explain their cloud infrastructure, CI/CD, and tooling to downstream teams. Since the platform team owns their C4 diagrams, they’re empowered to drive changes to their designs and architecture and communicate them with full transparency. Having ownership and accountability improves the overall culture, and the C4 model can be both a tool and practice that exercises these traits.
Conclusion
We’ve covered ways for getting “buy-in” from your team for the C4 model. It’s important to link the proposed framework to a qualitative metric that your team or company cares about (e.g., developer productivity) to highlight its impact. The C4 model serves as an approach that promotes better documentation, collaboration, and ways of working. Introducing it to your team is a valuable addition to their toolkit.
Here are four ways to get buy-in from your team:
- Emphasise the Simple Notation
- Measure Impact on Developer Experience
- Avoid Mandating It for Every Diagram
- Show How It Improves Engineering Culture
