The Engineering Skill Behind Better System Design
The engineers who move into leadership roles aren’t necessarily the ones who code fastest. They’re the ones who see systems.
What separates them? Usually, it’s perspective. Most engineers think about their immediate task: build this feature, solve this problem, ship this code. The engineers who advance think differently. They ask: how does this fit into everything else? What breaks if I change this? Where does this data flow after I’m done with it?
This is data modeling. But not the database design kind you might be thinking of. It’s a mindset shift that changes what you can contribute and how you influence decisions. Understanding how data relates across your system is part of the broader capability to see the full context in which you operate.
The Gap Between Storing Data and Understanding It
Most engineers approach data with a simple question: What info do I need to store?
It’s practical. It gets you moving. But it’s also how you end up with systems that work today and break tomorrow. It’s also how you end up discovering problems in production that should have been obvious during design, or end up with duplicate data living in three different places because nobody modeled the relationships.
Research from McKinsey and Stripe shows that engineering teams spend between 25 and 42 percent of their time on activities caused by poor system design: rework, workarounds, debugging legacy code, and managing fragile dependencies. That time compounds over years.
Here is how not understanding data flows can impact a team: Engineer A builds a feature and stores user data in a new table. Engineer B builds a feature six months later and also needs user data, so they add on and store some of it in their own service. Nobody asked: who owns the truth here? What happens when it changes in one place but not the other?
Without understanding data relationships, you can’t spot these problems. You just build what was asked and move to the next thing.
But engineers who think about relationships see it differently. They notice the overlap before it compounds. They ask questions that prevent rework. And crucially, they get visibility into how their work affects other parts of the system.
This is the foundation for leadership impact. You can’t guide decisions if you don’t understand the consequences.
Modeling Is Asking the Right Questions First
Data modeling isn’t about creating diagrams or designing databases. It’s about asking questions before you code.
The shift is subtle but powerful. Instead of asking “what table do I need?”, you ask:
- Who owns this data? Not who created it—who is responsible for its accuracy and currency? If it lives in multiple places, whose version is the source of truth?
- What other systems depend on this? What breaks if I change it? What reads it? How often?
- Where does this data flow after I’m done with it? Is it used once or a hundred times? By whom?
- What validates it? Should validation happen here, at a boundary, or somewhere else? If multiple systems validate the same thing, how do we keep it consistent?
These questions aren’t theoretical. They change what you build and how you build it. They change what you propose and how you defend it.
When you ask these questions, you start communicating differently, too. Instead of saying “we need to store this field,” you say “we need to clarify who owns this relationship because right now product can’t do X without breaking Y.” That’s a conversation with your team and product about tradeoffs, not a technical implementation detail.
When You See Relationships, You Spot Problems Earlier
Here’s what changes when you model data relationships:
You stop waiting for code review to discover design problems. You catch them during design. You ask, “wait, is this relationship the same as feature X?” instead of finding out six months later when someone notices the duplicate logic.
You save rework. A lot of it. The engineer who thinks about relationships upfront doesn’t build something that works at 100 requests per second but breaks at 10,000. They anticipate it.
You communicate across teams more clearly. The product wants a simple feature. You say: " We can build this, but it creates this data relationship, which means we will run into issues supporting that use case. Now, the product understands the actual tradeoff, not just 'the engineer said no.”
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
Small decisions about data relationships cascade.
Architecture decisions shape what becomes possible or impossible in your system. A shared database between services compromises isolation. Duplicate data in two places means you’re managing multiple sources of truth. These constraints either get managed intentionally upfront or they compound into expensive rework later.
Your code reviews become more rigorous because you’re checking design assumptions, not just syntax. You ask better questions. You catch inconsistencies.
Over time, this builds your reputation. You’re the person who spots problems before they become expensive. You’re the person who understands how things fit together. These are the qualities that move you from an individual contributor to someone people listen to.
Build a Mental Map Before You Code
You don’t need to become a DBA to build data flows. You need to start with one habit: before you code, map relationships.
On paper, in a document, or just in your head: what data comes in? What stays? What goes out? What does the other code depend on? What validates it?
Ten minutes of this thinking saves hours of debugging and rework later.
Then bring this habit into other work:
- In code reviews: Ask about relationships. “Where does this data flow after this function? What systems depend on this shape?”
- In design discussions: Ask about ownership. “Who is the source of truth for this? What happens if product changes this requirement?”
- In retrospectives: Notice patterns. “When did we discover these two systems had the same data? Could we have seen it earlier?”
You don’t have to architect every data decision. It’s more about building the habit of asking, “how does this relate to everything else?” It takes practice, but the payoff is real.
The engineers who grow into leadership see systems. They understand how pieces fit together and what happens when one piece changes. Data modeling is the technical lens for that thinking.
It’s not a skill you master once. It’s a perspective you develop over time. And it changes what you can contribute, how you’re perceived, and where you can take your career.
What part of your system would you map differently if you started thinking about relationships now? Reply to this email—I read and respond to every on