Published · 8 min read
You probably saw many cliché stuff about risking everything. Not risking is the biggest risk and all. While there is a truth to that, risk needs to be an appetite. Remember what happened with the 2008 global financial crisis. Some took risks. Miscalculated. Misrepresented. Misaligned. So forth. Where did we end up? Entire markets froze. Liquidity vanished overnight. Companies collapsed in a chain reaction because nobody understood the true exposure they were carrying. Everyone assumed someone else was watching the details. No one was.
Similarly, what does that mean in engineering? Cowboy coding. No backup procedures. No code reviews. No testing. No handover. No documentation. No blue or green deployments. No staging environment. Shipping changes straight into production. Friday master merges. No feature flags. No monitoring until the outage already happens. Relying on tribal knowledge instead of written truth. Hoping for the best while silently carrying risk in every corner of the system.
This is how engineering fails. It’s not through a single mistake but through a slow buildup of unspoken risk that everyone ignores while they focus on what they are doing. Risk is always building up somewhere. It hides in someone’s silence, in someone’s assumptions, in the things people forget to mention, in the places where a team says “we will fix it later” but later never arrives. It is never a flashy problem. It is always the quiet one underneath. This is why risk comes first. We need to look at risk before we look at speed or ideas or features.
Risks follows you even you keep moving
What is risk though? It is the devil in the details. It is something that hides. It is in all the things that feel boring or feel routine. It feels like something you can ignore for another day, and then another one, and then one more after that.
Unfortunately, most teams only recognise risk when something finally breaks. A production outage. A missed deadline. An architectural decision that was made without the right people in the room. A conflict between two teams that suddenly becomes a political problem. Nonetheless, the real damage was already happening long before by the time these things surfaced. The root cause was not the failure. The root cause was the quiet accumulation of ignored signals.
This is something I remind myself often. I like being bold. But being bold without understanding the risk profile is just recklessness and silliness. I used to think experienced people were being overly cautious. I assumed the priority was speed, or output, or coming up with clever ideas. The more responsibility I had, the more I realised that what really matters is the risk profile behind the work. If the foundation is shaky, the project becomes shaky. If communication is unclear, delivery becomes unpredictable. If assumptions stay unspoken, everything built on them becomes fragile.
It’s funny that I now realize the risk is present in every decision a team makes. The question is whether that risk is visible or invisible. Visible risk can be managed. Invisible risk grows in the dark until it escapes at 4:58 AM. That is why the most dangerous risks in engineering are not technical. They are the silent ones created by habits, assumptions, and shortcuts that feel harmless in the moment. What kind of risks should we think of?
In time, I learned here and there a bit. We are engineers, not developers and that distinction matters. Technically, I’m a manager but still. We need to address the risk. Although there are so many risks for a software project, team or organization, a few generally stood for me. They look ordinary. They look harmless. They look like everyday behaviour. Nevertheless, that is what makes them dangerous. Here are the ones that matter most.
People think they are working toward the same goal, but they are not. One group is optimising for speed. Another is optimising for correctness. One is writing a library. Others do not use it. Someone else is solving a completely different problem. Everyone feels productive, yet the team moves in different directions.
Information moves slowly, or not at all. The right people hear the right thing too late. Updates only reach half the team. Decisions happen in private conversations and never make it into the shared space. Communication risk creates uncertainty, and uncertainty is one of the fastest ways to create pressure from above.
You believe success looks a certain way. Your manager believes something else. Stakeholders believe something entirely different. Nobody says it out loud because everyone assumes they understand each other. This risk grows quietly until the moment of delivery, when everyone realises they were imagining different outcomes.
The scope is bigger than expected. Dependencies multiply. Unknowns become real. Work takes more time than planned, yet nobody reacts early enough. Execution risk is not about failure. It is about pretending things are on track when they are not. By the time people acknowledge reality, the timeline has already broken.
There are unresolved tensions between people. Someone feels unheard. Someone feels pressured. Someone feels disrespected. People stop asking questions. They stop surfacing concerns. They stop collaborating with full energy. Interpersonal risk drains the team slowly until motivation and trust disappear.
Leaders cannot see what is happening. They do not know the state of the work. They do not know the truth about progress. They do not know what worries the team has. When visibility is low, leaders assume risk is high. And when leaders feel risk is high, they begin to intervene in ways that slow the team down even more.
The organisation is set up in a way that guarantees friction. Ownership is unclear. Responsibilities shift day and night. Nobody decides on anything. When they do, it’s not written anywhere. Teams are connected through fragile dependencies. Structural risk is not created by individuals. It is created by the environment they work in.
This happens when small delays accumulate. A week slips here. A decision waits there. A dependency drags on. Nothing looks serious on its own, but the accumulation of those stalls the progress. Once momentum disappears, it takes enormous effort to recover it.
Risk feels abstract until you break it into something you can measure with your eyes and your instincts. Every project carries risk. Every decision carries risk. Every conversation carries risk. The question is how to see it before it becomes a problem. Here is the formula I use.
Risk equals ambiguity multiplied by impact, divided by visibility. Voila!
Software Development Risk Formula
It looks simple, but it explains almost everything that goes wrong in engineering work.
This is everything that is unclear. Unknown requirements, unclear ownership, missing context, hidden assumptions, confused priorities, or the silent moments where people think they agree but they do not. When ambiguity increases, risk increases with it.
This is the weight of what can go wrong. A tiny feature with no users has low impact. A change that touches billing, authentication, or production infrastructure has a high impact. Even a small misalignment can become serious if the impact is large enough.
This is how clearly everyone sees what is happening. High visibility lowers risk because people can react early. Low visibility raises risk because surprises grow in the dark. Visibility includes updates, written notes, honest conversations, early signals, and shared understanding.
So the formula becomes simple.
You can use this formula on every task, every plan, and every project. You can use it to decide when to raise a concern. You can use it to see when a team is drifting off track. You can use it to understand why a manager is anxious. You can use it to understand why leadership pushes for more updates even when the work is going well.
Risk is always present, even when people do not see it. Think about something simple. Why do you buy a child seat for a car? You want to be safe. You want to protect someone you care about. But for a long time people drove without child seats. The risk was always there. It did not appear the day the regulation arrived. People just did not recognise it until the cost became impossible to ignore.
Work is the same. Projects do not fail suddenly. Teams do not fall apart in one moment. The risks were already there. Unclear expectations. Quiet assumptions. Missing information. Shaky foundations. If you do not see them early, you only notice them when something breaks.
This is why risk comes first. When you understand the risk profile of your work, you protect the people around you. You make better choices. You keep the system safe. You prevent the slow, silent problems from growing. And you build trust without needing to talk about trust at all.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。