Ideas from the
work itself.

Growth and change need different leadership moves.

I have been brought in to help businesses grow, and to keep delivery moving while the organisation around them changed. The skills overlap. The job is not the same.

When a company is growing, the question is often how to add people and capability without making every decision slower. That can mean building a management layer, giving teams clearer ownership or making sure the platform can carry more demand.

During a restructure, the questions are different. What must keep working? Where is effort being lost? Which responsibilities need to move? People still need to ship, support customers and make sound technical decisions while the answers are worked out.

I have worked in both situations. In one, the business needed more leadership capacity as its workforce expanded. In another, engineering had to change shape while protecting customer delivery and platform reliability. Neither story is captured by saying "transformation".

Start with what the business needs next.

Sometimes the right answer is to build: add a team, invest in a capability or make room for a new product. Sometimes it is to simplify what is already there. Sometimes it is both, but not all at once.

I try to be clear about which problem we are solving before deciding what kind of change to make. That keeps growth from being mistaken for headcount, and change from becoming an end in itself.

The data did not all come from software.

At G3P, some of the data came from applications; some came from physical equipment and motion-capture events.

I worked as Fractional VP of Big Data Engineering, leading data engineers and visualisation specialists. The platform brought application activity, hardware logs and real-time motion-capture events into a shared data environment.

The work included a Redshift warehouse and pipelines using Airbyte, dbt, Kinesis and Kafka. I also worked with stakeholders on Redash and Tableau dashboards. I spent time with the people who understood how an event was produced, and the people who needed to interpret it. Without that conversation, a technically sound pipeline can still deliver the wrong thing.

Keep the question attached to the data.

A warehouse is infrastructure. Its value comes from the decisions it helps people make. I wanted the reporting work to stay connected to its sources, definitions and intended use, not just become a collection of charts that nobody trusted.

One simple test stayed useful: can someone trace a chart back to what it represents, and decide what to do with it?

A webhook is a signal, not a source of truth.

A webhook can arrive twice while the first copy is still waiting to be processed. The system has to cope with that without making a mess downstream.

I have been building an integration between an operational system and a CRM. The incoming event tells us something changed, but it is not always enough to update the other system safely. Sometimes we need to fetch the current record, check its lifecycle state and apply an explicit mapping first.

So the integration keeps a record of what it received and what it did next. Work can be queued and retried; duplicate events should not create duplicate effects; and a failed sync should leave enough context for someone to understand it.

That last step matters. An operator needs to see which record failed, whether it is safe to retry and what to fix if the mapping is wrong. A retry button without that context just makes it easier to repeat the same failure.

Build the repair path with the integration.

For this system, the questions include how to find a missed event, what to do with a change that arrives out of order, and what an operator sees when the destination API is unavailable. Those answers belong in the design, not in a support runbook written after launch.

The data rules and the operator experience are two sides of the same problem: the system needs to know what is safe to do, and a person needs a clear way to handle the exceptions.

AI is more useful when it can show its working.

I am building a local-first media library that uses models to help describe and search large media collections. The AI does not get the last word.

Processing can produce useful observations: objects, faces, speech, text in a frame, or sounds. But each result needs to keep where it came from and how confident the system is. A tag from a model is not the same thing as a person checking the footage.

The library stores the original media read-only. Analysis runs in background jobs, and failed work can be inspected or tried again. If someone corrects a video description or tag, later processing should not silently replace that decision.

Let people review the uncertain parts.

Confidence is useful when it changes what someone does next. It can help sort suggestions for review; it cannot turn a guess into a fact. A good interface should make the source of an observation visible and leave room to correct it.

I do not need the model to understand every video. I need it to cut down the first pass, show where a suggestion came from and leave the final catalogue in a person’s hands.

What should the system do when the sensor goes quiet?

On an airflow-control project, the sensor is part of the decision. If its readings stop, the system cannot pretend that nothing has changed.

The setup uses a wind sensor, a PLC, relay-controlled equipment and an HMI. In automatic mode, the fan responds to measured wind conditions. The commissioning requirement is for a communication fault to turn it off within five seconds, rather than let it continue on stale readings.

Manual modes are deliberately different: the operator’s explicit choice remains in control. That distinction needs to be clear in both the logic and the interface. “Automatic” and “manual” are not just labels; they describe who or what has authority over the output.

Make the failure visible, not mysterious.

The HMI should show whether readings are current, which mode is active and why the output changed. Commissioning should test the loss-of-communication case as deliberately as the normal operating sequence.

Fail-safe is not a magic phrase that makes a system safe in every context. It is a decision about a particular failure, an output and the people responsible for operating it. That decision belongs in the design before the equipment is running.

A prototype is a status, not an apology.

I have been exploring whether a small ESP32-based device can turn familiar motion controls into USB input. There is a working part, and there is still a part to solve.

The current prototype demonstrates the USB HID path. BLE pairing and full end-to-end validation are not complete.

A prototype answers a bounded question. Does the input hardware provide a signal we can use? Can the firmware expose it over USB in the way the host expects? What changes when the connection is wireless? Each answer narrows the next piece of work.

Say what has been tested.

I try to distinguish code that builds, a feature that has been demonstrated, and a device that has been tested end to end. Those are different milestones. During prototyping, a clear status helps someone decide whether to try the project, contribute to it or wait for another iteration.

There is no need to apologise for being part-way through an experiment. Just be precise about where it is.

Make the safe path the easy path.

A developer tool should save time without making it harder to see what a command will affect.

I have been building a VS Code extension for common Cloudflare Wrangler workflows. The useful part is not putting a button around every command. It is helping someone see the account, environment and resource they are about to work with, and making consequential actions deliberate.

Authentication stays with Wrangler rather than becoming a second credential system inside the extension. For higher-impact changes, the interface should make the target and consequence clear before the command runs. For routine work, it should get out of the way.

Good defaults are a safety feature.

When the tool knows which environment is selected, it can make the normal path easier and the risky mistake less likely. But it should not hide what is happening: logs, errors and the underlying command need to remain inspectable.

That balance matters in engineering tools generally. Automation should take away repetition, not remove the operator’s ability to understand or stop what is happening.