DEV Community: Victor Leung

Career Reflections from a Mentorship Coffee Chat

Victor Leung — Sun, 08 Nov 2026 15:01:26 +0000

Yesterday, I sat down for my first coffee chat of the year as a returning mentor for the New Asia College Mentorship Programme at The Chinese University of Hong Kong. Entering my second year as a mentor, I was eager to meet my mentees, who are bright minds on the cusp of graduating in Financial Technology. Listening to their questions, I could feel the weight of the current graduate market. Shrinking headcounts, fierce competition from returning overseas graduates, and the omnipresent shadow of artificial intelligence have left many students wondering where they actually fit. Yet, as we unpacked their concerns one by one, it became clear that the best antidote to market anxiety is not chasing the latest technical buzzword, but stepping back and thinking from first principles.

Having completed banking internships, one of my mentees noticed that almost every conversation around artificial intelligence revolves around internal automation and cost-cutting, asking me if I agreed that the technology is simply a game of automation. I respectfully disagreed. When you are deep inside a bank's technology division, it is easy to get lost in the weeds of scripts, workflows, and headcount efficiency. If we strip away the noise and return to first principles, we have to ask why a company exists in the first place. A business exists to deliver a product or service that creates genuine value for an end customer. Regardless of your future title, and regardless of whether you use artificial intelligence or not, your primary objective is to serve the customer. Automation that saves internal hours means very little if the institution fails to solve customer problems, so you must never let the mechanics of a tool blind you to the ultimate purpose of the enterprise.

Another classic worry among Financial Technology undergraduates is feeling caught in the middle, fearing their curriculum is neither deeply technical enough to compete with pure computer science majors on engineering, nor commercially focused enough to outshine traditional finance graduates. To turn this perceived weakness into a strategic asset, you have to understand the true nature of financial technology from first principles. When I asked what separates a digital bank from a traditional incumbent bank, the instinctive answer was a smoother user experience, which is only partially correct. The real difference lies in the business model and cost structure. Incumbent banks carry massive structural overhead from handling physical cash, operating branch networks, and maintaining legacy mainframes. Because of this heavy cost base, they struggle to meet evolving customer needs and end up losing market share in profitable lending businesses. Understanding how technology reshapes unit economics is the real essence of the discipline.

When deciding where to apply, many graduates cast a wide net across traditional banks, technology challengers, and consulting firms without matching their strengths to the employer's actual demand. While landing an offer always involves an element of luck and timing, you must align your long-term career goals with what the company actually lacks. If you apply to traditional banks, remember that they do not lack technical specialists or business analysts; they struggle to change with agility because existing staff are entrenched in legacy ways of working. Your real competitive advantage there is your fresh mindset as new blood. Conversely, if you apply to a financial technology firm, they are often packed with deeply technical engineers who lack domain experience in banking. In that environment, your financial domain knowledge becomes your greatest differentiator.

We also discussed whether the Big Four consulting firms remain a good career option, which requires understanding the fundamental nature of their business. Consultancies are in the business of selling people and project delivery. They first secure a client with a strict delivery timeline, and then hire or staff individuals to fill those roles. A precise skillset match is often less relevant to them than your sheer ability to deliver on schedule. Understanding this model takes the sting out of rejection: if you do not get the role, it is often not about your capability, but simply that the firm lost the client pitch. By the same token, even if you have the right skills and land the job, a dry project pipeline means you will end up sitting on the bench and eventually face layoffs.

Still, the overarching anxiety about artificial intelligence replacing junior roles altogether lingers for many graduates who struggle to see where their careers fit in an automated world. Looking back at the finance industry over the last decade, there has been a continuous trend of outsourcing information technology to lower-cost centers in mainland China or India. Today's shift toward artificial intelligence is fundamentally just another form of outsourcing, moving routine work from low-cost labor to machine automation. The real question you should ask yourself is why some companies choose to outsource while others fiercely build in-house. Institutions like J.P. Morgan and Goldman Sachs build their own systems because they treat technology as a core differentiator to compete in the market, rather than a pure cost center. They operate as technology companies first, with finance as their product. You want to join organizations that view technology as an investment, whereas companies that treat it purely as a cost will cling to legacy stacks and spend only when forced—much like how some consumers upgrade to the latest iPhone every year while others refuse to spend until their old phone completely breaks down.

For those who still feel unsure about what path to take, or worry about making early career mistakes, my advice is to look across a longer horizon of three to five years. When you are graduating, it is easy to feel boxed in by immediate constraints like your degree major, job descriptions demanding prior experience, and recruiters expecting you to know everything on day one. Do not let those temporary friction points limit your imagination. Over a three-to-five-year window, your career can pivot into completely different roles or industries, provided you take the time to figure out what you actually want and what you enjoy doing. Only work that you genuinely enjoy is sustainable over the long run.

When my mentee admitted they did not know their real strengths or interests—Modestly noting they just seemed to do okay and get lucky with top grades in exams—I pointed out that our education system is largely at fault. School trains us to obsess over fixing our weaknesses rather than identifying and compounding our strengths. Taking assessments like CliftonStrengths can help uncover what you are naturally wired to do well. In the age of artificial intelligence, this self-awareness is critical because the technology acts as an amplifier of your natural strengths, not a replacement. If you enjoy client-facing work, artificial intelligence will help you draft faster and operate more efficiently, saving you time so you can spend even more of your day in front of clients. Ultimately, take a step back and reflect on your life purpose and your childhood dreams; they often hold the clearest clues to what you truly want, giving you the foundation to build a fulfilling career.

The Quiet Discipline of Effective Management

Victor Leung — Sat, 31 Oct 2026 15:58:54 +0000

Management is often misunderstood as the art of getting people to do what we want. We build organizational structures, establish performance indicators, introduce reporting mechanisms, and hold meetings to ensure that work progresses according to plan. Yet despite these efforts, many organizations continue to struggle with disengagement, misalignment, and inconsistent performance. Perhaps the fundamental problem is not that managers lack sufficient control, but that they have confused control with leadership. Effective management is not about making people work harder. It is about creating the conditions in which people understand what success looks like, recognize when they are making progress, and have the confidence to correct their course when they fall short.

The most effective management practices are often surprisingly simple. They require neither sophisticated frameworks nor elaborate performance management systems. Instead, they rest on three disciplines: establishing clear goals, recognizing good performance, and redirecting behavior when expectations are not met. These ideas may sound elementary, but their simplicity conceals a deeper challenge. They require managers to move beyond supervising activities toward developing human capability. And that transition demands something far more difficult than administrative competence: the willingness to trust people while remaining accountable for results.

Consider how goals are typically established in organizations. Senior leadership defines strategic objectives, which cascade through departments into team targets and individual performance indicators. By the time these objectives reach the people responsible for delivering them, their original purpose may have become obscured by layers of interpretation. Employees understand what they have been asked to do, but not necessarily why it matters or how their contributions connect to the broader mission. As a result, they become exceptionally busy without always becoming more effective. They may complete every assigned task while making little meaningful progress toward the outcomes the organization actually needs.

This reveals an important distinction between activity and achievement. A person can spend an entire day attending meetings, responding to messages, and producing deliverables, yet contribute almost nothing to the organization's strategic objectives. Effective managers understand that productivity is not measured by how much work gets done, but by how much valuable progress that work creates. Their responsibility is therefore not merely to assign tasks, but to help people develop a clear understanding of the outcomes that matter. A well-defined goal should answer several essential questions: What are we trying to achieve? Why does it matter? What does good performance look like? When must it be accomplished? And how will we know whether we have succeeded?

The process of defining these goals should be collaborative rather than unilateral. When people participate in shaping their objectives, they are more likely to understand the trade-offs, recognize potential obstacles, and take ownership of the results. A goal should be sufficiently clear that it can be summarized on a single page, not because every meaningful ambition can be reduced to a few sentences, but because clarity is a test of understanding. If a manager and an employee cannot explain their shared expectations concisely, there is a reasonable chance that they do not yet share the same definition of success. The purpose of goal-setting is not to create documentation for an annual review. It is to establish a common reference point for everyday decisions.

Yet defining goals is only the beginning. Strategy becomes meaningful through repeated choices, and those choices are made in the ordinary moments of a working day. An effective manager encourages people to revisit their priorities regularly and ask themselves a deceptively powerful question: Is what I am doing right now bringing me closer to what I am trying to achieve? This brief act of reflection introduces self-correction into daily work. It shifts accountability from an external mechanism imposed by management to an internal discipline practiced by individuals. Over time, the manager no longer needs to monitor every activity, because people have developed the judgment to monitor themselves.

This is particularly important in knowledge-intensive environments, where outcomes cannot always be measured through visible activity. In technology strategy, for example, producing more architectural diagrams, governance documents, or technology roadmaps does not necessarily mean that the enterprise has become more adaptable, resilient, or efficient. The real question is whether these artifacts have improved decisions, reduced unnecessary complexity, or enabled measurable business outcomes. A manager who evaluates the number of deliverables may unintentionally reward bureaucracy. A manager who evaluates their contribution to strategic outcomes encourages meaningful innovation. What we choose to recognize ultimately shapes what people choose to optimize.

This brings us to the second discipline of management: recognition. Too many managers regard good performance as an expected obligation that requires no acknowledgment. Their attention naturally gravitates toward problems, exceptions, and mistakes. When everything goes well, they remain silent; when something goes wrong, they intervene. Over time, employees may learn that the most reliable way to attract managerial attention is to make a mistake. Such an environment creates anxiety rather than excellence, because people become more concerned with avoiding criticism than with pursuing improvement.

Recognition provides an alternative mechanism for shaping behavior. When someone demonstrates sound judgment, takes initiative, helps a colleague, or produces an exceptional result, a timely and specific acknowledgment reinforces the behavior worth repeating. The important distinction is between generic praise and meaningful recognition. Telling someone that they have done a good job may provide temporary encouragement, but explaining precisely what they did well and why it mattered offers something more valuable: information they can use to improve. For example, recognizing an employee for identifying an architectural dependency before it became a delivery risk communicates that foresight, collaboration, and risk awareness are qualities the organization values.

Recognition is most effective when it is sincere, immediate, and connected to observable behavior. It should not become an artificial ritual or a technique for manipulating emotions. People generally recognize the difference between appreciation and flattery. Genuine praise acknowledges both the contribution and the individual judgment behind it, while making clear that their success matters. A moment of acknowledgment, followed by an opportunity for the person to appreciate what they have accomplished, can be more meaningful than an elaborate reward delivered months later. It reinforces competence, encourages confidence, and establishes a foundation of trust.

Nevertheless, recognition alone cannot sustain performance. Mistakes are inevitable, particularly in organizations that encourage experimentation, independent judgment, and innovation. The question is not whether people will fail, but how managers respond when they do. Traditional management often treats mistakes as occasions for blame or punishment. Yet punishment can be particularly counterproductive when the individual is still learning. It may suppress the immediate behavior, but it does not necessarily develop the understanding required to perform better. Worse, it can teach people to conceal errors, avoid difficult decisions, and prioritize personal protection over organizational learning.

A more constructive response begins with an important diagnostic question: Was the expectation genuinely clear? If the employee did not understand the goal, lacked the necessary resources, or received conflicting instructions, the problem may lie partly within the management system rather than the individual's conduct. Before correcting someone, a manager should establish the facts and distinguish among misunderstandings, capability gaps, poor judgment, and deliberate disregard for agreed expectations. These situations may produce similar outcomes, but they require fundamentally different responses. Fairness begins with understanding the cause rather than reacting only to the consequence.

When expectations were clear and an individual has made a mistake, effective redirection should be timely, specific, and focused on behavior. The manager should explain what happened, why it matters, and what consequences may follow if the behavior continues. This conversation need not be lengthy, but it should be unambiguous. Avoiding difficult feedback in the name of kindness is not necessarily compassionate; it can deprive people of the information they need to improve. At the same time, criticism should never become an attack on personal character. A person's performance can be disappointing without the person being a disappointment. This distinction is fundamental to preserving dignity while maintaining accountability.

The most powerful corrective conversations combine high expectations with genuine confidence in the individual's capacity to improve. A manager might communicate that the outcome fell short of what was agreed, acknowledge the impact, and then reaffirm the belief that the person is capable of better. This does not excuse the mistake or eliminate responsibility. Rather, it makes improvement psychologically possible by separating an unsuccessful action from a permanent judgment about the individual. A person who believes that one failure has permanently damaged their reputation may become defensive or disengaged. Someone who understands that the mistake matters, but that trust can be maintained through learning and responsible action, is more likely to respond constructively.

An equally important discipline is knowing when to end the conversation. Once the mistake has been addressed, expectations clarified, and corrective action agreed, repeatedly revisiting the same incident can turn feedback into resentment. The manager should allow the individual to move forward without carrying a permanent label. This does not mean overlooking repeated problems or abandoning formal accountability when circumstances require it. It means treating a resolved incident as resolved, while continuing to evaluate future performance fairly. The objective of redirection is not to establish who was wrong. It is to increase the likelihood that the next decision will be better.

These three disciplines—clarity, recognition, and redirection—form a continuous management cycle. Goals establish direction. Recognition reinforces behaviors that create progress. Redirection corrects deviations and creates opportunities for learning. As people develop greater capability, they become increasingly able to apply these disciplines themselves. They learn to define meaningful objectives, recognize effective behavior, and examine their own mistakes without waiting for managerial intervention. At that point, management has achieved something far more valuable than short-term compliance: it has cultivated independent judgment.

There is, however, a danger in interpreting simplicity as a substitute for deeper organizational leadership. A brief conversation cannot compensate for contradictory priorities, unrealistic workloads, insufficient resources, or a culture that punishes transparency. Nor should immediate recognition replace fair compensation, meaningful career development, or the removal of systemic obstacles. Effective management requires both interpersonal discipline and organizational design. Managers must ensure that the systems surrounding their teams support the behaviors they claim to value. Otherwise, the organization may celebrate collaboration while rewarding individual competition, encourage innovation while penalizing reasonable failure, or demand accountability without granting the authority necessary to act.

This is where the distinction between management and leadership becomes less useful than the relationship between them. Leadership establishes purpose and direction; management translates that purpose into repeatable decisions and behaviors. Neither is sufficient without the other. An inspiring vision without clear expectations can produce enthusiasm without execution. Rigorous performance management without trust can produce compliance without commitment. The challenge is to integrate strategic clarity with human understanding, creating an environment where people are both supported and expected to perform.

As artificial intelligence and automation increasingly reshape the workplace, this challenge becomes more significant, not less. Technology can automate reporting, monitor performance indicators, and identify deviations from expected outcomes. It can provide managers with unprecedented visibility into organizational activity. But visibility should not be confused with understanding. A dashboard may reveal that a milestone has been missed, but it cannot fully explain the human circumstances, conflicting priorities, or organizational assumptions behind the result. The availability of more data does not diminish the importance of managerial judgment. It makes that judgment more consequential.

The manager of the future should therefore be less concerned with supervising every action and more focused on enabling better decisions. Their distinctive contribution will lie in clarifying ambiguity, developing capability, removing constraints, recognizing meaningful progress, and facilitating honest conversations when things go wrong. Rather than becoming the central decision-maker through whom every issue must pass, the manager should create an environment in which good decisions can be made throughout the organization. This is not an abdication of responsibility. It is a more mature form of accountability, one in which success is measured partly by how effectively others can perform without constant intervention.

