My job runs from the device to the backend
It is easy to describe an engineering organization by the boxes on its chart. Firmware. Backend. Quality. Automation. Hardware. Machine learning.
The product does not experience those boxes. Neither does the customer.
At Samsara, I lead across Safety and Telematics, with responsibilities spanning firmware, quality engineering, automation, on-device testing, backend services, and data. The work runs through physical devices and the systems connected to them. A successful result depends on how those pieces behave together.
That makes the boundaries between teams a central part of my job.
Follow the behavior through the system
When a result is wrong or unreliable, the most convenient organizational boundary may be the wrong place to stop the investigation.
A device might produce data that a service interprets differently from what the device team intended. A test environment may omit a condition the hardware encounters. A model may meet an isolated target while its surrounding pipeline creates a different product-level result.
Those are examples of the questions I want teams to be able to pursue together. They are not descriptions of particular Samsara incidents.
My responsibility is to make the ownership clear without making each team defend its boundary as the end of its concern. I want someone accountable for the complete behavior and a practical way for the contributing teams to resolve their dependencies.
Put hardware and software decisions in the same conversation
Taking on Safety alongside Telematics expanded that responsibility. Bringing firmware, hardware, and machine-learning decisions into closer alignment became an even more central part of the work.
The purpose is alignment around shared targets. Accuracy, latency, compute, power, cost, and the ability to operate and update the product all affect the design. Treating them as separate negotiations invites local decisions that are difficult to reconcile later.
A significant part of my work is bridging hardware and machine learning. That requires enough technical depth to understand the constraints and enough organizational clarity to turn them into decisions teams can act on.
Quality is part of that ownership
My scope includes how we test the device and its connection to the rest of the system: automation, emulation, simulation, on-device exercise, and backend integration.
These environments answer different questions. A fast simulation can make some failures easy to reproduce. Actual hardware supplies evidence the simulation cannot provide by itself. The work is to understand what each layer can establish and keep the feedback useful to the people making the change.
This is also where I see an opportunity for agentic development. Code generation can help, but it needs a clear contract with the test environment and the acceptance criteria. Otherwise, it can increase change volume without improving our ability to evaluate the result.
Broad scope should produce fewer gaps
The point of owning a broad surface is not to collect more functions under one leader. It is to reduce the places where a product-level problem can fall between responsibilities.
I want teams to know what they own, understand the neighboring constraints, and share a definition of the outcome. I want the test system to make important failures visible early. I want architectural tradeoffs to include the cost of operating the complete product.
That is the part of engineering leadership I find most compelling: building the conditions under which several disciplines can make one coherent product.