Capability before dependency.

There are two ways a leader can look brilliant in their first ninety days.

The first is to become the chief firefighter. Every technical choice, every commercial exception, and every awkward client call travels up to your desk. You work until midnight, you make crisp decisions, and people praise your grip on the business.

The second is to govern by cheque book. Whenever a capability gap appears, whether in security compliance, product engineering, or data science, you bring in an external vendor or a squad of consultants to build and run it for you. Demos happen on schedule, slide decks look polished, and the board sees immediate motion.

Both approaches buy speed in Quarter 1. Both leave the organisation weaker by Year 2.

When the hero leader goes on holiday for two weeks, decisions freeze because nobody one layer down has practiced making a call without a safety net. When the external consultant's contract ends, the slide deck stays behind, nobody on your floor truly understands why the architecture was wired that way, and a renewal invoice arrives on Friday morning for every minor change request.

Early in my career, I learned a principle that has shaped how I build teams, products, and businesses ever since: capability before dependency.

My job as a leader is not to be the indispensable brain in the room, nor is it to rent a permanent crutch from outside. My job is to leave behind stronger leaders, clearer processes, and enduring systems that keep improving long after I have moved on to the next problem.

The 2026 dependency trap: when tools and vendors think for you

For decades, organisational dependency meant one of two things: over-reliance on a single heroic executive, or over-reliance on an outsourced system integrator.

In 2026, a third, quieter form of dependency has entered the building: cognitive offloading.

As generative AI and automated coding and analysis tools have become standard issue across every desk, a joint research team from Microsoft Research and Carnegie Mellon University studied 319 knowledge workers across 936 real-world tasks to see what happens to human judgment when machines take over routine cognitive work.

Their findings should sit on every executive's desk:

• The confidence trap is real. When workers held high, uncritical confidence in an AI tool, they measurably reduced their cognitive effort and independent critical thinking. They shifted from active problem-solvers to passive rubber-stampers.
• Domain mastery is the only shield. Workers who already possessed deep, task-specific mastery used the tools very differently. Because they knew what a flawed assumption looked like, they interrogated the output, caught subtle errors, and kept their analytical edge.
• The irony of automation has returned. Drawing on cognitive psychologist Lisanne Bainbridge's classic 1983 paper "Ironies of Automation," the researchers pointed out a trap that every engineering and operations leader now faces. When you automate all routine tasks and leave only the rare, high-stakes exceptions to the human operator, you strip that human of the daily mental reps that built their judgment in the first place. When a complex edge case finally breaks in production on a Friday evening, the person on duty has an atrophied mental muscle right when you need them at their sharpest.

Combine that cognitive offloading with traditional vendor lock-in and you get the modern enterprise paradox: companies spending record sums on software licenses and external specialists while their own teams understand less and less about how their core operations actually work.

Moving knowledge across continents: a lesson from an R&D lab

I first saw what genuine capability transfer looks like when I joined a global consumer-goods R&D organisation in Mumbai.

At the time, much of the foundational laundry science (how surfactants, builders, fragrance, and fabric behave across different water conditions and washing habits) had been developed over decades in European laboratories. It would have been easy to treat the Mumbai lab as a local testing outpost: wait for headquarters to send a finished formula, run a stability check in local heat and humidity, and sign the sheet.

That is dependency disguised as global process.

Instead, the mandate was to build a self-sufficient global R&D capability in Mumbai. We had to take scientific knowledge that had lived in another country and make it native to our people, our pilot plants, and our local supply chain so that we could invent products for Indian homes and factories from first principles.

Inside that lab, I learned that capability never transfers through manuals alone. Documents record what was decided; they almost never capture what failed along the way or why a boundary was drawn where it was. Capability only moves when people work shoulder to shoulder on real problems under structured progression.

One of the moments I am proudest of from those years had nothing to do with a patent or a factory trial. It was working with a bright junior engineer on my team.

