Full Stack Developer · Industrial Placement

Why I joined

I joined Elanco’s global digital team on my industrial placement year. What drew me in was the chance to add real value. Elanco isn’t a tech company, which meant a developer wasn’t one of hundreds: you were the person in the room who knew how the web worked, and good ideas could actually change how the business ran. The team I joined was effectively the innovation team for the company’s web presence, looking for better ways to run marketing sites, user experiences and the architecture underneath them.

I’d been told that your career really starts with your placement, and to pick a job that builds the skills you want to grow rather than one where you simply code all day. Elanco looked like that kind of job. It turned out to be.

The role

On paper I was a full-stack developer. In practice the role was whatever the platform needed next: writing standards, building tools, running workshops, documenting, and later leading a migration.

The working environment asked a lot of independence of me. Nobody checked in every day, so I planned and prioritised my own work, often around colleagues in the US and Australia. When lockdown arrived, that independence became the whole job. When my placement ended, COVID and Elanco’s fully remote policy meant I could carry on at almost full time through my final year at university, essentially from my dorm room, alongside my studies and my dissertation.

What I built and led

The full story is in Building a Web Platform for 80 Sites. In short, the work came in layers:

• Standards. I wrote the web development standards for the team: which React versions to use (and where Preact made sense), and when to build on Next.js versus Gatsby.
• A paved road. Standards documents get ignored, so I turned them into a Web Accelerator, a boilerplate with the decisions already made, and wired it into the company’s self-service portal so teams could provision a new project themselves.
• The road to production. I set up the deployment architecture so every new site shipped the same way.
• Shared components. I brought in Storybook to hold a shared component library and applied it across the estate.
• The CMS migration. I worked on the move to a headless CMS, including content and media migrations in TypeScript and GraphQL, then stayed on as lead developer to see it through, coordinating more than a dozen onshore and offshore developers.
• A resumable migration tool. To move whole sites off other CMS platforms, I built a Node.js tool that exported content to disk, queued it, streamed it across in batches through adapter layers and could resume after failures. It became open-source tooling and a guest post on Kontent’s blog (A Resumable CMS Migration Tool).

The highlight, and the biggest challenge, was a week-long workshop in Manchester. It was a critical week: the team had to agree how a whole set of marketing and web processes would work and plan the next six to twelve months. I ran my own sessions. Because I was standing up several of the platforms involved, it was my job to explain my vision for how they’d integrate and to bring people with me. Getting a room of people across regions to sign up to an approach was a very different skill from building it, and it was the first time I’d had to do it.

About six months later, everything I’d talked about in those sessions had been stood up. More than 30 of our websites, including the main company site, had been migrated and renovated on the tools and platforms I’d played a major role in. Seeing a plan from a workshop room turn into live sites taught me more about leading change than anything I’d read.

Results

• Components shared across around 80 active sites, and the estate consolidated into three main company sites.
• New projects starting from a self-service template instead of a blank page.
• Within about six months of the Manchester workshop, more than 30 sites, including the main company site, had been migrated and renovated on the tools and platforms I’d helped build.
• The CMS migration delivered, with documentation that outlived my time on the team.

What I learned

Looking back, this was platform engineering before I had the words for it: a golden path, self-service provisioning and a shared component layer in a supporting domain (Golden Paths, Where Platforms Fit: DDD Subdomains). I also learnt that documentation is part of the product. The approach only scaled because people who had never met me could pick it up.

It’s also where my thinking about leadership started. I was given The Five Dysfunctions of a Team there, and used it to think about team dynamics on a large, distributed team and what kind of leader I wanted to be, long before I had the title. And it’s where I first saw Building Digital Culture’s argument in practice: the tooling only worked because habits changed with it.

Why I moved on

Each of my moves has been a step into more responsibility, and this was the first. Two things came together when I graduated. I was settling down in Kent, and the office was simply too far away to make sense long term. And the role wasn’t going to keep pace with what London-based roles could offer someone at my stage.

The extra year of real experience changed the options. I could skip junior roles entirely, which is how I ended up at Accedo building TV apps straight after university.