Work

I joined Lumberyard as a product manager with a broad brief and no defined mandate. The engineering effort was enormous: license CryEngine, rebuild its asset and component systems, and get the engine ready for launch. With that many moving parts, I spent my early months learning the terrain, where the work was defined and where it wasn’t.

Then I looked at the release plan from the other side of the screen. A new user would open the engine and find a feature reference and an empty project. No first-run experience. No tutorials. No assets to open, take apart, and learn from. And because Lumberyard had rebuilt CryEngine’s core systems, the existing CryEngine learning materials no longer applied.

I’d shipped 18 games. I knew artists and designers learn by doing, and Unity and Unreal had built their onboarding around that fact, with starter projects, guided tutorials, and sample content. Lumberyard was headed for launch without any of it. The need sat between every team’s priorities. It wasn’t anyone’s job yet.

Amazon makes decisions through written proposals, so I made the case in Amazon’s format: a working-backwards press release and a written narrative, with no slides and no mockups. It described what a new creator should experience on day one, and it showed how Unity and Unreal already delivered that experience.

The response wasn’t no. It was not now. The team was stretched, the roadmap was already full, and much of the leadership came from engineering, where an engine succeeds when the technology works. I kept pressing the case with my manager, who carried it to the engine’s senior leader. Over many conversations, the question shifted from whether creators needed this to what the smallest useful version could be.

I narrowed the vision to a first step leadership could say yes to: a four-person founding team made up of me, a producer, an art director, and a technical artist, with the work planned in phases. For launch, we delivered two things. One was an onboarding tutorial covering foundational workflows; the other was a rendering demo that showed what the engine could do. Together they gave creators a way to begin and a reason to do so.

The launch content landed well, and that bought us the next phase. Leadership added an executive producer, a technical game designer, and a second technical artist. They funded Starter Game, a complete playable level that brought the engine’s foundational systems together in one place, along with a budget for rendering demos.

I wrote the Getting Started Guide around Starter Game’s assets. Creators could move from guided exercises to a working game and see how each feature contributed to the whole. A reference manual became a path from first launch to real understanding.

Climax Studios built Starter Game, and I served as its creative director and game design director. That partnership ran on a daily rhythm: writing design and creative specs, reviewing proposals, playing builds, reviewing dailies, and turning feedback around quickly so their team never had to wait on ours.

None of it came from a single approval. Every delivery became the argument for the next one, and making that argument was part of the job every day.

What started as four people became a seven-person team directing a network of external studios. As the work matured, the company gave it two permanent homes. A dedicated tutorial team joined Documentation to carry onboarding forward. Creative Content moved into Marketing, where my team continued producing example content and demos that showed creators what the engine could do and how to do it themselves.

The idea that was once not now had become part of how Lumberyard taught and presented itself.

My role changed along with the work. I arrived as a product manager without a defined mandate, and I became creative director of the team I’d proposed, built, and shipped with.

Frostbite powers Battlefield, Madden, EA Sports FC, and many other high-profile games across EA. Its Example Content team sat within UX and Product, and after turnover and restructuring, four technical artists remained. The Director of UX and the Head of Product believed in the function and had fought to keep it. What they needed was someone who could define its role and make its value more visible.

Demand wasn’t the issue. Studio creators wanted better training, faster technical support, and features validated before they reached production. But the team had no mission, no defined scope, and no way to show impact beyond goodwill. It operated like a help desk: reactive, hard to see, and easy to cut.

My manager brought me in to rebuild it. My background fit what he needed: 18 shipped games, the creator onboarding I had led at Lumberyard, and years of making creative work legible to the people who fund it. The one new thing was managing technical artists. What leadership wanted most was a creator’s view of the engine: someone who would champion the artists and designers who use it, and rethink what a team like this could be.

I defined the team’s mission around three responsibilities:

• Feature validation and design support: work with product and engineering to make sure new features held up before release.
• Technical support: help studio creators with feature questions and workflow problems.
• Training and onboarding: build examples and tutorials, and keep the user guide aligned with how features actually behave.

Every request now had a test: which responsibility does it serve? That gave the team a way to prioritize, gave partners a clear picture of what to expect, and gave me the foundation for every future hiring case. I worked with product, engineering, and studio partners to agree on what success looked like in each area, so conversations about the team centered on outcomes instead of effort.

I paired technical artists directly with product managers and engineering leads. They validated features alongside the people building them, contributed to release documentation, and handled studio escalations. Their insight into workflows, usability, and real-world performance improved features before studios ever touched them.

Then I gave them room to run, and my role shifted to running the system around them: keeping scope and schedules on track, managing how each person’s time was spent, and owning planning with my peers in Product and Engineering. Monthly summaries and quarterly reviews showed leadership what the team delivered and whom it served, so the case for the team no longer rested on advocacy.

Growth came in phases, with each role tied to roadmap priorities and studio demand. One technical artist in a feature area became two, and in some areas, three or four.

Within two years, every team member was embedded with a specific engine feature area. Engineering teams that once hadn’t seen the need began asking for technical artists of their own, and the conversation changed from “why do we have this team?” to which area would get the next hire. Each year, product domains competed for the next round of technical artists. I gathered the data and set the priorities for which areas got them.