Ultimately, the quality of management is revealed not only in what a team achieves, but also in who its people become through the process of achieving it. Do they grow more confident in their judgment? Do they understand how their work contributes to a meaningful purpose? Are they willing to acknowledge mistakes, learn from them, and attempt difficult things again? Can they succeed without continually seeking permission or reassurance? These questions reveal a dimension of management that conventional performance indicators often overlook: the long-term development of human capability.

Perhaps the greatest paradox of effective management is that the better a manager becomes, the less dependent people become on being managed. Clear goals reduce the need for supervision. Genuine recognition strengthens the confidence to act independently. Constructive redirection develops the judgment to recover from mistakes. What begins as a set of simple managerial practices ultimately becomes a culture of ownership, learning, and trust.

The true achievement of a manager is not to become indispensable to the team's success, but to make the team increasingly capable of succeeding without them. That is the quiet discipline of effective management: helping people understand where they are going, recognize when they are on the right path, and find the courage to change direction when they are not. Great management is not measured by how much authority we exercise over others, but by how much capability, confidence, and responsibility we help them develop within themselves.

Technology Strategy Is Not a Plan

Victor Leung — Fri, 30 Oct 2026 14:05:14 +0000

The greatest obstacle to successful technology strategy is rarely a lack of effort, resources, or execution. More often, it is our inability to question the assumptions and mental models that guide our decisions.

There is a peculiar tendency in management: when results fall short of expectations, our instinct is often to work harder rather than think differently. We demand greater discipline, tighter governance, more detailed plans, and stronger execution. Yet we rarely question whether the underlying logic guiding our efforts was sound in the first place. We become increasingly efficient at doing things that may never have been worth doing. And when those efforts fail, we prescribe more of the same.

Over my years as a technology consultant and Enterprise Architect, I have witnessed this pattern repeatedly. Organizations invest heavily in digital transformation but struggle to demonstrate meaningful business value. Technology leaders establish architecture frameworks, governance committees, and multi-year roadmaps, yet remain frustrated by the pace of change. Executives demand greater agility while simultaneously introducing additional layers of approval and control. Despite enormous investments in technology, talent, and methodologies, many organizations find themselves confronting essentially the same problems year after year.

Perhaps the problem is not that we are executing our strategies poorly. Perhaps we are operating with the wrong mental models altogether.

Consider a student who consistently performs poorly in examinations. A conventional response might be to recommend studying longer, attending more classes, or practicing additional exercises. But a more revealing conversation begins with different questions: What do you believe caused the unsatisfactory results? What daily choices contributed to this outcome? What assumptions led you to make those choices? And what would you need to change to produce a different result?

These questions shift attention from effort to causality. They reveal that poor outcomes may not reflect insufficient commitment but an ineffective approach to learning. A student who spends hours memorizing information without understanding it may need an entirely different method rather than additional study time. The same principle applies to enterprise management. Before demanding greater execution, we should examine whether the choices we are executing are capable of producing the outcomes we desire.

This is where effective technology strategy begins: not with better planning, but with better thinking.

One of the most persistent misconceptions in corporate management is that having a plan means having a strategy. Annual planning cycles generate budgets, investment proposals, project portfolios, milestones, and elaborate technology roadmaps. These artifacts create the reassuring impression that the future has been carefully considered and uncertainty brought under control. Yet a collection of planned activities, however comprehensive, does not constitute a strategy.

Planning addresses what we intend to do. Strategy addresses why those choices should enable us to succeed.

A technology roadmap might specify that an organization will migrate workloads to the cloud, modernize its data platform, adopt artificial intelligence, and retire legacy systems over the next three years. These may all be sensible initiatives, but they do not explain how the organization expects to create a distinctive advantage. More importantly, they do not explain why these investments deserve priority over competing opportunities, which capabilities matter most, or what the organization has deliberately decided not to pursue.

A genuine strategy requires choices, and meaningful choices inevitably involve uncertainty. If every initiative is considered essential, every stakeholder's priority is accommodated, and every proposed investment receives a place on the roadmap, the organization has probably avoided the difficult work of strategy. It has produced a politically acceptable plan instead.

The purpose of strategy is not to eliminate uncertainty. It is to improve the odds of success by making coherent choices under uncertainty. That distinction matters because it changes how leaders approach both strategic formulation and management.

One particularly useful approach is the five-choice strategy framework popularized by A.G. Lafley and Roger Martin. It asks five deceptively simple questions: What is our winning aspiration? Where will we play? How will we win? What capabilities must we have? What management systems do we need?

These questions form an integrated logic rather than five independent planning exercises. Each choice shapes the next, while new insights can require earlier choices to be reconsidered. Together, they force leaders to connect ambition with competitive positioning, organizational capability, and the practical mechanisms required for execution.

For an Enterprise Architect, the implications are significant.

Traditionally, Enterprise Architecture has often been perceived as a discipline concerned with technology standards, target-state designs, application rationalization, and governance compliance. These responsibilities remain important, but they are insufficient for today's strategic challenges. Architecture that begins with technology solutions rather than strategic choices risks becoming an elaborate exercise in optimizing the existing environment.

The more valuable contribution of Enterprise Architecture is to translate strategic intent into the organizational and technological capabilities required to realize it.

Imagine a financial services organization aspiring to deliver a differentiated digital investment experience. Its ambition is not simply to implement a new investment platform. It must decide which customer segments it intends to serve, which experiences will distinguish its offering, and how it will compete against established institutions and emerging digital competitors. These choices subsequently determine whether the organization requires capabilities in personalized portfolio analytics, real-time data integration, automated investment operations, digital client servicing, or some combination of them.

Only after establishing this strategic logic should architectural decisions about platforms, applications, data architecture, integration patterns, and infrastructure become meaningful. Technology becomes the means of realizing a strategic choice rather than the starting point of the discussion.

This requires a fundamental change in the capabilities we expect from technology leaders.

The first is the capability to challenge mental models. Every strategy rests on assumptions, whether acknowledged or not. An organization might assume that centralized governance always improves control, that standardization necessarily reduces cost, or that replacing legacy technology automatically produces business agility. Such assumptions may be valid in certain circumstances, but they are not universal truths. Effective leaders make these beliefs explicit, examine the evidence supporting them, and remain willing to revise them when reality contradicts expectations.

A particularly useful management practice is to distinguish observable facts from interpretations and assumptions. When a transformation initiative falls behind schedule, the immediate conclusion may be that delivery teams lack discipline. An alternative hypothesis might be that architectural dependencies, fragmented decision rights, or conflicting business priorities are creating systemic delays. Each explanation implies a very different intervention. The quality of the outcome therefore depends on the quality of the diagnosis.

The second is the capability to think in systems rather than isolated projects. Enterprises are complex systems in which technologies, processes, incentives, organizational structures, and human behavior interact. Improving one component does not necessarily improve the whole. A new technology platform might reduce infrastructure costs while increasing operational complexity. An additional governance checkpoint might reduce certain risks while making delivery slower and encouraging teams to circumvent the process. A successful local optimization can produce an undesirable enterprise-wide outcome.

Systems thinking encourages architects and executives to examine dependencies, feedback loops, unintended consequences, and the constraints that determine overall performance. Instead of asking whether each project is progressing according to plan, leaders should ask whether the combined portfolio of initiatives is changing the organization's capabilities in the intended direction.

The third is the capability to formulate and test strategic hypotheses. Rather than presenting strategies as conclusions that must be defended, we should treat them as reasoned hypotheses that require evidence. A decision to invest in a shared data platform, for example, might be based on the hypothesis that consistent, reusable data products will reduce duplicated integration effort and accelerate the delivery of analytics across business units.

That hypothesis should have observable indicators of success. Are teams reusing data products? Are integration lead times decreasing? Is data quality improving? Are new business capabilities reaching customers faster? If the evidence does not support the hypothesis, the appropriate response is not automatically to increase investment or enforce adoption more aggressively. It is to reconsider the assumptions, design, incentives, and conditions necessary for the original strategy to work.

This mindset draws from scientific inquiry, experimentation, and continuous learning. It replaces the illusion of perfect foresight with an organizational ability to learn faster than circumstances change.

The fourth is the capability to manage through capabilities and outcomes rather than activities and deliverables. Projects are temporary vehicles for change; capabilities are enduring organizational abilities that create value. Completing a cloud migration, implementing a new customer relationship management system, or deploying an artificial intelligence solution is not, by itself, evidence of strategic success.

The more important question is what the organization can now do that it could not do before. Can it launch products more quickly? Make better investment decisions? Deliver more personalized customer experiences? Respond to regulatory changes with less disruption? Reduce operational risk without sacrificing adaptability?

Capability-based planning helps establish the connection between business strategy and technology investment. It enables leaders to identify which capabilities are strategically differentiating, which should be standardized, which can be sourced externally, and which are no longer worth maintaining. This creates a more rational basis for allocating scarce resources than simply funding projects according to organizational influence or historical precedent.

The fifth is the capability to build adaptive management systems. Even the most compelling strategy will struggle if the organization's management practices reinforce contradictory behavior. A company cannot realistically pursue agility while rewarding managers exclusively for adherence to fixed annual plans. It cannot encourage experimentation while treating every unsuccessful hypothesis as a failure of execution. Nor can it demand enterprise-wide collaboration while assessing performance entirely through isolated departmental objectives.

Management systems must therefore evolve alongside strategy. This means establishing clear decision rights, aligning incentives with enterprise outcomes, managing investment as a portfolio of strategic choices, and creating regular opportunities to reassess assumptions. Architecture governance should increasingly evaluate the consequences of decisions rather than merely enforce adherence to predetermined standards.

For example, architectural fitness functions and measurable technology health indicators can provide continuous evidence about resilience, security, interoperability, maintainability, and delivery performance. Value-stream analysis can reveal where organizational friction prevents strategic capabilities from emerging. Scenario planning can help leaders prepare for alternative futures rather than commit unquestioningly to one forecast. Portfolio reviews can examine whether an investment thesis remains valid and whether resources should be redirected, accelerated, or withdrawn.

These methods are not replacements for sound engineering, governance, or execution. They make those disciplines more strategically effective by connecting decisions to evidence and outcomes.

There is also a deeper managerial implication. Strategy must no longer be viewed as an episodic exercise performed by senior executives before being handed down for implementation. In environments characterized by technological disruption, changing customer expectations, regulatory uncertainty, and accelerating artificial intelligence adoption, strategic management must become a continuous organizational capability.

This does not mean changing direction whenever circumstances become uncomfortable. Constantly revisiting decisions without sufficient evidence creates confusion and undermines execution. The challenge is to develop the judgment to distinguish between temporary difficulty that warrants perseverance and new evidence that warrants reconsideration.

Effective management therefore requires two seemingly opposing qualities: commitment to strategic intent and intellectual flexibility about the means of achieving it.

The Enterprise Architect has an increasingly important role in reconciling these tensions. By maintaining a holistic understanding of business capabilities, information flows, technology dependencies, operating models, and investment trade-offs, architects can help leaders recognize when apparently sensible local decisions undermine broader strategic objectives. More importantly, they can make alternative choices visible before organizations become locked into expensive commitments.

The architect of the future should not merely ask whether a solution conforms to the target architecture. The more strategic questions are whether the target architecture still reflects the organization's competitive choices, whether its assumptions remain valid, and whether the proposed investment will strengthen the capabilities that genuinely matter.

This requires Enterprise Architects to become more than technical experts. They must develop commercial judgment, financial literacy, organizational awareness, systems thinking, and the ability to facilitate difficult strategic conversations. Their influence should arise not simply from architectural authority, but from their ability to improve the quality of enterprise decisions.

Ultimately, the greatest risk in technology strategy is not choosing an imperfect course of action. Every meaningful strategy is imperfect because it is formulated with incomplete information about an uncertain future. The greater risk is becoming so committed to our existing mental models, management routines, and carefully constructed plans that we lose the ability to recognize when they are no longer working.

An organization can have an impressive technology roadmap, a sophisticated enterprise architecture practice, and highly disciplined delivery teams while still moving confidently in the wrong direction. Excellence in execution cannot compensate for incoherence in strategy.

The question we should ask when outcomes disappoint is therefore not simply, "How can we execute our plan more effectively?" It is, "What assumptions led us to believe this plan would succeed, and what have we learned that should change our choices?"

That question may be uncomfortable. It challenges established authority, exposes uncertainty, and forces us to acknowledge that yesterday's successful methods may become tomorrow's constraints. Yet this discomfort is precisely what makes strategic thinking valuable.

The future of effective technology management will not be determined by who produces the most comprehensive plans, adopts the latest frameworks, or implements the largest number of technologies. It will belong to organizations that develop the ability to question their assumptions, make coherent choices, build differentiated capabilities, and continuously adapt their management systems as evidence emerges.

Technology strategy is not fundamentally about managing technology. It is about improving how an organization thinks, chooses, learns, and ultimately competes.

And sometimes, the most important strategic decision is not what we should do next, but what we must stop believing.

A Safe Place to Grow

Victor Leung — Mon, 26 Oct 2026 13:51:57 +0000

One day, I will become a father. Somewhere in the future, a little girl whom I have not yet met will enter my life and change it in ways I can barely imagine. I feel an extraordinary mixture of excitement, anticipation, responsibility, and quiet anxiety. I wonder what she will look like, whose smile she will inherit, and what kind of person she will eventually become. Yet, beneath all these questions lies one that occupies my thoughts more than any other: Will I be able to give her the emotional security she needs to grow into a confident, compassionate, and resilient human being?

I have spent much of my adult life believing in the power of learning, preparation, and continuous improvement. In my professional life, I am accustomed to examining complex systems, anticipating risks, and designing structures that can withstand uncertainty. But fatherhood presents a different kind of challenge. A child is not a system to be optimized, a project to be managed, or an outcome to be engineered. She is a human being who will arrive with her own temperament, emotions, curiosities, and dreams. Perhaps the most important lesson I must learn is that good parenting is not about designing the person my daughter should become, but creating the conditions in which she can safely discover who she is.

The more I read about developmental psychology, the more I realize that a child's earliest experiences can shape how she understands herself and the world. Long before she can speak, reason, or remember events consciously, she will already be learning whether the world is predictable, whether people can be trusted, and whether her needs matter. Psychological safety begins not with sophisticated educational methods or ambitious parenting plans, but with the simplest human experiences: being held when frightened, comforted when distressed, and welcomed when seeking connection. A baby does not need to understand the meaning of love intellectually. She needs to experience it repeatedly until security becomes something she can feel.

One of the most remarkable discoveries for me is the importance of physical touch. Research into skin-to-skin contact, sometimes called kangaroo care, shows how closeness can support an infant's physiological regulation and strengthen the bond between parent and child. I imagine holding my newborn daughter against my chest, allowing her to hear my heartbeat while I become familiar with the rhythm of her breathing. She will not understand my words, but perhaps she will gradually recognize my voice and associate my presence with warmth and comfort. In a world that often measures love through achievements and material provision, I am beginning to understand that some of its most powerful expressions require nothing more than time, patience, and physical presence.

