About Halcrow
The hard parts of
technology are my job
The unclear parts. The undefined parts. The projects nobody can quite get moving. That's where I work.
After 16 years and 253 companies, I know why software projects stall, rewind, and drift. It's almost never the technology.
It's distance. Between the people building it and the business it's for. Everything about how Halcrow works exists to close that distance.



Before technology, I spent ten years on large construction projects for clients such as Lendlease, Multiplex, Stockland, Grocon, the NSW Government. Construction taught me something software later confirmed: the work goes wrong in the distance between the people deciding and the people building.
In the 16 years since, I've led infrastructure projects, SaaS builds, enterprise transformations and early-stage products across 253 companies. After enough of them, the pattern is hard to ignore.
Projects don't fail because the technology is wrong. They fail because no one who's technically experienced is also accountable for the outcome (not the activity or milestones, the outcome) and close enough to the work to carry it there.
That's the gap I built Halcrow to close. Halcrow is how I think a technology partner should work.
I sit on your side of the table as your fractional CTO and I stay there. I don't sell the relationship and hand you to an account manager; the person who scoped the problem is the person accountable for solving it.
Behind me is a team of 26 software and cloud engineers and we've been doing this for over 16 years, so the judgement and the build come from the same place, and one of us answers for both.
We measure ourselves the way you do: did the number move, did the business change, would you make the decision again.
Plain language, honest calls (including the ones that cost us work) and outcomes over activity, every time.
Most consultancies finish projects. We solve problems. If that's the kind of partner you've been looking for (or the kind you were promised last time and didn't get) I'd like to meet you.

Sam Halcrow
Founder & Fractional CTO












Meet my team
I'm one of the only fractional CTOs that has a team of AI and software engineers employed with me
When I take on an engagement as a fractional CTO, I can bring engineers with me who can build what we decide on.

Gaofeng Wang
Gaofeng operates at the strategic layer of product delivery: roadmap sequencing, stakeholder alignment, and the decision of what gets built versus what gets deferred. He has been the PM on projects where scope had drifted significantly from the original objective, and the job was as much about stopping work as directing it.

Saif Wang
Saif works at the boundary between what the business needs and what the engineering team can deliver. He has held the Product Owner role in Salesforce implementations, custom SaaS builds, and enterprise platform projects — managing backlogs, writing acceptance criteria, and being the person engineers can actually get a decision from before the sprint ends.

Nikki Hao
Nikki manages how Halcrow's work and thinking reaches the market: case studies, guides, and the content that helps our clients recognise their delivery problems before they become expensive ones. Not client-facing in engagements, but she's the reason you found us.

Monk Gao
Monk specialises in production-grade API and data infrastructure across AWS, Azure, and GCP. He's been the first engineer into projects where the offshore build was unmaintainable and the last one out once the system was stable and owned internally. Comfortable with legacy codebases, greenfield architecture, and everything in between.

Sebastian Too
Seb has been embedded as Product Owner on projects where the original PO was too removed from the daily build to keep the backlog accurate. He brings the commercial context engineers need to prioritise correctly and the technical literacy to write requirements that don't require three rounds of clarification before work starts.

Shuwen Wang
Shuwen has eight years of experience shipping backend systems across fintech, logistics, and enterprise SaaS. Brought in when architectural decisions have been deferred too long and the technical debt is starting to determine the roadmap, she builds things that hold up — and documents them so they don't walk out the door when the engagement ends.

Dacheng Gao
Dacheng builds production web and mobile interfaces across React, Vue, and React Native. He has delivered frontend codebases from scratch and inherited ones that needed significant remediation. He works directly with product and UX so the gap between what was designed and what gets built is closed before the demo, not after.

Min Song
Min Song focuses on the parts of the frontend that determine whether users actually adopt what's been built: performance, accessibility, and the fidelity of the interaction model. She's been inside projects where technically complete software failed because the interface didn't match how real users work, and knows how to prevent it.

Shawn Shang
Shawn has designed across B2B SaaS, internal tooling, and consumer products. He's brought into projects where user requirements have been assumed rather than understood — and where the gap between what the spec said and what users actually needed is only discovered after months of build. He works directly with engineers so designs are tested against implementation reality, not just in Figma.

Lei Chen
Lei Chen is embedded in teams that are working but not delivering predictably. He sets up and runs the ceremonies — standups, sprint planning, retrospectives, backlog refinement — until the team has the muscle memory to run them independently. He's reduced sprint velocity variance from over 40% to under 15% across multiple engagements by fixing the delivery structure, not the people.

Hongxiao Zhang
Hongxiao works on the infrastructure and security layer that most projects underinvest in until something goes wrong. He's been embedded in teams where cloud architecture was set up fast and never properly revisited, and where security controls came too late in the build. He designs and implements infrastructure built to scale and secured from the ground up.

Vince Ge
Vince has experience running delivery for teams that span in-house developers, offshore contractors, and client stakeholders simultaneously — the model where communication overhead is the primary cause of delay. He knows which ceremonies to run, which to cut, and how to create a delivery rhythm that holds under the pressure of real client deadlines.

Zhixiang Gao
Zhixiang builds the test coverage that projects skipped on the way to launch and are now paying for in production incidents. He's been embedded in projects mid-build to establish automated test suites, define acceptance criteria, and create the quality baseline that lets the team ship with confidence rather than hope.

Mingfei Xia
Mingfei specialises in the point where a project is nearly complete but nobody can determine what "done" actually looks like. He brings a structured approach to acceptance testing, regression coverage, and release readiness that gives both engineers and product stakeholders a single honest answer about whether the software is ready to ship.

Yunfeng Song
Yunfeng builds and operates the infrastructure layer that determines whether a product runs reliably in production or becomes a source of incidents. He has migrated legacy on-premise systems to cloud, established monitoring and alerting where there was none, and structured deployments so that shipping a release is a routine event rather than an all-hands exercise.

Le Li
Le embeds in projects where testing has been an afterthought and where that's now showing up as bugs in production and releases that slip. He builds the test coverage and processes that should have been there from the start, working closely enough with developers that quality becomes part of how the team builds day to day.

Zhicheng Fu
Zhicheng builds backend systems that need to work reliably at scale, in production, under real load. He's been brought into projects where the architecture made sense early on but couldn't carry the weight of what the product became. He knows where the structural problems usually hide and how to fix them without pulling everything apart.
Benefits of working with me
You need someone making the calls a CTO makes, without the CTO-sized cost

You'll get the systems a CTO builds
Without a CTO, technical decisions happen ad hoc. I set up the right systems and structures so your team always knows what to do next, who owns it, and how it gets decided.

You'll have a conduit between business and tech
I sit between your business goals and your technical team, translating one into the other, and I own the calls I make rather than just advising on them.

You'll be working with today's technologies
I stay across what AI, project tools, and no-code platforms can actually do right now, so you're not building on approaches that were current two years ago.

You'll avoid the issues that stall most tech projects
Blown timelines, AI projects that ship but change nothing, running out of money before launch... Most problems come down to systems, not skill.

You'll see how smoothly your project can run
Things go out regularly, decisions get made quickly, and you spend your time on what matters most instead of approving every small change.
Track record
This is the experience I bring to your company
- 253 companies I've stepped into as a fractional CTO
- 253 companies
- I've been leading technology projects for over 16 years
- 16 years
- One million engineering hours delivered under my technical leadership
- 1,000,000 hours
















Principles
Four principles behind every project
Be in the room, not on the sidelines
Advice from a distance doesn’t fix anything. I’m always right there with you.
Tell the truth, even when it's awkward
If something's not working, you'll hear it from me before you find out the hard way.
Capability close to the problem
The right person solving the right thing, not a committee solving the wrong thing.
Build it properly or don't build it
Shortcuts cost more later than they save now.
Manifesto
What I believe about tech delivery after 16 years in this work
Technology should deliver business outcomes. Always.
There are a few laws that almost every technology initiative has to obey if it's going to do that.
Someone has to own the outcome, not just the output. Decisions have to be made by people who understand both the business and the technology. And the team doing the work has to be led by someone with enough experience to know what good looks like.
Most organisations break these laws, but not deliberately. The models they rely on are just built that way.
Consultancies are accountable for deliverables. Agencies are accountable for scope. Internal teams answer to whoever hired them, which is often someone without the technical authority to hold them to the right standard. These models aren't designed to produce what the business actually needs from its technology.
So initiatives drift, vendors go unmanaged, engineers work hard on things that don't move the business forward. Roadmaps lose their connection to where the company is actually going. And when the board asks a hard technical question, nobody in the room can answer it with real confidence.
I've seen this pattern across 253 companies. It's rarely the team's fault. Almost never, in my experience.
What's missing is one role. An experienced technical leader who owns the direction, leads the team, manages the vendors, makes the calls, and is accountable for whether the technology delivers what the business needs. Not accountable for whether the project finished. Accountable for whether it worked.
Most companies don't have that person. Hiring a full-time CTO is a serious commitment, and the wrong hire is a slow, expensive problem to fix. So the role stays empty, or gets filled by someone without the experience or authority to do it properly. And the gap quietly costs the business more than anyone realises.
That's the problem Halcrow was built to solve.
I step in as a fractional CTO. Inside the business, doing the work. I've worked with the same engineers for years. When the engagement needs a team, they come with me. We've built enough together that we don't need time to figure out how to work with each other.
Sometimes I'm brought in after something has already gone sideways. Sometimes before anything's been built. The work is the same either way: fill the role that's been missing and make sure the technology actually delivers what the business needs.
The people accountable for the technology should be inside the business doing the work. That's what I believe. That's why I built Halcrow.
Ready?
After our first meeting you'll leave knowing what to do next
Visit my office in Surry Hills

Meet on a video call