The team peaked at 24 in 2024. In 2025, it moved from UX and Product into Engineering. The function leadership once questioned was now built into how the engine gets made.

Defining the team’s role also laid the groundwork for its most ambitious project: a production system for the engine’s learning content (see Case 03).

Between 60 and 100 new content creators joined EA’s Frostbite studios each year, and most needed 9–12 months to feel production-ready. Studios had built their own onboarding, each solving the same problem in isolation. The few existing tutorials were dated and narrow. Examples were scarce: in a good year, the team produced fewer than ten.

A conservative cost analysis put the potential savings from faster onboarding in the millions. That created urgency, but faster onboarding is harder to fund than new product, and headcount was limited.

The obvious answer was more people. The real constraint was the process. Every example started from scratch, with its own visual direction, its own assets, its own documentation, and no reliable way to reach the people who needed it. Each example took 4–6 weeks. At that pace, no team size would close the gap. This was a systems problem, not a staffing problem.

A four-person team couldn’t build that system alone, so I looked for partners who already had the capabilities. Frostbite’s head of Documentation brought technical writers who could own the tutorials. EA Sports’ Technical Art and Design group, a large team serving creative and technical needs across the EA Sports franchises, brought designers, craft directors, technical artists, and project managers.

I proposed a joint strike team of Example Content and Sports Technical Art to build the environments, assets, and production pipeline. Documentation, a partner team, would write tutorials on those foundations, and I made sure their work followed Vanguard’s direction so creators got one unified experience. Defining the problem, designing the solution, and bringing leaders in both organizations to agreement took about a year, alongside the work of rebuilding my own team (see Case 02).

Vanguard launched with 16 people, including 12 from Sports. I served as producer and creative director, leading with a senior project manager, a principal technical art director, a senior craft director, and a senior lighting director.

Over the next 18 months, Vanguard grew to 28 people across animation, lighting, world building, procedural art, and visual effects. Together we built the system every example would run on: unified level files, a shared presentation and interaction model, visual direction guidelines, a reusable asset library, and documented workflows with checklists and templates, all linked to the engine’s user guide.

Making content was half the problem. Getting it to people was the other half. Creator Hub, a new Frostbite platform then in prototype, was the natural home, and I secured it as the release channel for our examples and tutorials. With a dedicated QA team and the engine release teams, we established a standard test plan and a quarterly release cadence that kept every example stable with each engine update.

Building got fast. Shipping stayed deliberate. A new example could be built in a day or two, then pass through a few hours of testing and integration before going out with the next release.

Vanguard launched more than 250 examples through Creator Hub, up from a pace of fewer than ten a year, alongside 20 new tutorials the Documentation team built on Vanguard’s levels and assets. The examples lived in 24 showrooms, each built around a domain such as physics, animation, materials, cinematics, or lighting, so creators could explore every example alongside related ones. Estimated onboarding time fell from 9–12 months to 6, with a plan in place to reach 3.

The bigger change came after launch. With the system in place, technical artists in each feature area worked directly with that area’s product and engineering directors to decide what new features needed demonstrating, and then built it. Every six months, another 10 to 20 examples joined the library. Learning content now followed the engine’s roadmap instead of trailing behind it. By 2025, the library held more than 300 examples, and the tutorial team, building on Vanguard’s levels, assets, and design direction, had grown its tutorials to more than 85.

The launch content had earned the Creative Content team its next phase (see Case 01). In planning with Product, Engineering, and Marketing, one request kept coming back: where is the high-quality rendering content?

Engineering was developing new rendering features, including temporal anti-aliasing, specular anti-aliasing, and order-independent transparency, as part of a partnership with NVIDIA. The engineers needed production-grade assets to test them against. Marketing needed something that would make developers see what the engine could do.

Both teams used the same words, but they meant different things. Engineering needed precision, fast. Marketing needed emotion and had time to get it right. A single demo would have served both poorly.

I split the request into two projects, each with its own goals, schedule, and production partner.

Bistro would be a technical showcase on a tight timeline. I listed the rendering features in development, mapped them to the surfaces needed to test against them (stone, wood, metal, and glass), and designed a Parisian street-corner café that brought those surfaces together. Success meant a scene that was demanding enough to prove the engineers’ work.

LOST would be a narrative short with a deliberately contrasting look: stark desert, natural stone, and dense forest. Success meant range and emotional impact, showing developers what they could create with Lumberyard, not just what it could render.

Both projects ran in parallel with the team’s other commitments. I drew on vendor relationships I’d built at Microsoft and Amazon Publishing: Elite3D produced Bistro, and Realtime UK produced LOST.

On Bistro, I was creative director and also led art direction while our art director was on leave. On LOST, I wrote the story and directed the piece. On both, I worked with the studios almost daily, writing specs, reviewing builds and dailies, and turning feedback around fast enough to keep two schedules moving.

Both demos debuted at GDC and were well received by developers and the wider community.

Bistro had a second life I never planned for. NVIDIA asked to distribute it, and Amazon donated it to NVIDIA’s Open Research Content Archive, a free library of production-quality assets for graphics researchers, announced at SIGGRAPH. Released under an open license, Bistro has since appeared in rendering tests across many engines and research projects, years after its debut.

I’ll admit I was against giving it away. I was wrong, and I’m glad I lost that argument. A scene built to test one engine became a shared resource for an entire field.