I have also been learning practical ways to comfort a newborn. Pediatrician Harvey Karp popularized the five S's: swaddling, holding a baby on her side or stomach while soothing her, shushing, gentle swinging or rocking, and sucking. These approaches remind me that babies are adapting to an unfamiliar world after months of warmth and rhythmic movement in the womb. Of course, comfort must always be accompanied by safety: sleep belongs on the back, on a firm, flat, clear surface; side or stomach positioning is for supervised soothing while awake, never for sleep. Swaddling must stop when a baby shows signs of trying to roll. More importantly, I hope to develop the patience to understand what my daughter's cries may be communicating rather than interpreting them as inconveniences to eliminate.

As she grows, I want to remember that communication begins long before language. Developmental researchers describe a process called "serve and return," in which a baby offers a smile, sound, gesture, or expression, and an attentive caregiver responds. These exchanges help support the neural foundations of communication, emotional development, and social understanding. Something as ordinary as mirroring her smile, responding to her babbling, or looking into her eyes can become part of how she learns that her presence matters. At the same time, I must learn to recognize when she has had enough stimulation. If she looks away or becomes overwhelmed, my responsibility is not to entertain her endlessly, but to respect her need for rest.

I have begun to appreciate that attention is one of the purest forms of love a parent can offer. In an age when our attention is constantly fragmented by phones, notifications, work, and endless streams of information, genuine presence may become increasingly valuable. I want my daughter to grow up remembering a father who looked at her when she spoke, who listened without immediately reaching for a screen, and who made ordinary moments feel important. I hope to spend time walking with her, reading beside her, and talking about whatever captures her curiosity. Childhood may consist largely of seemingly insignificant moments, yet those moments gradually become the emotional memories of a lifetime.

Reading is another habit I hope to nurture from her earliest years. I have always believed that books expand our understanding of the world, but I am learning that reading to children is about much more than building vocabulary. A picture book can become an invitation to connect, explore, and imagine together. When she is an infant, I can read aloud, point to pictures, and let her become familiar with the sounds and rhythms of language. Later, when she begins to speak, I can engage her through the PEER approach: prompting her to describe something, evaluating and acknowledging her response, expanding her ideas, and inviting her to repeat or continue the conversation. Instead of treating reading as an academic obligation, I want books to represent warmth, discovery, and time spent together.

As my daughter begins exploring the world independently, I know that one of my greatest challenges will be resisting the temptation to intervene too quickly. Imagine her trying to pour water into a cup and accidentally spilling it across the table. My instinct might be to take over, prevent the mess, and complete the task efficiently. But what would she learn from that? Perhaps she would learn that mistakes are unacceptable, that adults do things better, or that her attempts are not worth the trouble. I would rather tell her that pouring water takes practice and ask whether she would like to try again. The spilled water can be cleaned up. The confidence lost through repeated discouragement may be harder to restore.

This brings me to the psychology of praise. Carol Dweck's research into motivation and growth mindsets has influenced how I think about learning. Rather than constantly praising children for being naturally intelligent or talented, I want to recognize their effort, strategies, persistence, and willingness to improve. If my daughter struggles with a difficult puzzle, I hope to acknowledge how she approaches the challenge instead of judging only whether she solves it. I want her to understand that ability can develop, that mistakes offer information, and that progress matters more than appearing perfect. Above all, I do not want her to believe that my affection increases when she succeeds or diminishes when she fails.

Perhaps this is where psychological safety becomes especially important. A child who feels secure should be able to admit uncertainty, ask questions, express disagreement, and acknowledge mistakes without fearing humiliation or rejection. I want my daughter to know that telling me the truth will never make her unworthy of love, even when her actions require correction. I hope our home becomes a place where difficult conversations are possible and where asking for help is understood as a sign of trust rather than weakness. I want her to feel safe enough to fail, courageous enough to try again, and secure enough to be herself.

Of course, emotional safety does not mean eliminating every frustration or giving her whatever she wants. Children need boundaries, consistency, and guidance to develop self-control and respect for others. The challenge is to remain both gentle and firm. When my daughter becomes upset because she cannot have something, I want to acknowledge her disappointment without necessarily changing the boundary. Her feelings can be valid even when her behavior is unacceptable. I can tell her that I understand she is angry, while still making it clear that hitting, hurting others, or acting dangerously is not permitted. The goal of discipline, after all, should be to teach rather than to punish, to develop judgment rather than demand unquestioning obedience.

One principle I find particularly meaningful is that children cannot always regulate emotions they have not yet learned to understand. When a toddler becomes overwhelmed, logical explanations and lectures often achieve very little. In those moments, the parent's emotional stability becomes an essential source of support. Instead of immediately demanding that my daughter calm down, I can first acknowledge what she feels, help her regain composure, and only then discuss what happened. Over time, she can learn to name emotions, practice calming strategies, and distinguish between feelings and actions. The ability to regulate emotions is not something a child simply acquires through instruction. It is learned partly through repeated experiences of being supported by someone who can remain calm.

This realization makes me slightly uncomfortable because it turns the responsibility back toward myself. I cannot reasonably expect my daughter to manage frustration if I respond to inconvenience with anger. I cannot teach patience through constant impatience, empathy through dismissal, or respect through intimidation. Children learn as much from observing how adults behave as from listening to what they say. The person I become in her presence may influence her more deeply than the advice I eventually give her. Fatherhood, therefore, is not merely the responsibility of raising a child. It is also an invitation to examine my own emotional habits, confront my weaknesses, and become more intentional about how I live.

I know that I will not always succeed. There will be nights when I am exhausted, moments when I become frustrated, and occasions when my judgment falls short of my intentions. I may speak too sharply or misunderstand what she needs. But perhaps psychological safety does not require a parent who never makes mistakes. It requires a parent who recognizes them, takes responsibility, and repairs the relationship. I want to be capable of saying, "Daddy was upset, and I should not have spoken to you that way. I am sorry." An apology does not diminish parental authority. It demonstrates that respect is mutual and that relationships can survive disagreement, imperfection, and repair.

I must also remember that every child arrives with a temperament that is partly her own. Some children are naturally cautious, others adventurous. Some need more time to adapt to change, while others seek constant novelty. I do not yet know whether my daughter will be quiet or expressive, sensitive or fearless, independent or deeply attached. Perhaps she will be all these things at different stages of her life. My responsibility is not to force her personality into a predetermined ideal, but to understand her individuality and adjust my parenting accordingly. If she is sensitive, I want to help her understand that sensitivity can coexist with strength. If she is cautious, I want to encourage courage without making her ashamed of fear.

As a father raising a daughter, I am particularly conscious of the expectations society may eventually place upon her. She may encounter pressure to be agreeable, attractive, accomplished, or constantly available to others. I hope to teach her that kindness does not require surrendering boundaries, confidence does not require perfection, and self-worth should never depend entirely on approval. I want her to have the freedom to pursue science, literature, art, technology, or whatever interests her, without believing that her identity must conform to someone else's expectations. More importantly, I hope she develops enough confidence to question assumptions, form independent judgments, and choose a life that reflects her own values.

Yet I must be careful not to transform these aspirations into another set of demands. There is a subtle danger in wanting to raise a resilient, confident, emotionally intelligent child: I might begin treating those qualities as achievements she owes me. She does not. My daughter is not responsible for validating my parenting philosophy or fulfilling the ambitions I have imagined for her. She may struggle, lose confidence, make questionable decisions, or follow a path I would not have chosen. My challenge will be to offer guidance without controlling her identity and to remain emotionally available even as her need for independence grows.

I am also learning that nurturing my daughter requires caring for the environment surrounding her, including my relationship with her mother and our own well-being. A secure home is not created by one endlessly self-sacrificing parent. It grows through cooperation, shared responsibility, mutual respect, and a willingness to ask for help when necessary. I hope we can show our daughter what a healthy relationship looks like, not because we never disagree, but because we handle differences with dignity. She will learn about love not only from how we treat her, but also from how we treat each other.

There is much discussion about the importance of sleep, routines, nutrition, cognitive stimulation, and early learning. All these matter, but I am beginning to see them as parts of a larger picture. Healthy development is not the product of maximizing every activity or reaching every milestone ahead of schedule. Children need adequate rest, opportunities to play, predictable rhythms, and freedom from unnecessary pressure. They need room to become bored, to explore without constant instruction, and to discover that not every moment must be productive. I hope I can resist the modern temptation to turn childhood into an endless program of optimization.

As I prepare for her arrival, I keep returning to a simple idea: I cannot promise to protect my daughter from every disappointment, but I can work to ensure that she never has to face life's difficulties feeling fundamentally alone. One day, someone may reject her friendship, she may fail an examination, lose something precious, or experience heartbreak. I will not always be able to solve those problems, nor should I. But I hope she will know that she can come home, speak openly, and find someone willing to listen before judging. My role is not to remove every obstacle from her path, but to provide a secure foundation from which she can develop the courage to navigate them.

Perhaps this is what becoming a father ultimately means: learning to love someone without trying to possess her future. At first, she will depend on me for almost everything. Gradually, she will learn to crawl, walk, speak, question, disagree, and make decisions of her own. Each milestone will be both a celebration and a small act of letting go. The success of parenting cannot be measured by how closely a child continues to follow her parents, but perhaps by how confidently she can eventually walk her own path, knowing that the relationship remains secure.

I still worry about whether I will be a good father. In fact, I suspect that uncertainty may accompany me throughout parenthood. There will never be a complete manual for understanding another human being, particularly one who is changing as rapidly as a child. But perhaps the answer is not to eliminate that uncertainty through endless preparation. It is to approach fatherhood with humility, curiosity, patience, and the willingness to keep learning. I do not need to know everything before she arrives. I need to be prepared to listen, adapt, and grow alongside her.

My dear daughter, you have not yet entered this world, and already you are teaching me something important. You are reminding me that the most meaningful things in life cannot always be measured, accelerated, or perfected. They must be cultivated through attention, trust, and countless ordinary acts of care. I do not know what kind of father I will become, but I know the kind I want to be: someone whose presence offers reassurance rather than fear, whose guidance encourages exploration rather than conformity, and whose love never becomes a reward that must be earned.

When you finally arrive, I may not have all the answers. I will probably be tired, uncertain, and learning more slowly than I would like. But I hope that, through all the imperfect days ahead, you will come to understand one simple truth: You do not need to be extraordinary to deserve my love. You do not need to succeed to make me proud of your existence. Before you take your first step, speak your first word, or accomplish anything at all, you are already enough.

And perhaps, if I can give you that sense of security, it will become the foundation from which you can build a life that is truly your own.

AI Agents in the Enterprise

Victor Leung — Sat, 24 Oct 2026 15:22:24 +0000

The most consequential change in enterprise AI begins when a system stops suggesting what someone should do and starts doing it on their behalf. A flawed answer can mislead a reader. A flawed action can alter a customer record, disclose confidential information, or create a commitment the enterprise must honour. Moving from assistance to agency changes the architecture of responsibility.

As an Enterprise Architect, I believe the strategic question is how much authority an organisation can delegate while retaining evidence that its systems are acting within that authority and producing worthwhile outcomes. Model capability matters. So do the boundaries around it, the quality of the information it receives, and the operational discipline that surrounds every release.

The adoption forecasts explain the urgency. In August 2025, Gartner predicted that 40% of enterprise applications would include task-specific AI agents by the end of 2026, compared with less than 5% at the time. That is a forecast, rather than confirmation that the transition has already happened. It nevertheless describes a substantial expansion in the software capable of acting for us.

Adoption and impact must be measured separately. McKinsey's 2025 survey found that 88% of respondents reported regular AI use in at least one business function. Around 6% met its definition of AI high performers: respondents attributing at least 5% EBIT impact and significant value to AI. These are different measures, not a conversion funnel proving that 94% of adopters failed. The same survey found 23% scaling an agentic system somewhere in their organisation and another 39% experimenting with agents. The opportunity is real; enterprise-wide impact remains a separate achievement.

Other research reinforces the need for discipline without establishing a universal failure rate. S&P Global Market Intelligence reported in May 2025 that 42% of companies abandoned the majority of their AI initiatives before production. RAND's 2024 research cited estimates of more than 80% of AI projects failing, rather than deriving that figure as a new representative failure-rate measurement. These findings concern broader AI projects and different populations. They should encourage scrutiny of delivery economics, rather than be combined into a dramatic but misleading statistic.

The distinction between copilots, agents, and digital workers is useful when it describes delegated work. A copilot supports a person who remains in control of the sequence. An agent can select and execute multiple steps towards a bounded goal. A system described as a digital worker may coordinate an entire workflow, but an accountable human owner must still carry responsibility for the outcome. These are design choices, not inevitable stages that every process should climb.

Greater autonomy is valuable only where adaptation improves the result. A predictable calculation may need ordinary software. A fixed sequence may need a workflow engine. An agent becomes useful where selecting the next action requires interpreting changing context. Nor does memory mean that an agent automatically learns safely from experience. Retaining a conversation, improving a model, and changing an approved operating policy are distinct activities with different assurance requirements.

The model is one component of the operating system around that decision. The agent harness supplies instructions, tool definitions, execution logic, context management, and controls. Its loop proposes an action, invokes an authorised tool, observes the result, and decides what comes next. The surrounding software must also determine when to stop, when to escalate, and how to recover from a partial failure.

This is where architecture becomes concrete. A system prompt can state that an agent must respect a transaction limit. Only an independently enforced permission or transaction check can reliably prevent the tool from exceeding it. Policy written in natural language is guidance; policy enforced at the action boundary is a control.

Every tool therefore represents delegated authority. Access should be scoped to the agent's identity, business purpose, permitted records, and approved operations. Short-lived credentials, explicit limits, and separation between proposing and executing consequential actions make that authority manageable. Delegating to another agent must preserve the original restrictions rather than create a route around them.

Risk cannot be inferred from a tool's name alone. Reading an account record may expose sensitive information. Searching documents may retrieve malicious instructions embedded in otherwise legitimate content. Creating an internal ticket may be reversible and routine, while sending a client communication may establish a commercial expectation. Code execution needs isolation and constrained network and filesystem access. The relevant questions concern sensitivity, consequence, reversibility, and scope.

For material transactions and external commitments, I would require human approval unless the organisation has explicitly authorised a narrow, tested form of automatic execution. The reviewer needs the proposed action, supporting evidence, affected parties, and meaningful alternatives. Approval must bind to that specific action and expire when relevant inputs change. A confirmation button that conceals the consequences creates little assurance.

The security evidence makes this practical rather than theoretical. IBM's 2025 Cost of a Data Breach announcement reported that 13% of organisations studied had experienced breaches of AI models or applications; 97% of that affected group reported lacking proper AI access controls. The denominator matters. The finding does not mean that 97% of all AI deployments were breached, but it highlights the danger of extending capability faster than access governance.

A second system must accompany the agent harness: an evaluation harness. The first enables action. The second provides evidence about whether the system performs acceptably under defined conditions. Neither a convincing demonstration nor a model benchmark establishes that an enterprise workflow is ready for production.

Evaluation should begin with representative tasks and explicit acceptance criteria. Test whether the agent completes the business objective, uses authorised information, chooses permitted tools, respects approval gates, and recognises when it lacks sufficient evidence. Include ambiguous requests, stale data, conflicting records, malicious retrieved instructions, unavailable dependencies, and repeated attempts at the same transaction. A failed request followed by a retry must not quietly create two payments or two orders.

