The Advisory Mindset: Shifting From Execution to Strategy

Transcript

Here is a number that should stop you cold. Research by the Carnegie Institute of Technology found that 85% of financial success comes from human engineering skills — communication, negotiation, relationship-building — while only 15% comes from technical knowledge. Fifteen percent. Most engineers spend their entire careers optimizing for the smaller number. That is not a personal failure. It is a structural blind spot baked into how technical professionals are trained. You are taught to solve problems. You are rarely taught to make those solutions matter to the people holding the budget. Now, think of a surgeon who performs a flawless operation but never explains the diagnosis to the patient. The technical work is perfect. The outcome still fails. That is the gap facing technical advisors every day. The Project Management Institute studied this directly. They found that for every one billion dollars spent on projects, 135 million dollars is at risk. And 56% of that risk traces back to ineffective communication. Not bad code. Not poor architecture. Communication. That means the most dangerous thing in a technical project is often not a technical problem at all. It is the failure to translate what you know into what your stakeholders need to hear. So how do you close that gap, Mariglen? The answer starts with a model developed by David Maister called the Trusted Advisor framework. Maister's core insight is precise and uncomfortable. An advisor's perceived trustworthiness is inversely proportional to their self-orientation. The more you focus on your own technical solution rather than the client's actual need, the less they trust you. Full stop. This is why active listening is a more powerful tool than immediate problem-solving. When you rush to answer, you signal that your solution matters more than their problem. When you listen first, you signal alignment. You become a partner, not a vendor. The key idea here is that trust is not built by being right. It is built by making the other person feel understood. There are three core tenets that effective technical advisors use to operate from this mindset. First, lead with context, not capability. Instead of saying "I can build a microservices architecture," say "based on your growth targets, here is what your infrastructure needs to support." You are anchoring your expertise to their goal. Second, reframe risk in business language. Engineers talk about system failure rates. Executives talk about revenue exposure. Same reality, different vocabulary. For example, instead of "our uptime is 99.2%," say "we are currently exposed to roughly 63 hours of potential downtime per year." That lands differently. Third, ask before you advise. A single well-placed question — "what does success look like for you in six months?" — does more to reduce stakeholder friction than three slides of technical justification. These language shifts are not cosmetic. They reposition you from service provider to strategic partner. The takeaway from all of this is direct, Mariglen. Technical excellence is the entry ticket. It is not the game. The advisors who create the most organizational value are not always the most technically sophisticated people in the room. They are the ones who understand that every technical decision is also a business decision. Shifting your focus from how things work to why they matter for the organization's goals is not a soft skill add-on. It is the core competency of the role. Remember this: the engineer who can build anything but cannot connect it to a business outcome will always be executing someone else's strategy. The advisor who masters that connection gets to shape the strategy itself. That is the shift this course is built around, and it starts right here.