Technical Decision-Making for Mid-Level Engineers

The ultimate end game in technical decision making is making decisions that are best for the business. You may have spent a good part of your career just focused on technical solutions. As you become more senior in your career and take on leadership roles, you’ll begin to see technical decisions through the eyes of business outcomes. I’m not just talking about “this product has to go live on x date”, it’s way more complex than that. You may have a delivery schedule, dependent teams, politics, a lack of cooperation from other teams, a lack of buy in from people, leaders pushing for competing business outcomes with bonuses attached, maybe also a lack of trust between departments of hundreds of people. That’s just the short term hurdles you’ll need to overcome. The longer term perspective could include technical debt, defects that take time away from future feature delivery, a system that doesn’t scale well with customer growth, a product that doesn’t scale as anticipated and now you’re stuck with additional technical complexity or a tech stack that turns out being the flavor of the month that ends up causing major problems in the future. Sometimes a senior engineering leader will make a call that you don’t understand. It may not make sense from a technical perspective. Sometimes though, there are constraints and decisions that need to be considered with the bigger picture in mind. Both technical and business outcomes and constraints need to be considered, and the business side might not immediately obvious or visible to your team. When these decisions are made around you, use them as an opportunity to learn. Ask questions and seek to understand. The more you can include a business perspective in your technical decision making, it's likely that your career will take an upward trajectory!

Most engineers spend years trying to get a seat at the table. Then they finally get it and make the same mistake immediately. They show up and act like builders in a room full of decision makers. Here's what that looks like in practice and how to fix it: Step 1. Stop bringing answers. Start bringing perspectives. - Builders come to meetings with solutions already decided - Decision makers come with a point of view and an open question - "Here's what I'd recommend and here's what I'm still uncertain about" is more powerful than "here's the answer" - Certainty closes conversations. Perspective opens them Step 2. Read the room before you read the data - Engineers default to leading with numbers and technical evidence - At the decision-making level, context and timing matter as much as accuracy - Before speaking, ask yourself who in the room has skin in this decision - The most technically correct answer delivered at the wrong moment loses every time Step 3. Stop defending your work. Start advancing the mission. - The instinct to protect your model, your code, your approach is natural - At the table it becomes a liability - When your idea gets challenged, your job is not to win the argument - Your job is to find the best path forward, even if it isn't yours Step 4. Learn to sit with ambiguity out loud - Builders are trained to solve before they speak - Decision makers are expected to think in public - Saying "I don't have a clear answer yet, but here's how I'd approach finding one" builds more trust than silence - The table rewards engineers who can reason visibly, not just deliver quietly Step 5. Shift your metric from output to influence - Stop measuring your contribution by what you shipped - Start measuring it by what changed because you were in the room - Did the direction shift? Did the team avoid a costly mistake? Did someone make a better decision because of your input? - That is the scorecard that gets you invited back Getting a seat at the table is hard. Keeping it requires a completely different operating system. If you're navigating this transition right now, this is exactly the work I do with engineers. Follow me and let's build that together.

The hardest technical decision I made at Amazon wasn't about technology. During a project, an engineering team wanted to rebuild our entire checkout system. I remember, the enthusiast team; "It's legacy code," one of my best engineering colleague said. "We can do it in 3 months." But here's what my Amazon experience taught me to ask: I asked the below Questions: 1/ Why now? 2/ What's the actual pain? 3/ What's the hidden cost? After diving deep (Amazon leadership principle in action), we discovered: - 80% of issues came from 20% of the code - Complete rebuild = 6 months minimum - Migration risks > Current pain What we did instead: 1/ Isolated the problematic components 2/ Created clear interfaces 3/ Rebuilt critical parts first Result: - 70% improvement in performance - Only 6 weeks of work - Zero customer impact The Framework I Used: 1. Pain Assessment - Current impact - Future risks - Resource cost 2. Solution Mapping - Quick wins - Medium changes - Complete rebuilds 3. Hidden Cost Analysis - Migration complexity - Team bandwidth - Customer impact Key Learning: Technical decisions aren't about the newest technology. They're about making the right trade-offs. Early PMs: What technical decisions are you struggling with? Let's solve them together 👇

I see L3/L4 engineers doing "senior-level work" who don't get promoted follow a pattern. They confuse volume with seniority. Here's the difference: Two engineers. Same team. Q2 performance review. Engineer A: Shipped 5 features. All on time. High quality. No bugs. Engineer B: Shipped 3 features. Killed 2 before they were built. Engineer B got promoted. Engineer A didn't. Why? Engineer A executed what was asked. Engineer B changed what was worth executing. The feature Engineer B killed: A dashboard, the PM requested. Before writing code, they asked: "What decision will this enable?" PM couldn't answer clearly. Turned out the data already existed in another tool. Building a new dashboard would duplicate effort and fragment the system. Engineer B proposed enhancing the existing tool instead. Saved 3 weeks of engineering time. Prevented future maintenance debt. That's senior thinking. Mid-level engineers execute faster. Senior engineers decide better. The pattern: You're measuring yourself by output: features shipped, tickets closed, velocity. Your manager is measuring you by judgment: What did you prevent? What did you simplify? What did you question? Promotions don't go to engineers who do more work. They go to engineers who eliminate unnecessary work. This week: Pick one item in your backlog. Ask your manager: "What business outcome does this enable?" If they can't answer clearly, you found work that shouldn't exist. Challenge it. That's the shift from mid-level to senior. P.S. If your manager gets defensive when you question requirements, you're working for the wrong manager. Senior engineers need leaders who reward judgment, not just compliance.