In her first few months, when a formulation experiment produced an unexpected viscosity shift, her natural instinct was to bring the raw numbers to my desk and ask what we should run next. If you are in a hurry, you give the answer in ninety seconds and go back to your own work. Every time you do that, you steal a learning rep from your team.

Instead, we established a simple rule: never bring me a raw data table without your own hypothesis and the next two experiments you would run if I were not here. In the beginning, we went through her logic line by line. Six months in, she was framing the experimental matrix on her own and defending her conclusions in cross-functional reviews. Within roughly two years, she was promoted to Senior Engineer and was coaching the next cohort of hires herself.

The same pattern repeated years later when I co-founded a blended-learning startup. A college intern joined our engineering team with raw curiosity and very little production experience. Rather than parking him on internal scripts or isolated bug fixes, we gave him structured ownership over real product slices, paired with uncompromising code reviews and direct exposure to teacher and student feedback. Step by step, he grew into a full-stack developer and eventually became our Technical Lead.

And in my current role leading product, technology, and AI transformation across a large group of schools, higher-education institutions, and software ventures, the same principle scaled to leadership architecture. When I arrived, too many routine technical and delivery escalations were travelling all the way to the top. We took four strong senior engineers and deliberately converted them into independent cluster leaders, giving each of them clear domain boundaries, explicit KPIs, and direct accountability to business stakeholders. Today, those clusters run with a speed and pride that no single central bottleneck could ever match.

Core brain vs. rented muscle: the $12,000 vendor lesson

Building internal capability does not mean suffering from "not invented here" syndrome. No sensible leader writes their own database engine or builds commodity payment rails from scratch.

The art lies in drawing a hard line between your core brain and rented muscle.

Your core brain is anything that defines how your business creates value, makes decisions, or manages risk: your domain data model, your product architecture, your customer workflows, your security posture, and the evaluation gates that judge whether a system is working. If you hand any of those to an outside vendor without an internal owner who understands them cold, you are mortgaging your future velocity.

Not long ago, we needed to formalise our security and compliance posture around ISO 27001, SOC 2, and governance, risk, and compliance (GRC) controls. The first proposal that landed on the table was a comprehensive US$12,000 vendor package. It came wrapped in impressive jargon: multi-framework automation, external advisory retainers, and enterprise-grade modules designed for a ten-thousand-person bank.

In many companies, that quote gets signed because compliance feels scary and executives want someone else's logo on the risk register.

Instead, we applied a simple commercial discipline:

1. Clarify what our current maturity stage actually requires. You do not buy a Formula 1 telemetry rig to pass a road-safety inspection. We separated the essential controls that genuinely protected our data and customers today from premature scope that belonged two years down the road.
2. Benchmark four to five competing vendors on trade-offs, not pitch decks. Comparing multiple providers side by side immediately exposed which line items were genuine audit requirements and which were high-margin consulting padding.
3. Phase the investment and keep the learning internal. We reframed the entire engagement into a focused, phased US$3,000 programme. More importantly, our own engineering leads did not hand the checklist over the wall. They implemented the policies, understood the reason behind every access control and backup rule, and owned the evidence trail directly.

We saved 75% of the cash cost on Day 1. The real dividend, though, arrived six months later: when we built our next product platform, security and compliance were already baked into how our own engineers wrote code, because the knowledge lived inside their heads rather than inside a consultant's binder.

Sakichi Toyoda's loom and the harness for AI teams

Over a century ago, before Toyota ever built an automobile, Sakichi Toyoda invented an automatic power loom with a deceptively simple mechanism: the moment a single warp or weft thread snapped, the machine stopped itself immediately and flagged the operator.

In the Toyota Production System, that principle became known as Jidoka, often translated as "automation with a human touch."

Notice the philosophy underneath it. A factory could have used automation to turn workers into mindless machine-tenders who swept the floor while the loom cranked out yards of defective cloth. Instead, Toyoda designed the machine to stop so the human operator had to diagnose why the thread broke and fix the root cause before restarting the line. The machine handled the repetitive physical throw of the shuttle; the human owned the diagnosis and quality standard. Every broken thread made the operator smarter.

