I've spent 20 years building engineering teams. Here's what I've learnt.
I'm Mark Grebler, an engineering leader based in Melbourne, Australia. I work with engineers, engineering managers, and founders to build high-performing teams and the cultures that sustain them.
How I think about engineering leadership
I've been asked "how do you lead?" more times than I can count. For a long time I found it a hard question to answer, not because I didn't have a view, but because I'd never had to make it explicit.
When I did make it explicit, it came down to something fairly simple: people perform best when they understand the purpose of their work, feel safe to speak up and take risks, and are given the space and support to grow. As a leader, your job is to create those conditions. Everything else — the processes, the frameworks, the delivery practices — sits on top of that foundation.
That sounds straightforward. In practice, it's anything but. Building genuine psychological safety takes time and consistency. Getting a team aligned around a clear purpose requires more than a vision statement. Creating an environment where people feel safe to fail and learn from it means modelling that behaviour yourself, repeatedly, in ways that are visible to the team.
I've spent 20 years doing this work, getting it wrong sometimes, learning from it, and building a clear point of view on what actually makes a difference. That's what I bring to every engagement.
My background
I started my career as a software engineer, which matters. I've written code, shipped products, and dealt with the real constraints that engineering teams work under every day. When I talk to engineers about technical challenges, they know I understand what I'm talking about — and that trust is the foundation of everything else.
Over time I moved into engineering leadership, and for the past eight years I've been the peak technology leader (CTO or Head of Engineering) at a series of Australian tech companies. Each of those roles has involved the same core challenge: taking an engineering function that is struggling in some way and building it into something that performs.
-
2025 to 2026Informed Decisions (.id) — Head of Product Engineering
Grew the product engineering department from 7 to 12, developed the company-wide operating cadence including OKRs, and supported the technology due diligence that led to a successful sale of the business.
-
2020 to 2024EstimateOne — CTO and Head of Development
This is the role I'm most proud of. Over four years, I grew the engineering team from 7 to 50 people, contributed to 220% revenue growth, introduced containerisation, microservice architecture, and a data mesh, built the EstimateOne Engineering Growth Framework, and led a significant uplift in security posture. EstimateOne was recognised as one of Australia's best technology workplaces during this period.
-
2018 to 2020Focus HQ — Head of Engineering
Built a local Melbourne engineering team from scratch, transferred ownership of a five-year-old codebase from an offshore team in Vietnam, and achieved SOC2 Type I compliance.
-
2014 to 2018Aconex — Engineering Manager
Led the delivery of a brand new big data analytics product from inception to general availability, and pioneered the first fully AWS-hosted product at the company, managed entirely by the development team.
-
Earlier rolesSoftware engineer and development lead
Before moving into leadership, I worked as a software engineer and development lead at CAE Professional Services Australia, primarily on defence projects at the Defence Science and Technology Organisation. I also consulted as an EAI technical analyst at Oakton. I hold a dual degree in Software Engineering (Honours) and Commerce from the University of Melbourne.
What I believe
A few things I've come to believe strongly over 20 years of building engineering teams:
Culture is the foundation, not the wallpaper.
Most companies treat culture as something you document and display. The teams I've seen perform best are the ones where culture is something you can see in the behaviour of the people, particularly the leaders. If the leader doesn't embody the culture, no one else will either.
The best engineering leaders multiply, they don't just contribute.
The shift from being a great individual contributor to having impact through others is the hardest transition in an engineering career. Most engineers who plateau aren't being held back by their technical skill — they're being held back by not having made that shift.
Alignment beats process.
You can introduce the best agile frameworks in the world, but if the team doesn't understand the purpose of their work and the problems they're trying to solve, the frameworks won't save you. Get the alignment right first, and the process becomes much easier.
People need to feel heard before they'll commit.
Psychological safety isn't a nice-to-have. It's the precondition for everything else: honest feedback, genuine collaboration, experimentation, learning. Without it, you get a team that nods along and then does what they were going to do anyway.
My writing and thinking
Alongside my work, I write about engineering leadership, culture, and delivery. My writing is collected on Substack, where I've published a five-part series on building engineering culture, as well as pieces on leadership, high-performing teams, agile estimation, and the EstimateOne Engineering Growth Framework.
I've also given talks on agile development, DevOps maturity, and learning — available on YouTube — and have published slide decks from some of those talks on SlideShare.
Let's talk
If you'd like to work together, or just have a conversation about engineering leadership, I'd be glad to hear from you.