Every prompt revision, model replacement, retrieval change, and tool update should face the relevant regression tests. Measure task success alongside unauthorised actions, unsupported claims, escalation quality, latency, and cost per successful outcome. An aggregate score can conceal a rare but serious failure, so critical scenarios need their own release thresholds. Automated graders can help, provided their judgements are calibrated against human review and objective checks.

Evaluation also continues after release. Controlled rollout, production sampling, incident analysis, and tested rollback procedures provide evidence that laboratory performance survives contact with real work. Record versions, retrieved evidence, tool requests and responses, policy decisions, and approvals, with appropriate redaction and retention. Auditors need an actionable execution record and a concise decision rationale; a generated explanation should never be mistaken for proof of the model's internal reasoning.

Data architecture deserves equal attention. Structured systems provide authoritative records. Documents and conversations explain institutional context. Live feeds provide timely signals. Calculation and execution tools allow the agent to verify quantities and act. Connecting these sources is useful only when the enterprise also defines their authority, freshness, ownership, and permitted uses.

Grounding reduces some unsupported outputs, but it does not eliminate hallucination. A system can retrieve the wrong document, misread a correct one, combine incompatible reporting dates, or draw an unjustified conclusion from accurate facts. Retrieved text must be treated as evidence rather than as instructions with authority over the agent. Persistent memory needs provenance, expiry, correction, and deletion controls so that yesterday's mistake does not become tomorrow's assumed fact.

Consider an agent supporting an investment operations exception. It may retrieve the trade record, compare settlement instructions, consult an approved procedure, and propose a resolution. That does not automatically authorise it to amend standing instructions or release a payment. If sources disagree, the appropriate outcome may be a well-supported escalation. Successful automation includes knowing when to stop.

Production readiness in this example means that the organisation can identify the source records and their timestamps, explain the proposed resolution, verify the approval, prevent duplicate execution, and reconcile the result with the system of record. A dashboard showing that the agent completed its loop is insufficient. The business outcome must be confirmed independently.

Scaling this capability requires an operating model. A centralised team can provide consistency when domain teams lack engineering capacity. Federation can work where domains have the skills and operational accountability to run their own systems. Neither organisation size nor the number of agents alone determines the right arrangement.

For a large enterprise with uneven capabilities, I favour a hybrid approach: common identity, policy enforcement, registries, telemetry, and evaluation standards, with domain ownership of workflows, data meaning, acceptance criteria, and business results. Application operations can remain central or move into capable domains. The division must be explicit: platform teams own shared infrastructure reliability; domain owners remain accountable for agent quality and the consequences of their business process. Cross-team incidents still need a single coordinator and a rehearsed escalation path.

Governance can develop through three practical moves: establish visibility, enforce controls, and maintain assurance as systems change. Visibility means an inventory connecting each agent to an owner, purpose, model version, data sources, tools, and deployment. Controls mean permissions, risk-based approval, budgets, execution limits, and a reliable suspension mechanism. Continuous assurance means those controls and evaluations remain effective as the environment evolves.

I would treat maturity as a planning aid. Initial pilots become an emerging capability when basic policies, budgets, and logging exist. A defined capability adds a complete inventory, accountable owners, and per-agent controls. Proactive governance embeds evaluation and cost gates into delivery and monitors production behaviour. Optimised governance connects assurance, economics, and outcomes over time. Even at that stage, changes to consequential policies require controlled approval; maturity should not imply that agents can rewrite their own limits.

The next step should address the most important missing capability. A team without an inventory needs visibility. A team with reliable logs but no regression tests needs evaluation. A team with technically successful agents but no demonstrated benefit needs to revisit workflow design and its business case. More agents are not evidence of greater maturity.

Leaders should judge the economics at the level of completed work. Include model usage, retrieval, tool calls, retries, human review, incident handling, and ongoing maintenance. Establish the existing process baseline and decide how released capacity will produce value. Faster processing matters when it improves service, reduces an actual expense, or enables useful work that previously went undone.

The Enterprise Architect's contribution is to connect that outcome to the capability being changed, the information required, the authority delegated, and the evidence needed to justify expansion. Begin with one bounded workflow. Give it an owner, an operational baseline, explicit permissions, an evaluation suite, and a recovery path. Expand its authority only when results support doing so.

The durable advantage will belong to organisations that can delegate responsibly and improve that delegation through evidence. Speed matters because opportunities do not wait. Judgement matters because automated mistakes also scale. Enterprise leadership must build the conditions in which both can coexist.

How Enterprises Turn Technology into Business Value

Victor Leung — Sat, 17 Oct 2026 08:00:35 +0000

Technology investment is easy to count. Business value is harder to establish.

An enterprise can move workloads to the cloud, launch digital channels, build a data platform, and deploy AI assistants while leaving its underlying economics largely unchanged. Delivery teams may meet their milestones, yet customers still encounter fragmented services and employees still reconcile conflicting information by hand.

As an Enterprise Architect, I see the central challenge as connecting technological possibility to the decisions that shape how the business works. A platform becomes valuable when someone uses it to change a customer outcome, a cost structure, a revenue stream, or an exposure to risk. That connection needs an owner and evidence.

My view is that sustained value depends on six connected disciplines: adapting the business model, choosing the operating model deliberately, concentrating on critical success factors, developing data monetization capabilities, clarifying governance, and investing in learning. Each strengthens the others. Treating them as separate programmes weakens the result.

1. Adapt the business model around customer outcomes

The first architectural question should be commercial: what outcome does the customer value, and how does the enterprise earn a return from delivering it?

Consider an equipment manufacturer. Selling machines creates one relationship with customers. Helping customers maintain reliable production creates another. The latter could combine equipment, maintenance, financing, telemetry, and specialist partners into an ongoing service. Technology enables the coordination, but the business model determines what is promised, who pays, and who bears the risk when performance falls short.

The distinction matters because digitizing an existing transaction and changing the basis of competition require different capabilities. A better ordering portal may improve convenience. A service priced around equipment availability requires reliable operational data, contractual clarity, partner coordination, and the ability to intervene before a failure.

AI agents extend this design space. An enterprise may move from recommending an action to executing it on a customer's behalf. That creates an opportunity to remove effort from the customer's life, alongside a responsibility to establish consent, limits, and recourse.

Some activities need structured execution: an agent follows an approved sequence, with explicit checks and escalation. Others allow adaptive execution: an agent explores alternative actions within defined constraints to reach a desired outcome. The architecture must reflect which kind of work is intended. Freedom to optimize a maintenance schedule does not imply freedom to change a customer's contract.

The strategic task is to decide which outcomes the enterprise can credibly own, which partners it needs, and whether the economics remain attractive after the full cost of delivery and accountability.

2. Make the operating model explicit

A compelling customer promise can fail when the enterprise cannot coordinate its own work.

Two choices deserve particular attention: how much information and activity business units must share, and how consistently they must perform their work. Integration and standardization are related, but they are different decisions. Units can share a customer identity while offering different services. They can also follow a common process while maintaining separate customer relationships.

Enterprise Architecture should make those choices visible. Which capabilities must be common? Where do local differences serve a customer or regulatory need? Where does variation merely duplicate cost?

Agentic AI makes ambiguity more consequential. Every agent implements assumptions about information access, decision authority, process rules, and coordination. If regional teams automate conflicting definitions of customer eligibility, faster execution can amplify the inconsistency.

Before scaling agents, leaders should agree on shared business definitions, ownership of process boundaries, and how conflicting actions will be resolved. Local autonomy can remain valuable, provided its limits are deliberate.

For the equipment manufacturer, this might mean a common asset identity and service history across regions, with local maintenance practices adapted to site conditions. The objective is enough coherence to deliver the enterprise promise while preserving useful differences.

3. Concentrate investment on critical success factors

A long list of technology use cases says little about strategic importance.

Critical success factors are the few conditions in which the enterprise must excel to achieve its objectives. For an equipment service business, these might include dependable uptime, profitable service delivery, and customer renewal. These priorities should shape where leaders invest attention and money.

The next step is to trace each factor to the decisions and workflows that influence it. If dependable uptime matters, fault detection, maintenance prioritization, spare-parts availability, and technician dispatch deserve examination together. Improving one activity while leaving the others constrained may produce little customer benefit.

This is where architects can connect strategy to delivery. Map the critical workflow, identify the limiting capability, and redesign the work around the complementary strengths of people and technology. AI may assist diagnosis; experienced engineers may retain authority over unusual or consequential interventions.

Define value before implementation. Establish the baseline, the expected improvement, the measurement period, and the accountable business owner. Include service quality and risk alongside speed and cost.

Time saved also needs a realization plan. If a tool releases employee capacity, will the enterprise serve more customers, reduce overtime, improve quality, or remove an expense? Without an operational decision, estimated productivity gains can remain spreadsheet benefits.

4. Build data capabilities that produce economic results

Data creates value through its use. Three useful routes are improving internal processes, enriching products and services with information, and offering information products that customers will pay for.

Our manufacturer could use service data to reduce unnecessary visits, provide customers with maintenance forecasts, or develop benchmarking services where permissions and confidentiality allow. Each route has a different customer, cost structure, and measure of success.

The architectural implication is that data platforms need a commercial and operational purpose. A dataset should have a responsible owner, understandable definitions, suitable quality, and clear conditions of access. Users also need to understand its limitations. A timely but incomplete maintenance record can lead to a different decision from a complete but outdated one.

AI adds another requirement: connecting information to permission to act. Access to a service record should not automatically authorize an agent to cancel a visit or order a replacement component. Data access and action authority need separate controls.

These capabilities require participation beyond specialist teams. Business employees must be able to interpret information, question recommendations, and recognize when a result is unsuitable for the decision at hand. Data monetization becomes an enterprise capability when people can use trusted information to change outcomes repeatedly.

5. Clarify decision rights and accountability

Governance creates value when it makes decisions timely, consistent, and accountable.

For each important technology decision, someone needs authority to decide, criteria for making the decision, and responsibility for its consequences. A committee without a clear decision owner can add delay while leaving accountability unresolved.

For AI agents, a practical starting point is to specify who may deploy them, which information and tools they may use, what actions they may take, when human approval is required, and who can suspend their operation. Monitoring should cover business outcomes, errors, unfair effects, and changes in behaviour.

The level of control should reflect the consequences of the action. An internal drafting assistant and an agent making contractual commitments warrant different approval and assurance arrangements. Common controls can make routine, lower-risk uses easier to deliver while directing scrutiny toward consequential decisions.

Architects can translate policy into enforceable mechanisms: bounded permissions, transaction limits, approval points, action records, and recovery procedures. Those mechanisms should be tested against plausible failures. If an agent books the wrong service, can the enterprise detect it, stop further bookings, and repair the customer impact?

Human accountability must remain clear even when execution is automated. A system's autonomy does not remove the enterprise's responsibility for the service it provides.

6. Treat learning and change as delivery work

A technology programme changes little if employees continue to work around it.

Training attendance and tool adoption offer useful signals, but they do not establish that the enterprise has developed a better way of working. Leaders need to understand whether people can make better decisions, handle exceptions, and deliver the intended customer outcome.

Learning should therefore be built into delivery. Use pilots to test assumptions, simulations to practise difficult situations, and feedback from real work to improve both systems and skills. Give employees time to learn and permission to surface weaknesses in the new process.

For the manufacturer, technicians might rehearse cases where an AI diagnosis conflicts with physical evidence. Service managers could practise resolving competing priorities across customers. Those exercises test the operating model and escalation paths as well as individual competence.

Maturity should be demonstrated through repeatable performance. Before expanding a solution, establish whether it works under realistic conditions, whether people understand their responsibilities, and whether the benefits persist after initial support is reduced. Expansion is then a decision supported by evidence.

The architect's contribution: make value traceable

These six disciplines form a connected set of choices. The business model defines the promise. The operating model establishes how the enterprise delivers it. Critical success factors focus investment. Data supports decisions and services. Governance assigns authority and accountability. Learning enables the organization to improve its performance.

Enterprise Architecture can keep those connections intact as individual programmes compete for resources and optimize their own deliverables.

For every significant investment, I would expect a clear account of the customer or business outcome, the capability and workflow that must change, the information and decisions involved, the accountable owner, and the evidence that will justify further investment. When one of those links is missing, the architecture discussion should bring it into view.

The practical starting point is one important outcome. Establish its baseline, find the constraint that prevents better performance, and redesign the work across organizational boundaries. Measure the result, learn from it, and expand what proves effective.

Technology leadership earns its strategic role by helping the enterprise make these choices and carry them through. The measure of success is a business that can deliver a more valuable promise, reliably and profitably, and adapt that promise as customer needs change.

Learning How to Learn

Victor Leung — Thu, 08 Oct 2026 14:56:37 +0000

We live in a world that celebrates knowledge, yet rarely questions how knowledge is acquired. From childhood, we are taught to accumulate information, memorize facts, pass examinations, and demonstrate competence. As professionals, we continue this pattern by attending training courses, collecting certifications, reading books, and mastering new technologies. We often measure our intellectual progress by how much we know rather than how effectively we learn. Yet there is a fundamental difference between acquiring knowledge and developing the capacity to learn. The former expands what we know today; the latter determines how well we can navigate what we do not yet know tomorrow.

The most valuable intellectual advantage is not necessarily intelligence, experience, or even expertise. It is the ability to understand and improve our own thinking. Psychologists call this metacognition, often described as thinking about thinking. It is our capacity to observe how we learn, recognize the limitations of our understanding, evaluate our assumptions, and consciously choose better approaches to solving problems. If ordinary cognition represents the musicians in an orchestra, metacognition is the conductor. Each musician may possess exceptional technical ability, but without coordination, reflection, and direction, the orchestra cannot produce its best performance. Similarly, possessing knowledge is insufficient if we cannot recognize when to apply it, question its relevance, or adapt our thinking when circumstances change.

Metacognition begins with a deceptively simple realization: our thoughts are not always reliable representations of reality. We naturally gravitate toward information that confirms what we already believe, prefer familiar solutions, and mistake confidence for competence. The more experienced we become, the easier it is to confuse accumulated knowledge with sound judgment. Expertise can therefore become a paradox. It equips us to solve familiar problems efficiently, yet sometimes makes us less willing to recognize unfamiliar ones. Learning effectively requires intellectual humility, the willingness to acknowledge that what worked yesterday may no longer work tomorrow.

This is particularly relevant in professional environments where knowledge evolves rapidly. A technology leader who has successfully delivered complex systems may instinctively approach every new challenge through familiar architectural patterns. A business executive may interpret emerging market dynamics through strategies that once produced exceptional results. These experiences are valuable, but they can also create cognitive blind spots. The most effective professionals are not those who defend their existing mental models most vigorously. They are those who continually examine whether those models remain useful. Experience should provide a foundation for judgment, not become a prison for imagination.

One of the greatest obstacles to effective learning is our relationship with difficulty. Most of us have been conditioned to associate understanding with ease and confusion with failure. When an explanation feels straightforward, we assume we have learned. When a problem requires prolonged effort, we begin to doubt our ability. Yet the subjective experience of learning can be misleading. Research into productive struggle suggests that attempting to solve certain problems before receiving an explanation can produce deeper understanding, even when learners initially feel less confident about their progress. The discomfort of confronting uncertainty can be part of the process through which meaningful knowledge is constructed.