That is the exact choice leaders face with AI and software automation in 2026.

If you deploy AI as an autopilot, where junior engineers paste tickets into a code generator and commit whatever compiles, or managers paste raw spreadsheets into a chat window and forward the summary to the board, you are building a brittle organisation. Six months from now, your codebases will be full of subtle architectural rot that nobody on the team knows how to debug, and your meetings will be full of fluent paragraphs that nobody in the room can defend when challenged on the numbers.

If, instead, you deploy AI as a sparring harness, the opposite happens:

• The human writes the hypothesis first. Before touching a model, the engineer or product manager writes a ten-line note: Here is the operating problem, here are the constraints, and here is my proposed approach.
• The model is used to attack the weak spots. Instead of asking the AI to "Write the strategy," the team asks it to "Find the three ways this architecture will fail under peak load, check whether these clauses contradict our existing policy, and generate edge-case tests I missed."
• The human owns the verification gate. Every line of code and every business recommendation is verified against primary evidence. When an executive asks in a review why a parameter was chosen, "The model suggested it" is never an acceptable answer.

Used that way, AI does not replace the junior engineer's growth ladder; it accelerates it, because every task becomes a live code review and a stress-test of their own reasoning.

Five rules for building an organisation that outlasts you

Whether you are leading a five-person product squad or a five-hundred-person enterprise transformation, shifting from dependency to capability comes down to five daily habits:

1. Coach the reasoning, never rewrite the deliverable

The hardest habit for a high-performing specialist to break when they become an executive is grabbing the keyboard. When someone brings you a seventy-percent document or a flawed architecture diagram, fixing it yourself takes twenty minutes. Coaching them through why it breaks takes forty-five. Spend the forty-five minutes. The first time costs you twenty-five extra minutes; the tenth time saves you a hundred hours.

2. Require options and trade-offs, not upward delegation

Ban the question "What should we do?" from one-on-ones once a person has been in their role for ninety days. Replace it with a simple contract: bring the problem, bring two or three viable options, show the evidence and trade-offs for each, and tell me which one you recommend. Even when their recommendation is wrong, you can now coach how they weighed the trade-offs rather than handing down an oracle's decree.

3. Write the Day-180 exit into every vendor contract on Day 1

Whenever you bring in an external partner or specialist agency, ask one question before signing the statement of work: how does our internal team run this without them in six months? Pair an internal engineer or operator with the vendor from the first sprint, require clean documentation and runbooks as a condition of milestone payment, and make knowledge transfer a gated deliverable rather than a polite wish at the end.

4. Expose emerging leaders to the real heat early

People do not learn executive judgment by watching from the back row. Bring your high-potential engineers and product leads into the board prep, the commercial negotiation, and the tough post-mortem. Let them present their own work, feel the weight of real questions from the promoter or CFO, and see how trade-offs are weighed across finance, operations, and technology. Keep a hand on their shoulder before and after the meeting, but let them hold the mic during it.

5. Grade yourself by the Three-Week Vacation Test

Once a year, ask yourself an honest question: if I lost my phone in a river tomorrow and could not reach the office for three weeks, what would happen?

If the honest answer is that key launches would stall, vendors would run wild, and your direct reports would wait in a queue until you returned, do not flatter yourself that you are working hard. You have built a bottleneck with your own name on it.

If the answer is that your cluster leads would run the weekly reviews, challenge the vendors on evidence, ship the release, and only flag the one genuine strategic call that belonged at your level, then you have done the real work of leadership.

Products age. Markets shift. Tools get replaced every three years. The only thing that truly compounds inside an enterprise is the capability of the people and systems you leave behind.

The true test of a leader is not what the organisation achieves while they are in the room. It is what continues to improve six months after they have moved on.