From zero to a shipping team
A product to build and no team yet. I work out the first slice of scope, hire the people to build it, set how the team works day to day, and get a first release in front of real users.
Engineering & Project Manager
For over a decade I've built software and, for the last five years, led the teams that build it. What I enjoy most is starting something from nothing: forming the team, getting the first release out, and growing the people around it until the project runs well without me.
Cluj-Napoca, Romania · Remote across Europe/US
Start from nothing, and leave behind a team that doesn't need me.
My best work has usually started with an empty repository and a brief that wasn't finished yet. Someone has a product to build, a budget to justify, and no team to do it with. I like that part: deciding what to build first, finding the people to build it, and getting something real in front of users before the plan has a chance to go stale.
The half that matters more is what happens next: growing the team while it delivers, so the tech leads make the calls, the way we work is transparent enough to be questioned, and nothing important lives only in my head. When I leave, the project should be in better shape than I found it, and the people should be further along than when we met.
A product to build and no team yet. I work out the first slice of scope, hire the people to build it, set how the team works day to day, and get a first release in front of real users.
A new platform, end to end. I carry scope, budget, risk and the customer conversation, and leave the architecture decisions with the engineers who will have to live with them.
The point where one team stops being enough. A second layer of leadership, tech leads who genuinely own their areas, career paths that mean something, and hiring that doesn't quietly lower the bar.
For products people use at all hours: on-call, incident response, and the operational habits that stop reliability and feature work from fighting over the same hours.
The part that decides whether any of the rest mattered. Decisions written down instead of carried in my head, tech leads who stopped needing me a while ago, and a way of working transparent enough that whoever comes next can pick it up without a rescue mission. I would rather be unnecessary than indispensable.
Numbers are the shorthand, not the point. Behind each of these is a team that ended up better at its job than it started, and a handful of people who moved on to something bigger.
I'm a software engineer at heart, six years hands-on before the last five leading people and projects. That background is why I can lead a team without getting in its way: fluent enough to earn engineers' trust, senior enough to let them own the hard calls.
Over the past year I ran two engagements in parallel (an Engineering Manager role and a freelance Project/Engineering Manager contract), leading delivery across both organisations at the same time.
I don't centralise decisions. I empower tech leads to own the technical direction and act as their sparring partner. My job is to make the team ship well and grow, not to be the smartest person in the room.
Leadership through trust, transparency & psychological safety
Structured around your need
Currently taking on new work, up to and including a full-time engagement. Tell me what you are trying to build and I'll tell you honestly whether I'm the right person for it.
Who I work best with
Leads teams across
Education
Tell me about your team and where delivery hurts.
Whether you are starting something from nothing, growing a team past the shape it began in, or planning a handover you want to go well, let's talk.