Built and led backend & DevOps teams

I led a team of up to 13 developers and DevOps engineers, driving project development across PHP and Go for a high-traffic e-commerce platform - and, in parallel, took over DevOps as a function that needed to exist rather than a function that already did.

Two jobs at once

The formal titles were Team Lead Software Engineering and Tech Lead DevOps, and the honest description is that these were two different jobs with two different time horizons sharing one person.

Software engineering leadership at Myposter was delivery-shaped: a high-traffic consumer platform with a roadmap, seasonal peaks, and a business that needed features to land when it said they would. DevOps leadership was capability-shaped: the work was to build practices that would still be working after I stopped paying attention to them.

Those two horizons compete. Delivery pressure is immediate and legible; the cost of skipped platform work shows up months later and never has an obvious owner. Holding both meant being explicit with the business about which one I was trading away in any given quarter, rather than quietly borrowing from the platform to make a date and hoping nobody noticed.

The constraint: real traffic, real seasons

A consumer print and photo e-commerce business has a load profile you cannot argue with. Traffic is seasonal and the peaks are the revenue. That has two consequences for how you lead engineering.

First, the deploy pipeline is a production risk in itself. A platform that ships confidently in March and freezes in November has not solved deployment, it has scheduled its fear. Second, capacity work has a deadline set by the calendar, not by the roadmap - which is oddly useful, because it makes platform investment legible to the business in a way that “reduce technical debt” never is.

Decisions and tradeoffs

PHP stayed; Go was additive. The platform was PHP and it worked at real traffic. Go went where its concurrency model earned its place, and nothing was rewritten to be modern. A team of 13 that starts a language migration in a high-traffic system spends years in the worst of both worlds, running two implementations of the same thing while shipping nothing new. The tradeoff is that we carried two ecosystems and two sets of tooling, and that it narrowed hiring: we did not recruit separately for PHP and for Go, we looked for people who already had both or who actively wanted to pick Go up, which is a smaller pool than either language on its own. Cheaper than the alternative, but not free, and I would not recommend it to a smaller team.

Building the DevOps practice, not a DevOps team. The distinction mattered. A DevOps team that owns deployment becomes a queue, and a queue between engineers and production is how you get engineers who do not feel responsible for production. I invested in CI/CD, infrastructure, and the practices around them so that product engineers could deploy their own work safely. The cost is that this is much slower to establish than centralizing the capability, and it requires believing that engineers will use the tools well.

DevSecOps as a default, not a gate. I came to this role directly from building a security scanner, having watched from the vendor side what happens when security arrives as an audit at the end. Putting it in the pipeline is less satisfying than a review board and considerably more effective, because it changes what engineers do rather than what they are told about.

Engineering and BI as one collaboration, not a handoff. I owned that relationship directly. In e-commerce, the numbers are the product decisions - conversion, basket, fulfilment cost - and a reporting layer built at a distance from the systems that emit the events is a reporting layer that is subtly wrong in ways nobody catches for a quarter.

Outcome

Service development and a DevOps practice were established as durable capabilities of the organization: CI/CD, infrastructure ownership, and security in the pipeline, with product engineers able to ship to a high-traffic platform themselves.

What I would do differently

Separating the two roles was never mine alone to decide. We were actively looking for a DevOps lead, but two priorities did not align: mine was freeing up the time so that platform work got a first-class share of attention, and the company’s was not paying a second salary for a job that was visibly getting done. That is a defensible position for a business to hold, and it is also why DevOps kept getting the attention left over after delivery - exactly backwards for the function whose whole value is compounding.

What I would push harder on is making that tradeoff legible while it was still live, rather than absorbing it. Doing the job well is precisely what makes it look like it does not need a dedicated owner. Inside the constraint I did my best work and the practices held; but the case for the hire lands better when the cost of not making it sits on the table, rather than in my calendar.