This challenges a deeply embedded assumption about education and professional development. We often design learning experiences to minimize frustration, presenting polished explanations, worked examples, and immediately accessible solutions. Although guidance is essential, excessive convenience can deprive learners of opportunities to develop independent reasoning. When someone explains a solution, we may recognize the logic and mistake recognition for mastery. Genuine understanding becomes visible when we must reconstruct the reasoning ourselves, apply the principle in an unfamiliar context, or explain why an alternative approach would fail. Learning is not simply the transfer of an answer from one mind to another. It is the development of the intellectual structures required to discover answers independently.

Carol Dweck's research on growth mindset offers another important perspective. A fixed mindset treats ability as a relatively permanent characteristic, encouraging people to interpret difficulty as evidence of personal limitation. A growth mindset recognizes that abilities can develop through effective strategies, appropriate support, practice, and feedback. The distinction is not merely motivational. It changes the meaning we assign to failure. Instead of treating mistakes as judgments about our intelligence, we can regard them as information about the gap between our current understanding and the demands of a problem. However, embracing a growth mindset should not be confused with celebrating effort indiscriminately. Persistence without reflection can reinforce ineffective methods. What matters is the ability to connect effort with feedback, strategy, and continuous adjustment.

Anders Ericsson's work on expert performance reinforces this distinction. Excellence is not simply the consequence of spending more hours on an activity. Improvement requires purposeful practice, attention to weaknesses, feedback, and repeated refinement. Repetition can strengthen competence, but it can also reinforce mistakes when performed without reflection. A professional who has repeated the same approach for ten years may possess ten years of experience, or merely one year of experience repeated ten times. The difference lies in whether experience has been converted into learning. Without deliberate reflection, time alone does not guarantee wisdom.

This is why self-reflection must become an active discipline rather than an occasional exercise. After completing a project, solving a problem, or learning a new concept, we should examine not only the outcome but also the process that produced it. What did I initially believe? Which assumptions proved inaccurate? What information did I overlook? Which strategies worked, and why? At what point did my understanding change? What would I do differently if I encountered the same situation again? These questions transform experience into structured feedback. They allow us to identify patterns in our thinking and gradually improve how we approach unfamiliar challenges.

Reflection also helps us recognize the difference between being busy and making progress. We may spend hours reading technical documentation, attending seminars, or consuming educational content while developing only a superficial understanding. The quantity of information consumed is not the same as the quality of learning achieved. A more meaningful measure is whether we can retrieve the knowledge without assistance, connect it to existing concepts, explain it clearly, and apply it to solve new problems. If we cannot explain an idea in our own words, perhaps we have not understood it as deeply as we imagine. If we cannot transfer a principle beyond the example in which we encountered it, perhaps we have memorized a solution rather than learned a concept.

Effective learning therefore requires intentional engagement. Before studying a subject, we should identify what we already know, what remains uncertain, and why the new knowledge matters. During learning, we should actively question explanations, test our understanding, consider alternative interpretations, and seek connections with previously acquired knowledge. Afterward, we should attempt to reconstruct the central ideas from memory and apply them in different situations. When gaps appear, we should treat them as opportunities to adjust our strategy rather than as reasons for discouragement. This cycle of planning, monitoring, evaluating, and refining is the practical essence of metacognition.

Equally important is recognizing that not everything deserves equal attention. Modern education and professional life frequently suffer from an obsession with completeness. We attempt to cover every topic, master every framework, and absorb every available piece of information. Yet breadth without depth often produces the illusion of expertise. Foundational concepts serve as intellectual anchors, allowing us to organize unfamiliar information into meaningful structures. Someone who deeply understands the principles of distributed systems can reason about unfamiliar technologies more effectively than someone who has memorized the features of dozens of products without understanding their underlying design. The same principle applies to economics, leadership, strategy, mathematics, and virtually every other discipline. When we master the essential ideas, learning additional details becomes easier because new information has somewhere meaningful to belong.

The ability to distinguish essential principles from peripheral details is itself a higher-order learning skill. It demands that we ask what truly matters, identify the relationships between concepts, and resist the temptation to confuse comprehensiveness with understanding. In a world where information is increasingly abundant and instantly accessible, the scarcity is no longer information itself. It is the judgment required to determine which information matters, how it connects, and when it should influence our decisions. Learning effectively is therefore as much about intellectual selection as intellectual accumulation.

There is also a social dimension to metacognition that deserves greater attention. Thinking effectively does not mean thinking independently of others. Our perspectives are necessarily incomplete, shaped by personal experiences, assumptions, and cognitive biases. Engaging with people who see problems differently allows us to discover the limitations of our own reasoning. Listening carefully, explaining our thought processes, questioning assumptions respectfully, and considering alternative solutions are not merely communication techniques. They are mechanisms through which individual understanding becomes more sophisticated. Curiosity allows us to learn from disagreement instead of interpreting it as a threat.

Consider a classroom in which the teacher deliberately steps away from the center of attention and encourages students to discuss different approaches to a mathematical problem. Rather than immediately identifying the correct answer, students are invited to explain their reasoning, question one another, investigate mistakes, and compare alternative strategies. The objective is no longer simply to obtain the right answer. It is to understand how answers are constructed, why certain methods work, and what can be learned when they do not. This principle extends far beyond education. In organizations, leaders who encourage thoughtful disagreement and constructive examination of mistakes create opportunities for collective learning that are unlikely to emerge in environments where authority is expected to possess every answer.

For leaders, this represents an important shift in responsibility. Traditional leadership often rewards certainty, decisiveness, and the appearance of expertise. Yet complex environments demand the capacity to learn collectively, especially when existing knowledge is incomplete. A leader who responds defensively to unfamiliar perspectives may unintentionally discourage the very information needed to make better decisions. By contrast, a leader who openly examines assumptions, acknowledges uncertainty, invites challenge, and reflects on unsuccessful decisions creates conditions in which others can do the same. Intellectual humility is not a weakness of leadership. It is an essential foundation for organizational adaptability.

The emergence of artificial intelligence makes this distinction even more consequential. We increasingly have access to systems capable of generating explanations, synthesizing information, writing code, and proposing solutions within seconds. These capabilities can dramatically accelerate learning, but they also introduce a new temptation: outsourcing the process of thinking itself. When answers become effortless to obtain, we may become less inclined to investigate the reasoning behind them. The danger is not that technology makes knowledge accessible. It is that convenience may encourage us to mistake access to knowledge for possession of understanding.

The more capable our tools become, the more important it is to develop the judgment required to use them well. We must learn to formulate meaningful questions, evaluate the reliability of responses, identify hidden assumptions, recognize uncertainty, and verify conclusions against reality. Artificial intelligence can serve as a tutor, a collaborator, or a source of intellectual challenge. But it should not automatically replace the productive struggle through which deeper understanding develops. Used thoughtfully, technology can strengthen our capacity to learn. Used passively, it risks making us dependent on answers we cannot independently assess.

I believe this is one of the defining challenges of lifelong learning. The objective should not be to accumulate an ever-expanding collection of facts, qualifications, and experiences. It should be to develop a mind capable of continuously renewing itself. This requires balancing confidence with humility, persistence with flexibility, and curiosity with disciplined judgment. It means becoming comfortable with the possibility that our understanding is incomplete, while remaining committed to improving it. It also means recognizing that unlearning outdated assumptions can sometimes be more valuable than acquiring additional information.

Perhaps the most important lesson is that learning should not be viewed as a temporary activity that prepares us for life. Learning is an integral part of living well. Every challenging conversation, unexpected setback, unfamiliar responsibility, or failed experiment offers an opportunity to refine our understanding of ourselves and the world. What distinguishes those who grow from those who remain stagnant is not the absence of difficulty, but the meaning they assign to it and the actions they take afterward.

The ultimate purpose of learning is not to reach a point where we no longer encounter problems we cannot solve. Such a destination does not exist. Instead, it is to develop the confidence, curiosity, and intellectual discipline to approach the unknown without being defeated by uncertainty. Knowledge may help us answer the questions of today, but metacognition prepares us to confront the questions of tomorrow.

In the end, learning how to learn is more than an educational technique or a professional advantage. It is a philosophy of intellectual growth. The moment we stop defining ourselves by what we already know and begin measuring ourselves by our capacity to understand what we do not, learning ceases to be a test of our limitations and becomes an exploration of our possibilities.

The greatest learners are not those who always know the answers. They are those who never lose the willingness to question, reflect, and begin again.

From the Day You Are Old Enough to Read This

Victor Leung — Tue, 06 Oct 2026 13:55:22 +0000

My dear future child,

I am writing this before I know who you will become.

I do not yet know the sound of your voice, the things that will make you laugh, or the dreams you will one day carry quietly inside you. I do not know what you will be good at, what will frighten you, whom you will love, or where life will eventually take you.

Perhaps that is one of the strangest and most beautiful things about becoming a father. You can love someone before you have truly met them.

One day, many years from now, you may find these words. By then, you may already be old enough to see me not simply as your father, but as another human being who was trying to understand life while living it.

You will probably have discovered some of my flaws by then. I will have worried when I should have trusted you, spoken when I should have listened, and tried to protect you from experiences that perhaps you needed to have for yourself.

Parents often wish they could give their children the lessons without giving them the pain that produced those lessons. Life rarely works that way.

So this is not a rulebook.

I do not want you to live the life I would have chosen for you. I want you to have the wisdom and courage to choose a life that is genuinely your own.

Think of these words simply as a few things I learned along the road. Carry whatever proves useful. Leave behind whatever does not.

Perhaps, many years from now, you will add lessons of your own.

The first thing I hope you learn is that some of the best investments you will ever make cannot be measured by the balance of an account.

Invest in your body while it is healthy, not only when it begins to hurt. Move often, sleep enough, eat sensibly, and remember that health can feel ordinary until the day it no longer is.

Take care of your mind with the same seriousness.

There is no courage in suffering unnecessarily simply because you are afraid to ask for help. If life becomes too heavy, speak to someone. Strength is not the absence of vulnerability; sometimes strength is recognizing that you do not need to carry everything alone.

Invest in your education too, but never confuse education with qualifications.

Degrees may open doors, but curiosity will carry you much farther. Read things that challenge you. Learn subjects that have nothing to do with your profession. Remain interested in the world long after examinations have ended.

Find mentors when you are young.

A good mentor can sometimes see the person you might become before you can see that person yourself. Listen carefully to those who have travelled farther than you, but never surrender your judgment to them.

Then, when you become experienced enough, turn around.

Someone will eventually be standing where you once stood, uncertain and trying to find a path forward. Be generous with what life has taught you.

Knowledge becomes more valuable when it is passed on.

There is another investment I hope you learn to make, and that is the investment of attention.

Attention may become one of the scarcest things in your life.

The world will constantly ask for it. Screens will ask for it. Work will ask for it. Advertisements, messages, ambitions, worries, and other people's opinions will all compete for a small piece of your consciousness.

Be careful about what you give your attention to, because what receives your attention eventually receives your life.

You may discover that human beings possess an unfortunate talent for becoming accustomed to wonderful things.

The new home becomes simply home. The promotion becomes another job. The object you once dreamed about becomes something sitting forgotten in a drawer. Even extraordinary circumstances eventually become ordinary when we live inside them for long enough.

This is why more is such a dangerous word.

There is always more.

More money. More recognition. More possessions. More achievement. More countries to visit. More restaurants to try. More things to place on a shelf so that other people might conclude that life has been kind to you.

Ambition itself is not the problem.

I hope you are ambitious. I hope you attempt things that frighten you a little. I hope you discover how much you can build, learn, explore, and contribute during the relatively short time you are here.

But ambition must learn to live beside gratitude.

Without gratitude, ambition becomes hunger without digestion. No achievement remains satisfying for very long because the mind immediately begins searching for the next one.

You arrive at the place you once dreamed about and discover another mountain behind it.

If happiness is always waiting at the summit of the next mountain, you may spend your entire life climbing without ever noticing the view.

So learn to notice.

Notice the people sitting around the table.

Notice your mother's laughter. Notice the sound of rain when you have nowhere you need to go. Notice conversations with old friends that continue long after dinner should have ended.

Notice ordinary afternoons.

We often imagine that the great moments of life will announce themselves. Sometimes they do. Weddings, births, graduations and departures clearly tell us that something important is happening.

But much of life disappears without ceremony.

One day you may look back and realize that an ordinary Sunday afternoon was one of the happiest periods of your life. Nothing spectacular happened, which is precisely why you failed to recognize it at the time.

Learn therefore to be present before memory teaches you the value of what you had.

Do not consume every pleasure until pleasure itself becomes dull.

You do not need the finest meal every evening. You do not need to buy something whenever desire appears. You do not need to transform every inconvenience into comfort.

Sometimes anticipation is part of enjoyment.

Something saved for can mean more than something immediately acquired. A journey becomes special partly because you do not make it every week. A celebration becomes memorable partly because ordinary days surround it.

Enough is one of the most difficult words to understand.

The world has built enormous industries around convincing you that you have not reached it.

There will always be a better phone, a larger house, a newer car, a more exclusive restaurant, and some object whose advertisements quietly suggest that ownership will transform you into a more complete human being.

Enjoy beautiful things if you can afford them.

I certainly do.

But never ask possessions to perform the work of identity.

They are not strong enough.

A watch can tell you the time, but it cannot tell you whether you have spent that time well. A large home can shelter many people, but it cannot guarantee that the people inside it love one another.

Build your life around people instead.

Call your family while you still can.

Stay in touch with the friends who knew you before your achievements gave strangers reasons to pay attention to you. Sit beside people during difficult seasons even when you have no useful advice to offer.

Sometimes presence is the advice.

Celebrate other people's success without turning their lives into measurements of your own.

Envy quietly transforms another person's happiness into evidence of your failure. Resist it.

Someone else's light does not make yours dimmer.

Eventually you will understand something that is difficult to appreciate when you are young: possessions rarely carry us through the hardest parts of life.

People do.

Another lesson took me time to understand: never become too proud to say, “I don't know.”

You may spend years becoming knowledgeable in your field. People may begin asking for your opinion. Eventually you may sit in important rooms surrounded by people who assume that everyone present knows what they are talking about.

Be careful.

Status can make ignorance harder to admit.

The more respected you become, the greater the temptation to defend your image instead of examining your understanding.

Whenever you think you understand something, try explaining it simply.

If you cannot explain an idea without hiding behind jargon, there is a chance that you have memorized its language without understanding its meaning.

Teach what you know.

Let other people question you. Pay attention to the places where your explanation becomes uncomfortable. Those are often the borders of your knowledge.

Return there.

Study again.

True expertise should make you clearer, not more mysterious.

You should also become comfortable changing your mind.

You will be wrong many times in your life. I certainly have been.

There is no shame in that.

Reality is larger than your opinions, and wisdom requires us to allow new evidence to rearrange old beliefs.

Do not remain loyal to a mistake merely because an earlier version of you made it confidently.

The goal is not to win every argument.

The goal is to leave the conversation understanding the world slightly better than when you entered it.

You will also hear many people speak about wealth.

Listen carefully, but decide for yourself what the word means.

Money matters more than idealistic people sometimes admit. A lack of money can narrow choices, create anxiety, and turn small problems into enormous ones.

Learn how money works.

