Guest
VP of Engineering at Zen Educate
“Software engineers at Zen Educate are problem shapers. They’re not ticket takers.”
That line from Martin’s job postings caught my attention. What does it actually mean to transform engineers from implementers into shapers? Martin walked me through the journey.
The Full Circle Journey
Martin started in the film industry, building technology for visual effects. There were no product managers or designers. Software developers figured things out by talking directly to artists and supervisors.
“I kind of started almost naturally in that go talk to people, understand the problems that they have and then sort of slowly try to build a solution from there.”
Then he joined Intercom, known for being product-led, and found people who shared his approach. Having product managers and designers wasn’t about removing ownership from engineers. It was about acceleration.
“It’s very hard to be great at everything. So if you’re there as an engineer and as a product engineer, you care about the experience and all, but you just might not have the skill, the time to go deep in those areas. So having these other people that you could suddenly pull on and leverage was really great.”
The Frustration of Being a Ticket Taker
What’s wrong with the traditional model? Martin put it simply:
“You never really understand what you’re doing and why. You’re sort of, it’s just an endless sea of requests. Eventually, the new tech becomes mundane, the chasing new tech becomes a bit less of a dopamine hit. And so you start to think, well, where else am I getting my fulfillment?”
When multiple stakeholders disagree about priorities, the engineer becomes the point where all that tension collides. No opinion of your own, just trying to satisfy everyone.
“Not only are you not getting that fulfillment in understanding, but you’re also being torn in many different directions. That’s very draining.”
The word I keep hearing from engineers is impact. The ones who are unsatisfied don’t feel like they have any.
The Transformation at Zen Educate
When Martin joined Zen Educate, they were close to the ticket-taker model. PMs wrote tickets, assigned them to engineers, and engineers had to get approval before shipping.
“That’s just all very slow, but also quite not fun for engineers.”
The shift involved engineers in problem definition from the start. Now when a PM identifies important problems, engineers are in the room asking: Why do we think this is the problem? Have we defined what success looks like? Is there actually a different problem here?
Same with design. When a designer ideates on solutions, engineers help figure out what’s feasible, what can be built faster using existing infrastructure, what would delay getting value into users’ hands.
“We still got today quite a linear process where there’s problem definition, solution ideation, technical assessment, and implementation. But with the engineers that have really embraced this product engineering mindset, those loops and feedback loops are getting tighter and tighter.”
Some teams take this even further, running daily sprints and treating everything as experiments rather than features.
The Definition That Stuck
Martin shared his one-line definition of a product engineer:
“It’s someone who loves solving real problems for users and just happens to be skilled at leveraging technology to do that.”
The difference from a traditional engineer is that the product engineer focuses first on the problem, not the technology. They’ll solve it with code most of the time, but sometimes they won’t.
“The mark of a product engineer is someone who solves a problem sometimes by not building anything.”
What Actually Changed
The mechanics matter. Zen Educate built a six-week process with problem definition and scoping in the first couple weeks, solution design in the middle, technical assessment, and then implementation.
“We’ve actually created quite a lot of lead time in the process. That’s how we tackled the main challenge of laying the tracks far enough ahead that the team can run at it well.”
They also experimented with engineers partnering directly with commercial leaders, skipping the traditional product hierarchy entirely. One engineer paired with an account manager to spike out a solution before a full team took it on.
“That’s been very successful and also a lot of fun for everyone, especially on the commercial side who suddenly get a closer glimpse of what does it mean to actually build something and iterate on it.”
The Constant Reinforcement
The biggest challenge isn’t process. It’s permission.
“The thing that’s maybe obvious and simple is the need to constantly tell people and reinforce that you can do this.”
Engineers coming from traditional environments are nervous. Am I stepping on the PM’s toes? Am I allowed to ask these questions?
“Making that okay and safe and re-emphasizing continuously that no, as a team this is how we do better. And actually, the PM is gonna thank you because they’ve got a lot to do.”
Then there’s the skill gap. Some engineers have never thought about user problems this way. They haven’t understood the commercial aspects of the business.
“It’s okay to not know. It’s okay to get it wrong. If we’re giving you the ability to have more influence, more impact, we’re not also expecting you to nail it first time.”
Scaling the Culture
I asked Martin how this scales. His answer: constant effort.
“Anyone who says ‘I’ve got the culture now and it will stay forever,’ that doesn’t work. You have to work at it every day in how you show up, how others show up, what you recognize and reward.”
The dangerous zone is the messy middle, when you’re too big for the founder to talk to every engineer but too small for autonomous groups to maintain culture on their own.
His advice for leaders wanting to adopt this model:
Challenge yourself on why. If it’s just because you read about it and it looks cool, it’s probably not going to work.
Write it down. Use AI to stress-test your thinking. What would an engineer think reading this? What would a CEO think? Find the trade-offs. If you can’t find any, you haven’t thought hard enough.
Find champions. There will always be engineers who naturally get it. Back them, amplify their successes, and provide cover if needed.
“First and foremost, you got to understand why you’re doing it yourself.”
