Projects

Trimble / CTCT · 2024 to present

Global engineering software programme leadership

Leading engineering and software delivery across approximately 13 cross functional teams in New Zealand, India and the United States. The role aligns embedded systems, platform software, hardware, integration and release planning across organisational and time zone boundaries.

Programme and public product scale

≈ 13

cross functional teams coordinated

3

countries supporting delivery

6

major machine categories

120 +

supported excavator models

Diagram of a Trimble machine control system with a cab mounted display and connected positioning hardware
Engineering software Trimble / CTCT

Role

Senior Engineering Project / Program Manager

Christchurch, New Zealand · Global delivery

Challenge

Interdependent software, embedded, hardware and integration work had to move as one programme across global teams, two multinational parent organisations and multiple technical disciplines while maintaining visibility at the interfaces.

Outcome

Reusable planning, dependency, risk, decision and reporting systems improved programme visibility, stakeholder communication and delivery predictability across interdependent work.

Software development Programme leadership Global delivery Systems integration Release planning Risk & dependencies Stakeholder leadership Technical product context

The programme context

My current work sits where software development, embedded systems, machine hardware and real construction environments meet. The public product context is advanced grade control technology: systems that combine digital site designs, precise positioning, in cab software and machine control to help construction equipment work accurately against a model.

What grade control does

Grade control helps an operator move earth to match a digital design. GNSS, commonly called GPS, establishes the machine’s position on the site. Sensors track the geometry and movement of the blade, boom, stick or bucket. The onboard computer combines those measurements to calculate where the cutting edge is and how far it sits above or below the target surface.

The result is shown to the operator as cut and fill guidance on an in cab display. On supported machines, the system can also control hydraulic functions to help hold the required grade. Trimble provides a useful public explanation of how these positioning, sensor and design inputs work together.

Grade control itself predates Trimble. Laser based systems appeared in the 1960s. Trimble’s public history shows that the company later helped pioneer the GPS and RTK technologies that enabled modern 3D machine control, including its first stakeless GPS grade control system in the 1990s. The Trimble machine control history provides the wider timeline, while its RTK history describes Trimble’s role in bringing centimetre level positioning into practical commercial use.

Within that environment, I lead programme delivery across approximately 13 cross functional teams in New Zealand, India and the United States. The work spans organisational and time zone boundaries in a joint venture setting linking two multinational parent organisations.

The internal programme, product roadmap and technical architecture remain confidential. What can be shown publicly is the delivery problem: coordinating multiple engineering and software workstreams so that interdependent parts are planned, integrated and prepared for release as one system.

Public product scale

Trimble makes its Earthworks software available globally through the worldwide SITECH distribution channel. The public product portfolio covers six major machine categories: excavators, dozers, motor graders, compactors, wheel loaders and compact machines.

Trimble also states that its aftermarket automatic system can support more than 120 excavator models from 13 manufacturers. These figures describe the publicly documented reach of the product platform. They do not disclose internal sales, customer or roadmap information.

My role

My focus is software development project and programme management. I create the structure that enables specialist teams to make sound decisions and deliver together without flattening the technical complexity of their work.

That includes:

  • integrated programme and release planning across software, embedded, hardware and integration work;
  • dependency management across teams, components and organisational boundaries;
  • risk, issue, decision and escalation systems that keep ownership visible;
  • stakeholder leadership and reporting across countries and time zones;
  • translating technical detail into clear programme level choices and communication;
  • improving the quality and cadence of planning conversations; and
  • keeping technical dependencies, decisions and delivery feedback visible across the teams responsible for software and system behaviour.

I am not trying to substitute programme process for engineering judgement. The job is to create enough shared context, sequencing and decision discipline for engineering judgement to operate effectively across the whole programme.

A programme operating system

Large technical programmes become difficult when each team can see its own work but no one has a dependable view of the interfaces. A local decision can change another team’s integration sequence, test schedule, release confidence or system readiness.

I developed reusable planning, dependency, risk, decision and reporting systems to make those interfaces visible. Together they form a practical programme operating system:

  1. Plans establish the delivery logic: what has to happen, in what sequence and with which assumptions.
  2. Dependencies expose the interfaces: where one team’s progress or decision affects another.
  3. Risks and decisions create ownership: what needs attention, who owns it and when escalation is necessary.
  4. Reporting creates shared situational awareness: a consistent view for technical leads, delivery teams and senior stakeholders.
  5. Integration results close the loop: test outcomes and system behaviour become visible, allowing lessons to inform planning and development.

The value is not additional administration. It is better visibility, earlier conversations and more predictable delivery across work that cannot succeed in isolation.

Software development leadership

Software delivery in a machine control environment is inseparable from the system around it. A feature may depend on embedded behaviour, positioning inputs, machine configuration, hardware availability and test infrastructure. Release planning therefore has to account for more than code completion.

My technical background helps me work comfortably at those interfaces. I can move between programme controls and detailed engineering conversations, ask useful questions, recognise dependencies across systems and help teams turn uncertainty into an executable plan.

The leadership challenge is equally human: creating clear forums, useful artefacts and communication standards for a large group of specialists distributed across locations and organisations. Strong programme management gives those teams a common operating picture while preserving clear technical ownership.

What this demonstrates

This programme demonstrates leadership of complex software development in a multidisciplinary engineering setting: global teams, interdependent technologies, organisational boundaries, release and integration planning, and senior stakeholder communication.

The central lesson is that delivery predictability comes from making the interfaces visible. When teams share a reliable view of dependencies, decisions, risks and technical results, they can solve difficult technical problems with greater confidence and fewer late surprises.

Public context: Caterpillar and Trimble’s longstanding CTCT joint venture and its grade control focus.