Learn to earn it honestly, save it consistently, invest it patiently, and spend it deliberately. Understand debt before accepting it. Understand compounding before wasting time.

But do not worship the instrument.

Money is useful because of what it can make possible.

The greatest luxury it may eventually buy you is not a car, a house, or something with a famous name printed on it.

It is freedom.

Freedom to say no.

Freedom to leave an environment that requires you to betray your values. Freedom to help your family when they need you. Freedom to choose meaningful work over desperate work.

Freedom to rest.

Freedom to begin again.

Freedom to spend Tuesday afternoon with someone you love because you do not need every waking hour to produce income.

When thinking about money, therefore, ask yourself not only, “Will this make me richer?”

Ask, “Will this make me freer?”

Sometimes the answer will be the same.

Sometimes it will not.

Your career will occupy an enormous portion of your life, so choose your work thoughtfully.

Look for places where people are treated with dignity. Look for leaders who care not only about what you can produce for them, but about the person you might become.

Look for purpose.

But do not expect every working day to feel meaningful.

Meaningful work still contains boring meetings, difficult personalities, failed projects, administrative tasks, uncertainty, and mornings when you would rather remain in bed.

Purpose is not constant inspiration.

Purpose is knowing why something remains worth doing even when inspiration is absent.

Try to leave whatever you touch a little better than you found it.

Build things that continue to be useful when you are gone. Teach people enough that they no longer need you. Give credit freely.

Do not spend your career making yourself indispensable.

Spend it making yourself useful.

Titles will come and go.

One day, someone else will sit at your desk, inherit your responsibilities, and perhaps accomplish them better than you did.

This is not a tragedy.

The position was never you.

Your character is the part you carry home.

Do not confuse professional success with a successful life.

There are people with extraordinary careers who arrive home as strangers to their families. There are people admired by thousands who cannot sit comfortably alone with themselves.

Achievement can decorate a life.

It cannot substitute for one.

Be especially careful with comparison.

You will live in a world that gives you unprecedented access to other people's lives, or at least the parts they choose to display.

You will see their promotions, holidays, weddings, homes, celebrations and triumphs. You will rarely see their loneliness, arguments, debts, doubts, disappointments or sleepless nights.

Never compare the unedited version of your life with the edited version of somebody else's.

It is a competition designed to make everyone lose.

There will always be someone richer than you.

There will always be someone more accomplished, more attractive, more popular, younger, faster, or apparently happier.

If your peace requires being ahead of everyone else, peace will never arrive.

Compare yourself instead with the person you used to be.

Are you wiser than you were five years ago?

Kinder?

More courageous?

More patient?

More capable of admitting when you are wrong?

Those questions may tell you much more about the direction of your life.

Try to own a little less than you can afford.

You may discover that every possession asks for something in return. It needs space, attention, maintenance, protection, or simply another small piece of your mind.

Simplicity is not deprivation.

Sometimes it is freedom from having to think about things that were never important.

Give more too.

Not because generosity guarantees some reward from the universe, but because it keeps your world larger than yourself.

Help people who cannot repay you.

Do useful things that nobody will know you did.

There is a particular kind of freedom that comes from no longer needing every good action to become part of your reputation.

And please remember that you do not need to become extraordinary for me to be proud of you.

I will naturally dream about your future. Parents cannot help imagining possibilities for their children.

Perhaps you will build companies, write books, discover something, lead people, travel widely, or become exceptional in a field I know nothing about.

Perhaps you will not.

Perhaps you will prefer a quiet life.

There is dignity in that too.

The world may encourage you to turn your existence into a performance, as though a life only matters when enough people witness it.

Do not believe that.

A quiet life can be a magnificent life.

If you become a CEO, I will love you.

If you become a teacher, I will love you.

If you become an artist, engineer, doctor, carpenter, researcher, parent, entrepreneur, or something that does not yet have a name, I will love you.

And if you change direction halfway through, I will still love you.

Your life was never meant to justify mine.

You do not owe me achievements in exchange for being loved.

What matters far more is who you become when nobody is watching.

Be dependable.

Keep promises carefully, especially the small ones.

Treat the cleaner with the same respect you show the chief executive. People reveal themselves most clearly through how they behave toward those from whom they need nothing.

Apologize when you are wrong.

Forgive when forgiveness is possible, but learn that forgiveness does not always require allowing someone back into your life.

Have boundaries.

Kindness without boundaries eventually becomes permission for other people to misuse your kindness.

Know when to leave.

There will be relationships, jobs, ambitions and even versions of yourself that once served you but no longer do.

Leaving is not always failure.

Sometimes staying requires a greater betrayal.

Have the courage to begin again.

You may have to do this more than once.

Most lives are not straight lines. They are revisions.

Do not be embarrassed by that.

Perhaps the deepest lesson I can offer you is also the simplest.

Love people while they are here.

Do not postpone every conversation.

Do not assume there will always be another Christmas, another dinner, another journey, another chance to ask the question you kept meaning to ask.

Time rarely announces what it is taking from us.

One day you may become a parent yourself.

If that happens, perhaps you will understand why I wrote this.

You will look at someone impossibly small and realize that you would like to protect them from every disappointment the world contains.

Then you may slowly understand that this is neither possible nor desirable.

A parent's job is not to clear every stone from the road.

It is to help a child become strong enough to walk across difficult ground without losing tenderness.

I cannot live your life for you.

I should not.

There will be mistakes you must make personally before their lessons become yours. There will be heartbreaks that my advice cannot prevent, questions I cannot answer, and crossroads at which you will have to decide without knowing where either road leads.

I hope I give you roots strong enough to know where you came from.

I hope I give you wings strong enough that you do not need to stay there.

And I hope that when my beliefs no longer fit the world you inhabit, you will have enough courage to improve upon them.

Every generation should travel a little farther than the generation before it.

So question these words.

Add to them.

Correct them.

Then go and live.

Build a life rich in people rather than possessions, curiosity rather than certainty, purpose rather than status, and freedom rather than appearances.

Earn enough to have choices.

Learn enough to understand how much remains unknown.

Work hard, but remember why you are working.

Travel if the world calls you.

Come home when someone you love needs you.

Take care of your body before illness teaches you its value.

Take care of your mind before exhaustion teaches you its limits.

Buy beautiful things if they genuinely make life better, but never allow what you own to become the measure of who you are.

And when life is good, notice.

That last lesson may be among the most important.

When life is good, we often assume it will remain that way. We hurry through peaceful seasons in pursuit of something more exciting, only to look back later and understand how precious those uneventful years really were.

So look around occasionally.

There may be a day when nothing remarkable happens. You wake beside someone you love. Everyone you care about is healthy. You eat dinner together. The phone does not ring with bad news.

Do not call that an ordinary day.

Call it a fortunate one.

A good life is not waiting somewhere in the future after you have earned enough, achieved enough, learned enough, or finally become the person you think you are supposed to be.

The future keeps moving.

Life is what is happening while you prepare for it.

And wherever you eventually go, whatever you accomplish, however many times you fail and begin again, I hope there is one thing you never have to wonder about.

Long before I knew what you would become, I loved you.

Not because of what you might achieve.

Not because of the name you might make for yourself.

Simply because you were you.

And that was always enough.

Best Regards,
Your Dad

How to Handle Anger

Victor Leung — Mon, 05 Oct 2026 12:19:50 +0000

Anger rarely asks for permission. A careless remark, a disrespectful colleague, an unreasonable demand, or a stranger who behaves as though no one else exists can alter our internal state in a matter of seconds. The event itself may be brief, but the mind is remarkably skilled at extending its life. We replay the conversation, reconstruct the tone, imagine what we should have said, and continue arguing long after the other person has moved on. What lasted a moment in reality can occupy hours in the mind.

This is one of the strangest qualities of anger: reality often ends before the emotion does. Someone may have caused the first wound, but everything that happens afterward increasingly becomes our responsibility. The first reaction may be instinctive. We may not be able to prevent the flash of irritation, disappointment, or rage. Yet what comes next is different. The moment we become aware of the feeling, a small space begins to open between emotion and action. That space may initially be narrow, but it is where our freedom lives.

To handle anger well is therefore not to become emotionless. It is not to suppress irritation, deny pain, or pretend that nothing matters. It is to develop enough awareness that emotion no longer decides our behaviour automatically. Anger may arrive, but it does not have to become the owner of the house. It can be acknowledged, understood, and eventually asked to leave.

One of the simplest ideas I have learned is also one of the hardest to practise: the past is already the past. Intellectually, this is obvious. Emotionally, it is difficult. The mind resists the finality of what has happened because anger feeds on repetition. It wants another hearing, another argument, another imaginary victory. We tell ourselves that we are analysing the situation, but sometimes we are merely replaying pain. Yesterday cannot be corrected by suffering through it again today.

A useful question in such moments is: is there anything meaningful left for me to do? If there is, then the anger may still contain useful information. Perhaps a misunderstanding needs to be clarified, a boundary needs to be established, an apology needs to be requested, or a difficult conversation must take place. In those cases, action is appropriate. But if there is nothing more to be done, continuing to relive the event no longer serves a purpose. At that point, anger begins to charge us emotional interest on a debt that has already been paid.

Sometimes the most effective response is not philosophical at all. It is physical. Walk. Exercise. Take a shower. Leave the room. Sleep before replying. Allow the body to settle before asking the mind to make an important decision. We often assume that emotional problems require intellectual solutions, yet the mind is not separate from the body. A tired, stressed, overstimulated nervous system can turn a small inconvenience into a personal crisis. Sometimes wisdom begins with movement, silence, or rest.

This is also where I have learned to distinguish between suppression and letting go. Suppression says, “Nothing happened,” even though resentment remains beneath the surface. Letting go says, “It happened, I understand what I can learn from it, and I will not carry it further than necessary.” Suppression hides the wound. Letting go closes it.

Much of anger also begins with a hidden word: should. People should behave differently. My colleague should understand. My manager should appreciate the effort. My family should know how I feel. The organisation should make the rational decision. Life should be fair. There is nothing wrong with preferences or standards, but trouble begins when preference quietly transforms into entitlement. “I would like things to happen this way” becomes “things must happen this way,” and when reality refuses to cooperate, frustration follows.

This has made me increasingly interested in the expectations that sit beneath anger. Whenever I feel myself becoming irritated, I try to ask: what expectation of mine has just been violated? Very often, the emotional intensity does not come only from what happened. It comes from the gap between reality and the version of reality I had already constructed in my mind. The greater the attachment to that expectation, the stronger the anger when the world ignores it.

In professional life, this can be especially subtle. The more effort we invest in an idea, the easier it becomes to identify ourselves with it. We analyse the problem, design the architecture, test the assumptions, and eventually form a recommendation. Then someone disagrees. Logically, this is simply part of decision-making. Emotionally, however, the rejection can feel strangely personal because somewhere along the way, the idea stopped being merely an idea and became ours.

That is a dangerous moment. The objective was never supposed to be proving that I am right. The objective was improving the decision. There is strength in defending a well-reasoned position, but there is even greater strength in being able to separate conviction from ego. We should be willing to argue strongly when evidence supports us, but equally willing to change our minds when better evidence appears. A mature mind does not confuse being challenged with being diminished.

When emotions become intense, I have found it useful to strip the situation back to facts. Not interpretations, not imagined motives, not the story about what the event “means,” but the facts themselves. The proposal was rejected. The deadline moved. Someone criticised the work. A colleague failed to respond. A person behaved badly. The plan did not work. These facts may still be unpleasant, but facts are usually quieter than the stories we build around them.

Once the facts are visible, a more useful question emerges: what is the next constructive move? I increasingly like this way of thinking because it changes the emotional posture completely. Instead of asking, “Why is this happening to me?” the mind begins asking, “What can I do from here?” The first question often deepens helplessness. The second restores agency.

Life resembles a game in this sense. A game presents conditions. Some are favourable, others are not. Obstacles appear, rules change, and other players behave unpredictably. Complaining about the existence of the obstacle does not move the game forward. We observe the environment and decide on the next move. If the road is blocked, we wait or choose another route. If a conversation becomes pointless, we end it. If someone repeatedly crosses a boundary, we strengthen the boundary. If criticism contains useful information, we absorb it. If it contains nothing useful, we leave it where it came from. If a mistake can be corrected, we correct it. If it cannot, we convert it into experience.

This perspective has also changed the way I think about responsibility. People who care deeply about their work often expand responsibility far beyond what they actually control. We begin carrying the expectations of the team, the disappointment of the manager, the uncertainty of the organisation, the success of the project, and the emotions of everyone involved. Eventually, responsibility becomes limitless, and frustration follows because reality refuses to fit inside our sphere of control.

There is humility in recognising where responsibility ends. I can prepare carefully, communicate clearly, make recommendations, support others, raise risks, and act with integrity. I cannot control another person’s judgement. I cannot guarantee every outcome. I cannot force an organisation to make the decision I prefer. I cannot carry everyone’s expectations at once. There is something quietly arrogant in assuming that everything depends on us. It does not. We are responsible for our part, and our part is enough.

The same principle applies to difficult people. For a long time, I assumed that maturity meant being able to deal patiently with everyone. I no longer believe that. Some people should be understood. Some should be confronted. Some should simply be kept at a distance. Not every provocation deserves a reply, not every disagreement deserves an afternoon, and not every person deserves unlimited access to our attention.

Strategic distance is not necessarily cowardice. Sometimes it is discipline. A difficult person may occupy five minutes of your day and five hours of your mind. The first part may be unavoidable. The second part often is not. We may not always be able to control who enters our environment, but we can become more selective about who remains in our thoughts.

At the same time, calmness should never become an excuse for passivity. Anger sometimes carries important information. It can tell us that a boundary has been crossed, that something unfair has happened, or that silence has lasted too long. For people who naturally avoid confrontation, the challenge may not be reducing anger, but learning to express it earlier and more clearly before resentment accumulates.

There is a difference between aggression and firmness. We do not need rage in order to say, “I disagree,” “This is not acceptable,” or “This needs to change.” Calm words can be stronger precisely because they are not diluted by emotional chaos. Anyone can shout. It takes considerably more discipline to remain composed while refusing to surrender what matters.

Another practice I have come to value is deliberately noticing something good each day. At first glance, this may seem unrelated to anger, but attention shapes emotional life more than we realise. The mind becomes skilled at whatever we repeatedly ask it to notice. If we constantly search for incompetence, disrespect, disappointment, and inconvenience, we will eventually find evidence everywhere. A bitter mind can always build a convincing case for bitterness.

The opposite habit can also be cultivated. A good conversation, a useful book, a new idea, a satisfying meal, an evening walk, a piece of music, a beautiful sunset, or a small piece of work done well can all become evidence that the day contained something of value. This does not mean pretending that everything is wonderful. It means refusing to allow what went wrong to become the only thing that was real.

Perhaps a good day does not require the absence of difficulty. Perhaps it only requires remembering that difficulty was not the whole day.

I do not expect to become someone who never feels anger, nor do I think that would necessarily be desirable. Emotion is part of being human, and anger can sometimes reveal what we care about. What I hope to become better at is allowing emotion to inform me without allowing it to command me.

The practice, then, is simple to describe but difficult to master. Notice the emotion. Separate fact from interpretation. Examine the expectation beneath it. Decide whether action is necessary. Act where action is useful. Set boundaries where boundaries are needed. Create distance where distance is wise. Then let go of what no longer requires your attention.

