From Gaming to Enterprise Architecture: Lessons in Adaptability

For a technical professional changing industry or role, a move need not mean starting again. My move from game development into web development, eCommerce and enterprise architecture changed the platforms, vocabulary and commercial context. Problem framing, technical judgement, feedback, collaboration and adapting a method to new constraints came with me.

That is the useful lesson in career adaptability. It is not a personality trait or a command to ‘embrace change’. It is the ability to recognise which parts of your experience are fundamental, which are tied to one environment and what the new environment requires you to learn.

Games taught me to work across boundaries

Game development is not neatly technical or creative. A game succeeds through the interaction of code, art, design, production, audio, hardware constraints and the player’s experience. A technically elegant system that does not help the game is still the wrong system.

Working on projects across several generations of PlayStation, Xbox and PC taught me to move between those concerns. I had to understand enough of another discipline to see its constraints, explain technical trade-offs without hiding behind jargon and keep a team pointed towards a playable result.

The work was often uncertain. Hardware changed, schedules moved, client expectations shifted and teams had to learn new tools while delivering. That uncertainty made adaptability practical rather than inspirational: find out what changed, preserve what still works and shorten the feedback loop on everything else.

My four-part game-development career history records the studios and projects. The more durable lesson sits underneath the chronology. My value was never confined to knowing one engine, console or job title.

The financial crisis forced the distinction

The 2008 financial crisis and the disruption around it removed any illusion that industry experience guaranteed a stable path. Redundancies and studio closures made a career change necessary rather than theoretical.

I had to separate the things I knew from the setting in which I had learnt them.

Some knowledge was specific: console platforms, production relationships and the economics of commissioned game development. Other capabilities travelled well:

• decomposing ambiguous problems;
• building and reviewing software;
• judging trade-offs between speed, quality and risk;
• coordinating specialists around a shared outcome;
• explaining technical choices to non-specialists;
• learning through short, concrete feedback loops.

That distinction gave me a route into web technologies and eCommerce. I was not becoming a beginner in every dimension. I was applying experienced judgement while becoming a beginner in the parts that were genuinely new.

Software development remained the foundation

Returning to hands-on software development gave the transition continuity. Languages, infrastructure and delivery practices changed, but code still made assumptions testable.

In games, a playable build exposes whether separate disciplines have combined into something coherent. In web and eCommerce, working software exposes whether architecture, data and user experience survive contact with real behaviour. Enterprise architecture can drift into diagrams and governance language unless it remains connected to those implementation realities.

That is why I have continued to build software alongside broader technical and leadership roles. Hands-on work is not a nostalgic return to an earlier career. It keeps judgement connected to current tools, constraints and failure modes.

Outcome focus transferred across industries

One management principle travelled particularly well: fixed attendance is a weak proxy for contribution in creative technical work.

In a game studio, the useful evidence might be a playable feature, a stable build or a design decision that resolves uncertainty. In eCommerce, it might be a safe release, a measurable improvement to a customer journey or a system that behaves reliably under load. In enterprise architecture, it might be a decision that teams can actually implement, with risks and constraints made explicit.

The outcome changes. The need for clarity does not.

My argument for outcomes over fixed hours began in games, but later coding, technical leadership and development roles kept confirming the distinction. In my experience, people had a better chance of doing useful work when they knew what must be achieved, understood why it mattered, received feedback early and had enough autonomy to choose a sensible method.

Autonomy does not remove accountability. It makes accountability more honest. Instead of asking whether somebody looked busy at the expected time, ask whether the work is progressing, whether quality is visible, whether risks are being raised and whether colleagues can depend on each other.

Adaptability is constrained experimentation

Advice about career change often becomes vague: stay curious, be resilient, keep learning. None of that tells you what to do on Monday.

A more useful approach is constrained experimentation. Name the durable capability rather than the title you held. Identify the economics, users, regulation, risk and delivery expectations that have changed. Build something small, then seek feedback from people who understand the new domain. Adjust the method when the new context requires it, but keep the same standard of quality and intellectual honesty.

This is how I have approached later changes in software, architecture and emerging technology. A home lab, a small application or a focused technical experiment gives me somewhere to test what I think I understand without pretending that previous seniority makes the new subject familiar.

Not every lesson transfers unchanged

Games also gave me habits that needed challenging.

Intense milestones can make sustained overwork look normal. Technical novelty can be mistaken for product value. A close studio culture can hide knowledge in personal relationships rather than systems. Fast decisions made by an experienced small team may fail when copied into a larger or regulated organisation.

Adaptability therefore includes letting go. Experience should improve the questions you ask, not grant every old answer permanent authority.

The move into enterprise architecture strengthened my attention to organisational consequences: who owns a decision, what another team needs to implement it, how risk is governed and whether the proposed future can be reached from the current system. Games had already taught me to connect disciplines. The new context made the scale and responsibility of those connections more explicit.

A career is more durable than its labels

My career has moved through games, web development, eCommerce, enterprise architecture, technical leadership and continued hands-on coding. From the outside, those can look like separate chapters. From inside the work, the through-line is clear: understand the real problem, make constraints visible, build or decide something testable and use feedback to improve it.

The technology will keep changing. So will the job titles. The aim is not to predict every change or remain permanently comfortable. It is to know which capabilities deserve to travel with you - and to be honest about what you need to learn when you arrive.