Last month in my team, a senior engineer said "yes" to an impossible deadline. Three days later, it was delivered. The same engineer said "no" to another request immediately after. Both times, they were right. This is called high-velocity decision-making. You might wonder what data they had that you didn't. But if you wait for 100% of the data, you aren't making a decision. You are just processing information. This superpower works when you have data gaps. It is experience. It is technical depth. It is business knowledge. And in one word, we call it gut feeling. Now you might ask, how do you build it? Here is what you can do. 𝟭. 𝗕𝘂𝗶𝗹𝗱 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 (𝘁𝗵𝗲 𝗵𝗮𝗿𝗱 𝘄𝗮𝘆) You need to know the risk of acting versus the risk of waiting. To do this, you must understand where your system falls in the customer's life. There are no textbooks for this. You learn it by talking to people. You learn it by listening. You learn it by sitting in project meetings where you have no role other than to absorb. Most engineers make a fatal mistake here. They keep coding during the meeting. They think they are being "productive" because they are writing code. But productivity isn't just output. By tuning out, they miss the context. No one will schedule a 30-minute meeting just to teach you business logic. You have to build that understanding yourself. This is where the gap widens between an engineer who thrives in decision-making and one who just thrives in coding. 𝟮. 𝗥𝘂𝗻 𝗺𝗲𝗻𝘁𝗮𝗹 𝘀𝗶𝗺𝘂𝗹𝗮𝘁𝗶𝗼𝗻𝘀 You need to know your architecture well enough to predict breaking points. Do a dry run in your head. Ask how upstream systems will use this and how downstream systems will react. You won't have all the answers. Start with an assumption to get moving, and correct it over time. 𝟯. 𝗥𝗲𝘀𝗶𝘀𝘁 𝘁𝗵𝗲 𝗽𝗿𝗲𝘀𝘀𝘂𝗿𝗲 Never say "yes" just because a manager or stakeholder wants to hear it. They might support you in the moment, but if you haven't given it deep thought, you aren't doing the job at a senior level. If you need to say "no," do not just refuse. People have ego. Quickly gather evidence that supports your hypothesis. Go to the stakeholders with data. Tell them directly why it is the wrong decision so they can make an informed choice based on facts, not just your opinion. 𝟰. 𝗘𝘅𝘁𝗿𝗲𝗺𝗲 𝗼𝘄𝗻𝗲𝗿𝘀𝗵𝗶𝗽 Once the decision is made, you must be on top of it. Do not assume someone else on the team has the details. They might, but you cannot rely on it. You must own the execution. That is the only way to navigate the situation without looking like a person who has no clue about their own domain. Now you might be wondering, isn't it very hard? Yes, high-velocity decision-making is very hard. And that is the reason why there are very few people who are good at it.

Here is the hardest truth for many developers to accept: code is not an asset, but it is a liability. Every single line of code you write has to be read, tested, debugged, maintained, and eventually rewritten. The more you write, the heavier the system gets. The shift from a Mid-level to a Senior engineer isn't only about mastering a new framework. But it's a complete mindset shift. It’s moving from asking "how do I build this?" to asking "should we even build this?" 😉 What does decision quality look like in practice? 1) Using existing solutions instead of ego-coding. A junior will spend 5 days writing a custom authentication module to prove they can. A senior integrates an established provider in 3 hours because they know that maintaining custom security edge cases will become a nightmare next year. 2) Deleting features. Seniors actively look for dead code. If analytics show a feature is used by 0,5% of users but takes up 15% of the maintenance time, a senior will advocate to kill it. Less code = less cognitive load. 3) Saying "NO" to Product Managers. The highest value a senior brings is looking at a Jira ticket and telling the business "The ROI on building this feature is negative. It will take 3 weeks to build and brings minimal value. Let's solve it with a process change instead." Typing speed is irrelevant. Efficiency in 2026 is pure decision quality. Engineering Managers & CTOs: Are you paying your seniors to type or are you paying them to think? 🤔

Technical decisions are almost never purely technical. They spill over into business outcomes and organizational implications. Speed versus reliability. Build versus buy. Consistency versus flexibility. Quick win releases versus long-term maintainability. Every significant technical decision involves a tradeoff. Many organizations make those tradeoffs with blinders on. People may choose a path without fully understanding what they’re giving up. Decision-makers who aren’t technically savvy may be attracted to the promise of new technologies without fully grasping the risks. They may expect fast results with a new technology and not account for slower progress as people learn. Senior, Staff and Principal Engineers are often the only people in the room who can see the full shape of a tradeoff. The ability to communicate those in language that doesn’t require a deep technical background is a real skill. The people who can connect the implications to what others care about—which may not be the technology itself—can inform decisions. Both require the ability to see the world from another point-of-view. Making tradeoffs visible and understandable is one of the most valuable things a technical leader can do. It is also one of the most undervalued contributions, because it doesn’t look like a deliverable. It looks having lots of conversation (and maybe building a PowerPoint deck). But here’s the payoff. Organizations that make tradeoffs explicit make better decisions. They create more sustainable systems. Further, they waste less time reversing choices that were made without full information or on the basis of hope. That’s the value of one technical leader who knows how to surface and explore issues when others lack context or expertise. This is a leadership skill. It requires the courage to slow a conversation down. It takes clarity to name what’s at stake. Understanding impacts beyond the tech stack requires curiosity and point-of-view empathy. All of this takes enough credibility that people trust your read of the situation. None of this comes from technical expertise alone. #Leadership #TechnicalLeadership #Tradeoffs #BetterDecisions