This is a more demanding definition of calm than simply “not getting angry.” Calm is not the absence of disturbance. It is the ability to return. Again and again.

Life will continue to present unreasonable people, failed plans, careless words, delays, disappointment, and injustice. The world will not reorganise itself around our peace of mind. The work, therefore, is not to create a life in which nothing provokes us. It is to become someone who can meet provocation without surrendering control of the next decision.

Over time, perhaps this is what emotional strength really means. We learn to carry less. We react more slowly. We see more clearly. We distinguish what actually happened from what we added to what happened. And when anger appears, we remember that the feeling may be real, but it is not an instruction.

We still choose the next move.

Stakeholder Management Is a Core Enterprise Architecture Capability

Victor Leung — Sat, 03 Oct 2026 06:36:03 +0000

Enterprise Architects are trained to think in systems. We map capabilities, applications, information flows, integrations, technology platforms, dependencies, risks, and target states. We learn to describe complexity and to design pathways from the current state toward a more intentional future. Yet some of the hardest architectural problems have surprisingly little to do with technology.

An Enterprise Architect can produce an elegant target architecture, establish clear principles, quantify technical debt, demonstrate long-term savings, and still watch the organization make a different decision. When this happens, the natural reaction is often to assume that the architecture was misunderstood, poorly communicated, or overridden by short-term thinking. Sometimes that is true. But there is another possibility: the architect has modeled the technology system more thoroughly than the human system in which the decision must operate.

An enterprise is not simply a collection of applications, processes, data, and infrastructure. It is also a network of people with different responsibilities, incentives, histories, ambitions, pressures, and degrees of influence. Architectural decisions inevitably enter that network. This is why stakeholder management should not be treated as a supporting communication skill. It is part of the architecture itself.

Technology professionals often carry an implicit belief that the best idea should eventually prevail. If an architecture is technically sound, economically rational, and strategically aligned, decision-makers should be able to recognize its merits. If enough evidence is presented, the organization should converge on the right answer. Real organizations rarely behave so neatly. Behind this reflection makes a broader observation about organizational life: strong performance alone does not necessarily translate into influence, and research associates political skill with stronger performance evaluations and perceptions of leadership effectiveness.

For Enterprise Architects, the implication is important. Being correct is not the same as being influential. An architecture can be technically superior and still be organizationally infeasible.

Consider a typical modernization programme. The architecture team concludes that several duplicated platforms should converge onto a common strategic capability. From an enterprise perspective, the logic is compelling. The organization can reduce operating costs, simplify integrations, consolidate controls, improve data consistency, and lower technology risk. But every duplicated platform has an owner. Each may be associated with a budget, a team, a roadmap, an executive sponsor, and years of organizational history. Consolidation may create enterprise value while simultaneously reducing someone else's autonomy, authority, funding, or perceived importance.

The architectural recommendation therefore becomes a political and organizational question the moment it leaves the diagram. If architects model applications, interfaces, and data flows but fail to model the interests surrounding them, the architecture is incomplete.

Enterprise Architects should therefore develop a mental model of stakeholders that is as deliberate as their model of technology dependencies. Who owns the problem? Who controls the budget? Who carries the operational risk? Who benefits if the proposal succeeds? Who loses autonomy? Who has formal decision rights? Who has informal influence? Whose judgment does the executive sponsor trust? Who can slow implementation without formally rejecting the decision?

These relationships form an organizational architecture around every important decision. Traditional tools such as RACI matrices help clarify responsibilities, but they rarely explain how influence actually flows. Formal authority and organizational influence are not always the same thing. Someone with limited authority on an organization chart may shape an executive decision because their judgment is trusted. A long-serving engineer may have substantial institutional credibility. A programme director may control timing and sequencing even if another executive technically owns the decision. The formal organization describes how decisions are supposed to happen. The informal organization often explains how they actually happen.

This is where many architects become uncomfortable. The word politics can sound manipulative, transactional, or incompatible with professional objectivity. Architects often prefer to believe that their role is to present evidence, maintain technical integrity, and allow governance to make the decision. But refusing to understand organizational politics does not make politics disappear. It simply leaves the architect with a weaker understanding of the environment in which the architecture must succeed.

Political intelligence, in this context, does not mean manipulation. It means understanding incentives, relationships, power, and context well enough to move the organization toward a better decision. Different stakeholders can look at the same architecture and see entirely different consequences. The CIO may see simplification. The CFO may see a large investment before benefits materialize. A product leader may see slower delivery. Security may see reduced attack surface. Operations may see migration risk. A regional business unit may see loss of autonomy. Engineering may see a year of remediation work. None of these stakeholders is necessarily irrational. They are evaluating the same architecture through different accountabilities.

Stakeholder management becomes more effective when architects stop asking why stakeholders do not understand the architecture and start asking what the architecture means from where those stakeholders are standing. That shift sounds subtle, but it changes the nature of the conversation. It turns stakeholder engagement from presentation into diagnosis.

Architects also have a tendency to assume that they know what senior stakeholders care about. They construct presentations around scalability, resilience, optionality, technical debt, and strategic alignment because these are the dimensions architects naturally value. I make a useful observation: rather than assuming what influential stakeholders consider important, ask them directly and regularly what matters most.

Applied to Enterprise Architecture, this suggests that architects should understand the decision criteria before presenting the answer. A CFO may have little interest in architectural elegance but considerable interest in how quickly infrastructure costs leave the P&L. A COO may care more about migration risk than future-state simplification. A business executive may knowingly accept additional technical debt if it enables entry into a strategically important market six months earlier. A CISO may support platform consolidation for reasons completely different from those of the CTO.

The architect's role is therefore not simply to communicate the same message more clearly. It is to translate architectural value across stakeholder perspectives without changing the underlying truth of the recommendation. Stakeholder management should never mean telling everyone what they want to hear. It means understanding what each stakeholder needs to understand in order to evaluate the decision properly.

This ability to translate is especially important because much of the value created by Enterprise Architecture is difficult to see. Good architecture often prevents problems rather than producing visible outputs. An unnecessary platform is never purchased. A dangerous integration pattern is avoided. Two programmes reuse the same capability instead of creating duplicates. A regulatory issue is resolved during design rather than discovered in production. A future migration becomes easier because today's decision preserved optionality. In each case, the architect creates value partly through events that never occur.

That makes Enterprise Architecture vulnerable to what I describe as becoming the organizational equivalent of a foundation: essential, but largely invisible. I argue that valuable performance must be made visible if it is to be appreciated.

For architects, visibility should not be confused with self-promotion. The more useful concept is traceability. Architectural decisions should be connected to measurable outcomes. Instead of saying that governance has improved, demonstrate that multiple programmes reused established patterns and avoided duplicated design work. Instead of reporting that the application estate has been rationalized, show the reduction in platforms, licences, integrations, operational processes, and control points. Instead of saying that a target architecture has been established, show which investment decisions changed because that architecture existed.

Architecture should leave evidence. Otherwise, the organization may struggle to distinguish architecture that creates value from architecture that simply creates documents.

This challenge is compounded by the fact that Enterprise Architects often operate without direct authority over the teams whose decisions they are expected to influence. They may not control engineering teams, programme budgets, product roadmaps, or delivery priorities. Yet they are still expected to create alignment across them. Influence is therefore not an optional leadership skill in Enterprise Architecture. It is one of the profession's defining capabilities.

Authority can compel a decision. Influence creates the conditions in which people choose to support it. The latter is considerably harder because it depends on credibility, trust, and relationships that usually need to exist before the formal decision point.

This is why stakeholder management should begin long before an Architecture Review Board or governance meeting. By the time a proposal reaches formal governance, positions may already have hardened. Effective architects engage engineering teams before the review, understand product constraints before defining principles, discuss financial assumptions with finance, and involve security before presenting an architecture that depends on security approval. They build alignment progressively.

In a mature architecture practice, governance becomes less about winning an argument and more about confirming a direction that stakeholders already understand. Formal forums remain important, but they should not become the first place where competing interests discover one another.

The quality of those relationships also matters. I discuss the role of recognition and the human tendency to respond positively when people feel acknowledged and respected. For professional architects, this should not be interpreted as an argument for flattery. It is better understood as a reminder that respect itself is a form of influence.

People are more willing to support difficult decisions when they feel heard, understood, and included in the reasoning. An architect who enters every discussion determined to demonstrate intellectual superiority may win technical arguments while gradually losing organizational influence. Being the smartest person in the meeting is not the same as being the person capable of moving the organization.

Strong architects give stakeholders genuine ownership without surrendering architectural integrity. Rather than presenting a target state as something Enterprise Architecture has determined, they can explain how the direction brings together product's need for speed, security's requirement for stronger controls, operations' desire for stability, and finance's concern about cost. The architecture may remain exactly the same, but the social architecture around it changes.

People are more likely to support decisions in which they can see their concerns reflected. That does not mean architecture should be designed by committee. It means stakeholders should be able to recognize how their constraints and priorities were considered.

This is also why resistance should be treated as information rather than obstruction. A stakeholder who opposes an architecture may not be opposed to architecture itself. They may be protecting a delivery commitment, concerned about operational stability, responding to a previous failed transformation, or aware of a constraint that has not yet entered the architectural model. Listening is therefore not simply good interpersonal behavior. It is a form of architectural discovery.

Enterprise Architecture has traditionally invested heavily in artifacts: reference architectures, principles, roadmaps, capability maps, standards, decision papers, and target-state models. These are useful, but artifacts do not create organizational change by themselves. People do.

For major architectural decisions, architects should therefore think in terms of coalitions as well as deliverables. Does the proposed direction have sufficient support across technology leadership, product, engineering, security, operations, finance, risk, data, regional teams, and programme leadership? Complete consensus is rarely necessary or realistic. What matters is understanding where support exists, where resistance remains, what is driving that resistance, and which dependencies are critical to execution.

This suggests that stakeholder management should become more explicit within architecture practice. Alongside a target architecture, architects should maintain a stakeholder view of the decision. They should understand interests, influence, impact, decision rights, concerns, and likely areas of resistance. They should plan engagement with the same discipline used to plan technology dependencies. If an unresolved system dependency can threaten delivery, an unresolved stakeholder dependency can do the same.

The need for this becomes most obvious when we remember that architecture is ultimately about trade-offs. Centralization competes with autonomy. Speed competes with standardization. Reuse competes with local optimization. Resilience competes with cost. Strategic convergence competes with tactical delivery. Control competes with flexibility. Build competes with buy.

Every significant architectural decision changes the distribution of costs, benefits, risks, and control. In that sense, architecture inevitably creates winners, losers, and compromises. The mature Enterprise Architect does not hide these tensions behind technical language. The architect makes them explicit so that the organization can make a conscious decision.

This may be one of the most important contributions of Enterprise Architecture. Its purpose is not to eliminate disagreement, but to structure disagreement around the right questions. Instead of allowing teams to argue endlessly about technologies, architecture can move the conversation toward capabilities, outcomes, risks, and enterprise priorities. Instead of allowing hidden incentives to distort decisions, architecture can surface the trade-offs. Instead of pretending that every stakeholder can achieve every objective, architecture can clarify which priorities need to take precedence.

Seen this way, the value of Enterprise Architecture is not simply that it produces better designs. It improves the quality of organizational decision-making. Stakeholder management is what makes that possible.

The encouraging point is that this capability can be learned. I emphasize that influence and political skill should not be treated purely as innate personality traits. They become more effective through practice. This matters because many people enter architecture precisely because they are analytical thinkers. They enjoy technology, models, complexity, and structured reasoning. Organizational politics may feel less natural.

But stakeholder management is a capability, not a personality type.

Architects can learn to distinguish interests from positions. They can learn to ask better questions, identify informal influence, communicate the same decision through financial, operational, strategic, and technical lenses, and recognize when trust rather than evidence is the missing ingredient. They can learn when disagreement should be challenged publicly and when it is better resolved privately. They can become more deliberate about who needs to be involved before a governance decision and more attentive to the organizational implications of technical choices.

These skills develop in much the same way as architectural judgment: through repeated exposure to difficult situations, reflection, and practice.

Enterprise Architects often describe their role as connecting business and technology. That description is increasingly incomplete. The role connects strategy, technology, and organizational reality. Strategy describes where the enterprise wants to go. Technology provides capabilities that can help it get there. Organizational reality determines whether the enterprise can actually make the journey.

Ignoring that third dimension produces architecture that can be logically elegant and practically irrelevant.

Once stakeholder management is treated as part of architecture rather than an activity that happens around it, the profession looks different. Stakeholder understanding becomes part of discovery. Coalition building becomes part of design. Communication becomes part of implementation. Influence becomes part of architecture leadership.

The strongest Enterprise Architects, therefore, are not simply those who can design the most sophisticated target state. They are those who can help an organization understand the choices in front of it, confront the necessary trade-offs, build sufficient alignment, and move toward a better future state together.

Architecture is not implemented by diagrams.

It is implemented by people.

And people are part of the system.

Enterprise Architecture Must Start Outside the Enterprise

Victor Leung — Thu, 10 Sep 2026 14:09:35 +0000

Enterprise Architecture is often described as the discipline of understanding an organisation from the inside out: its business capabilities, processes, applications, data, technology, governance, and operating models. We create architecture principles, reference architectures, roadmaps, standards, and technology strategies. We map the enterprise in increasingly sophisticated ways.

But there is a more fundamental question that should come before all of this: What business are we actually in?

This is not a trivial question. The answer cannot simply be derived from the products we manufacture, the applications we operate, or the services we currently provide. The organisation exists because it satisfies a need outside itself. The customer ultimately defines the business, and therefore the starting point for strategy should be the customer and the market rather than the organisational chart.

This has profound implications for Enterprise Architecture.

An architecture that begins with the current organisation tends to optimise what already exists. It documents applications, rationalises technology, reduces duplication, standardises platforms, and improves operational efficiency. These activities are valuable, but they can also create a dangerous illusion of progress. We may become exceptionally good at optimising an enterprise for a business model that is already becoming obsolete.

The real purpose of architecture is therefore not to make the existing enterprise more efficient. It is to ensure that the enterprise remains capable of creating value as its environment changes.

That distinction matters because the most important changes rarely originate inside the enterprise. New technologies, new customer expectations, new competitors, regulatory shifts, alternative business models, and changing economic conditions emerge from the external environment. The source material makes the point directly: strategy requires organised information about markets, customers, noncustomers, technology, finance, and the changing world economy because that is where results ultimately occur.

For Enterprise Architects, this means that the architecture repository should never become the centre of the architectural universe.

The architecture repository tells us what we have. It does not necessarily tell us what we need to become.

A mature architecture practice therefore needs two perspectives operating simultaneously. The first is an inside-out view: capabilities, processes, systems, data, infrastructure, technical debt, dependencies, costs, and risks. The second is an outside-in view: customers, competitors, noncustomers, emerging technologies, regulation, societal change, economic forces, and new sources of value.

The first protects the enterprise from internal complexity. The second protects it from external irrelevance.

This is particularly important in an era of artificial intelligence. An organisation can spend years developing an AI strategy around its existing processes and technology estate while a competitor uses AI to redefine the underlying customer experience altogether. The architectural question is therefore not simply, “Where can we introduce AI?” It is, “Which assumptions about how our business creates value are no longer valid because AI changes the economics or possibilities of the market?”

