Introducing Greg Reczek
You joined us after running your own business and then moved in-house. What convinced you that this was the right next step, and what’s been the biggest shift for you personally?
Running my own business gave me broad experience and a lot of autonomy. Over time, though, I had already begun stepping back from the day-to-day operations – delegating delivery and operational responsibilities to the team so I could focus more on strategy and technical direction. That shift was happening well before Amodal.
The business is still operating, but it now runs with far less direct involvement from me. That gave me the space to think carefully about where I could add the most long-term value.
Amodal becoming our largest and most strategic client made the decision clearer. The platform’s scale and ambition created an opportunity to build something meaningful and long-term rather than working across multiple shorter-term engagements. Mike was, of course, very persuasive – but ultimately it came down to impact. I could see the potential to build a strong, structured engineering function with real ownership and continuity.
It wasn’t an easy decision. Moving in-house meant committing fully to one mission. But the opportunity to shape the development function properly – investing in people, quality, and sustainability – felt like the right next step.
The biggest personal shift has been moving from delivery-focused thinking to capability-focused thinking. I now spend more time designing how we build, not just what we build.
As Head of Development, what problems do you enjoy solving most day-to-day, and which ones still keep you thinking after hours?
Day-to-day, I most enjoy solving structural problems – improving quality, refining workflows, reducing friction between development and deployment. I enjoy taking something slightly chaotic and turning it into something structured, predictable, and scalable.
Over the past year, the team has grown significantly. That growth required us to define clearer processes: pull request standards, release discipline, review practices, and stronger separation between development and production environments. Moving from speed-first delivery to quality-led delivery has been a big focus – not slowing down, but building in a way that reduces rework and long-term cost.
The problems that stay with me after hours tend to be architectural and strategic ones:
- How do we maintain quality as we scale?
- How do we balance innovation with stability?
- How do we ensure we’re building things that will still make sense in three years?
Those are the kinds of challenges I enjoy – the ones that shape direction, not just output.
When you think about your role day to day, what part of it do you genuinely enjoy getting stuck into?
I genuinely enjoy improving systems – whether that’s technical systems or team systems.
On the technical side, I still enjoy diving into architecture discussions, reviewing complex pull requests, or refining how our environments are structured. I like making things cleaner, clearer, and more resilient.
I also deliberately make space to explore improvements using AI tools. I see AI not as a replacement for engineering thinking, but as a multiplier. Whether it’s accelerating prototyping, improving code clarity, assisting with documentation, or reviewing logic, it allows us to move faster without compromising standards. I enjoy experimenting with how these tools can enhance productivity while still maintaining strong human oversight.
On the people side, I enjoy mentoring and setting standards. Watching the team mature – seeing developers take more ownership, challenge assumptions, and improve code quality – is rewarding.
Looking back over the past year, what’s one moment or decision that best reflects how the development function has evolved since you came on board
The clearest shift has been our move from speed-driven delivery to structured, quality-led development.
Early on, much of the focus was on shipping quickly – which made sense at the time. As the team grew and Endev-o platform became more central to the business, we had to evolve.
One defining moment was formalising our development and deployment processes – introducing clearer branching strategy, stronger review standards, and more disciplined releases. It wasn’t flashy, but it changed the culture. It signalled that we’re building for longevity, not just velocity.
Alongside that, the introduction of AI-assisted coding has made a significant difference to productivity. Used correctly, it allows us to prototype faster, analyse issues more efficiently, and reduce repetitive effort – while still keeping strong review processes in place. It hasn’t replaced engineering judgement, but it has accelerated it. That shift has meaningfully improved output without lowering standards.
The evolution hasn’t been about slowing down. It’s been about building in a way that compounds – where every release strengthens the foundation rather than adding fragility.
Contact us today
Discover how Amodal can help you deliver safer, smarter, and more compliant projects and assets.