That is a fundamentally different question.

It also changes how we should think about enterprise capabilities. A capability model is useful because it provides a stable view of what the organisation must be able to do. But capabilities should not become permanent monuments. Their importance, boundaries, and even existence can change when customer needs, technology, regulation, or competitive dynamics change.

The architecture function must therefore become a learning system.

The source material describes every enterprise as both a learning and teaching institution, with development embedded at every level and never truly finished. For architecture teams, this principle is especially relevant. Technology changes rapidly, but the more significant challenge is that our understanding of the business must change with it.

An Enterprise Architect who stops learning about technology eventually becomes irrelevant. An Enterprise Architect who stops learning about the business becomes even more dangerous.

Architecture should therefore continuously challenge its own assumptions. Why does this capability exist? Why is this process designed this way? Why does the customer tolerate this experience? Why are we investing in this platform? Which emerging technology could make this architecture obsolete? Which competitors are solving the same customer problem differently? Which noncustomers have deliberately chosen not to use our products?

These questions transform architecture from documentation into strategic inquiry.

They also change the meaning of governance.

Traditional architecture governance often focuses on preventing deviation from established standards. A project proposes a technology, and the architecture board determines whether it complies with the target architecture. This provides control, but control alone is insufficient in an environment where change is continuous.

The better question is not simply whether a proposal conforms to the architecture. It is whether the architecture itself remains fit for purpose.

Governance should therefore operate in both directions. Teams should be governed by architecture principles, but architecture should also be challenged by evidence from the business and the market. Otherwise, yesterday's architectural decisions become tomorrow's constraints.

This is where architecture and innovation become inseparable.

I argue that management and entrepreneurship are not fundamentally separate activities. An organisation that does not innovate cannot survive indefinitely, while innovation without management cannot endure. Organisations therefore need to be designed for change rather than merely reacting to it.

The same principle applies to Enterprise Architecture.

Architecture should not be the function that says “no” to innovation. Nor should it become an innovation laboratory disconnected from operational reality. Its role is to create the conditions in which innovation can occur repeatedly, safely, and at scale.

That requires architectural modularity, reusable platforms, clear APIs, governed data products, composable capabilities, automated controls, observability, security by design, and an operating model capable of moving successful experiments into production.

In other words, architecture should reduce the cost of change.

This is one of the most important measures of architectural maturity.

A highly mature enterprise is not necessarily the one with the cleanest architecture diagrams. It is the one that can respond to a meaningful change in customer demand, regulation, technology, or competition without requiring the entire organisation to be redesigned.

That requires another shift: from managing systems to managing organisational adaptability.

Technology is only one component of this adaptability. Organisations are ultimately collections of people working together toward common objectives. Management exists to make individual strengths effective and weaknesses less consequential, while creating the conditions for people to perform collectively.

Enterprise Architecture should reflect the same philosophy.

An architecture that looks elegant technically but creates excessive cognitive load for engineers, unclear ownership for product teams, bureaucratic approval processes, or fragmented accountability is not a good architecture. The architecture of the organisation includes its decision rights, responsibilities, communication mechanisms, and ways of working—not just its technology stack.

This is why organisational architecture matters as much as technical architecture.

A distributed technology platform with centralised decision-making may create bottlenecks. A decentralised organisation without common standards may create fragmentation. A product operating model without clear enterprise boundaries may produce duplicated capabilities. A highly centralised architecture function may provide consistency at the expense of speed.

There is no universally correct organisational design. Architecture must fit the context in which people actually work.

The same principle applies to architecture metrics.

Cost reduction is important, but it cannot be the only definition of architectural success. The source material explicitly challenges the idea that output or the bottom line alone provides an adequate measure of organisational performance, pointing instead to dimensions such as market position, innovation, productivity, people development, quality, and financial results.

Enterprise Architecture should adopt a similarly multidimensional scorecard.

How much technology cost did architecture eliminate? That matters.

But how much faster can the organisation launch a new product? How quickly can it respond to regulatory change? How many strategic capabilities can be reused? How much complexity has been removed? How resilient is the technology estate? How effectively can data be reused? How many innovation opportunities can move from concept to production? How much customer value is created by architectural investment?

These questions move architecture from a technology cost centre toward a strategic value discipline.

Perhaps the most important implication is that Enterprise Architecture must deliberately look beyond its own boundaries.

Architects should study industries outside their own. Many transformative technologies originate outside the industry in which they eventually become disruptive. A financial-services architect, for example, should not only study other financial institutions. The architect should also understand developments in cloud computing, artificial intelligence, telecommunications, retail, healthcare, logistics, gaming, manufacturing, and other sectors where new customer experiences and technology models may emerge first.

The boundary of architectural thinking should therefore be wider than the boundary of the enterprise.

The same applies to customers and noncustomers. Existing customers tell us how well the current business model performs. Noncustomers can reveal where the business model itself is failing to create sufficient value. The source material highlights noncustomers as an important source of fundamental change.

For architects, this creates a powerful strategic opportunity.

Instead of asking only, “How do we improve the experience of our existing users?”, we should also ask, “Why do potential users choose not to engage with us?”

The answer may reveal architectural problems that conventional application analysis cannot see: excessive onboarding friction, fragmented channels, poor data interoperability, slow decision-making, limited personalisation, inadequate ecosystem integration, or simply a business proposition that no longer matches customer expectations.

Architecture becomes strategically valuable when it can connect these external signals to internal structural decisions.

Ultimately, Enterprise Architecture is not about drawing the enterprise.

It is about helping the enterprise remain relevant.

The architecture function should continuously connect purpose, customer value, organisational capability, information, technology, people, and change. It should understand the enterprise as a living system rather than a static collection of components.

The strongest architecture teams therefore spend less time defending the architecture they have created and more time questioning whether that architecture is still the right one.

They understand that standards are means, not ends. Platforms are means, not ends. Capability models are means, not ends. Technology rationalisation is a means, not an end.

The end is organisational performance and continued relevance.

The Enterprise Architect's ultimate responsibility is therefore not to predict the future perfectly. That is impossible. It is to design an enterprise capable of responding intelligently when the future arrives.

That requires an outside-in mindset.

Start with the customer.

Understand the market.

Study the noncustomer.

Watch the edges of the industry.

Question assumptions.

Make innovation systematic.

Build organisational learning into the architecture.

Measure outcomes rather than activity.

And above all, design the enterprise not merely to operate efficiently today, but to change deliberately tomorrow.

Because the greatest architectural risk is not complexity.

It is becoming exceptionally efficient at doing something the market no longer values.

Why Enterprise Architects Must Design for Results, Not Just Systems

Victor Leung — Sat, 29 Aug 2026 04:03:10 +0000

Enterprise Architecture has traditionally been associated with the internal structure of an organization. We map applications, rationalize technology portfolios, define data models, establish standards, and design target architectures. These activities are necessary. But they can also create a dangerous illusion: that if we understand the inside of the enterprise well enough, we understand the enterprise itself.

We do not.

The most important results of an organization exist outside its boundaries. Customers, markets, technological shifts, competitors, regulators, and society ultimately determine whether an enterprise succeeds. This creates a fundamental challenge for Enterprise Architects: our discipline cannot simply be about optimizing the internal machinery of the organization. It must help the enterprise sense, interpret, and respond to the world beyond it.

That requires a broader understanding of both management and architecture.

Management is fundamentally about people. Its purpose is to enable individuals with different strengths, skills, and limitations to perform together toward a common outcome. An organization without shared goals and values is not truly an enterprise; it is merely a collection of disconnected activities. Training, development, communication, and individual responsibility are therefore not peripheral management concerns. They are essential elements of organizational performance.

The same principle should reshape Enterprise Architecture.

Architecture is often presented as a technical discipline concerned with systems, interfaces, platforms, and standards. But architecture is ultimately a coordination mechanism for human enterprise. Every capability map represents responsibilities distributed across people and teams. Every operating model defines how decisions are made. Every data architecture determines how knowledge flows. Every technology platform either enables or constrains people in their ability to work together.

An architecture that is technically elegant but organizationally unusable has failed.

This is particularly important in large enterprises, where complexity often encourages specialization. Teams become experts in their own domains. Technology functions optimize platforms. Business units optimize local objectives. Data teams optimize information assets. Risk functions optimize control. Each individual decision may be rational, yet the collective result can be fragmentation.

The Enterprise Architect must therefore ask a question that goes beyond technology: What enables people and capabilities across the organization to achieve joint performance?

That question changes the nature of architecture.

The first architectural responsibility is to establish a shared direction. Enterprises need clear objectives and values, but transformation programmes frequently begin with solutions rather than outcomes. We start with cloud migration, data modernization, artificial intelligence, or platform transformation before agreeing on the problem the enterprise is trying to solve.

Architecture should reverse this sequence.

A target architecture should be an expression of strategic intent. It should make visible the capabilities required to achieve that intent, the changes needed across processes and technology, and the decisions required to move from the current state to the desired future. Without this connection, architecture becomes documentation. With it, architecture becomes a mechanism for strategic alignment.

The second responsibility is to design for continuous learning.

No enterprise operates in a stable environment for long. Markets evolve, customer expectations change, technologies mature, regulations emerge, and new competitors redefine what is possible. An organization that treats transformation as a one-time programme will eventually find that its architecture reflects a world that no longer exists.

The future enterprise must therefore be designed as a learning system.

For Enterprise Architects, this means that target state cannot mean fixed state. A useful architecture must define not only what the organization should become, but also how it can continue to change. Modularity, loose coupling, reusable capabilities, clear interfaces, evolutionary roadmaps, and adaptive governance are valuable not because they are fashionable architectural patterns, but because they increase the organization's capacity to learn and respond.

The architecture itself must be capable of evolution.

This brings us to one of the most persistent misconceptions in management and technology: the belief that management is concerned with stability while innovation belongs somewhere else.

The distinction is increasingly meaningless.

An organization that manages efficiently but fails to innovate will eventually become obsolete. An organization that innovates without the ability to operationalize and scale its ideas will struggle to survive. Management and entrepreneurship are not opposing disciplines. They are complementary dimensions of the same responsibility: ensuring that the enterprise can perform today while remaining capable of creating tomorrow.

Enterprise Architecture sits directly at this intersection.

The architect must help protect the operational integrity of the enterprise while creating room for experimentation. We need architectures that support reliability without becoming rigid, governance without becoming bureaucracy, and standardization without eliminating innovation.

This requires architectural ambidexterity.

Core platforms may need strong controls, consistency, and resilience. Emerging capabilities may require experimentation, rapid iteration, and tolerance for uncertainty. The mistake is to apply the same governance model to both. Architecture should distinguish between what must be stable and what must remain adaptable.

The third responsibility is to move the enterprise's attention from effort to outcomes.

Inside an organization, it is easy to measure activity. We can count projects delivered, applications migrated, incidents resolved, servers decommissioned, and costs reduced. These metrics are useful, but they can become dangerous when they are mistaken for results.

Activity is not outcome.

An Enterprise Architecture function can produce hundreds of architecture diagrams without changing the performance of the enterprise. A technology transformation can migrate every application to the cloud without improving customer experience. A data programme can create a sophisticated platform without enabling better decisions.

The architect must therefore connect internal activity with external value.

The question should not simply be, "Did we deliver the architecture?" It should be, "What changed because of it?"

Did customer outcomes improve?

Did decision-making become faster or more effective?

Did the enterprise enter a new market more quickly?

Did risk become easier to understand and manage?

Did the organization increase its capacity to innovate?

Did we improve the economic performance or resilience of the enterprise?

These are more difficult questions than measuring technology delivery, but they are the questions that matter.

Strategy, after all, requires information about the environment. Organizations need to understand markets, customers, noncustomers, technological developments, and changes occurring beyond their traditional industry boundaries. The most significant opportunities and threats frequently emerge from outside the organization's existing field of vision.

This should fundamentally influence how Enterprise Architecture operates.

Architecture repositories are traditionally inward-looking. They contain applications, processes, technologies, integrations, and organizational structures. Yet an enterprise's strategic context extends far beyond these internal assets.

The architecture function should become an intelligence capability as well as a governance capability.

It should help leaders understand how external trends could affect internal capabilities. It should connect technology trends to business strategy. It should identify where emerging regulations may require new data capabilities. It should examine how changes in customer expectations could expose weaknesses in existing operating models. It should look beyond competitors and study noncustomers, adjacent industries, and technologies emerging from unexpected places.

The future of Enterprise Architecture is therefore not simply enterprise-wide. It is ecosystem-aware.

This outward orientation is especially important in asset management and financial services. The enterprise no longer competes solely through products or investment performance. It competes through the quality of its client experience, the intelligence of its data, the speed of its decision-making, the resilience of its operations, and its ability to respond to structural changes in markets and society.

Climate risk, artificial intelligence, digital assets, demographic change, private markets, and evolving regulation do not arrive neatly within existing organizational boundaries. They cut across investment management, distribution, operations, risk, technology, data, and governance.

A traditional siloed architecture is poorly equipped to address cross-cutting change.

The Enterprise Architect's role is to make those interdependencies visible before they become failures.

Innovation is another area where architecture must evolve. Every organization has its own distinctive capabilities, but innovation is a universal requirement. The challenge is not merely to generate ideas. It is to recognize meaningful opportunities, assess them in the context of the market, and convert them into sustained value.

That requires measurement beyond internal performance.

Organizations should ask not only whether their own innovation initiatives succeeded, but also what important changes occurred across their industry and beyond it. Which opportunities were captured? Which were missed? Did we fail because we did not see the change, because we dismissed it, or because we were unable to execute?

These are architectural questions as much as strategic ones.

A missed opportunity is often not the result of insufficient imagination. Sometimes the organization sees the future clearly but lacks the capabilities, data, platforms, operating model, or decision-making structures required to respond.

Architecture determines the organization's practical ability to act.

Finally, Enterprise Architects must recognize that specialization creates both advantage and danger. Deep expertise can establish a powerful position, but it can also create tunnel vision. Organizations become exceptionally good at solving yesterday's problems within a narrowly defined domain while failing to recognize that the environment around them has changed.

The same risk applies to architecture.

We can become experts in frameworks, reference architectures, cloud platforms, integration patterns, and technology standards while losing sight of the fundamental purpose of the enterprise. We can become so focused on the architecture of the inside that we fail to understand where the results are.

The most effective Enterprise Architect must therefore be both inwardly rigorous and outwardly curious.

We need to understand the complexity of the enterprise in extraordinary detail. But we must never confuse that complexity with the purpose of the enterprise.

The purpose is outside.

It is in the customer whose needs are changing. It is in the market that is being disrupted. It is in the technology emerging from another industry. It is in the regulation that will reshape the operating model. It is in the societal expectation that will redefine what responsible business means.

This is why Enterprise Architecture must evolve from being primarily a discipline of technology alignment into a discipline of enterprise adaptation.

Our job is not to create the perfect architecture.

Our job is to help the organization become capable of joint performance, continuous learning, disciplined innovation, and meaningful adaptation.

The diagrams, principles, roadmaps, standards, and governance processes are only instruments.

The real measure of architecture is whether the enterprise can see change coming, understand what it means, mobilize its people and capabilities, and create results where they ultimately matter.

Outside the boundary.