Hendrik Dahmke: Product Velocity Requires a Shared Understanding

Many organizations have agile teams, coordinated planning cycles, and modern tools. Yet they still lose time navigating the interfaces between management, systems engineering, hardware, and software. The problem rarely lies with a single team. It arises where vision, technical understanding, and decision-making autonomy are not aligned.

Hendrik Dahmke examines Product Velocity from the perspective of a systems engineer. His starting point is the question of how systems can be developed in such a way that people can understand their interrelationships and take ownership. In doing so, he combines insights from Scrum and SAFe with technical autonomy and a specific AI project.

This article is a guest post. In it, Hendrik describes his personal understanding of product velocity.

Guest Post by Hendrik Dahmke: What Does Product Velocity Mean for Me?

Why I'm glad someone is writing about this

Ubiquitous Computing was my last course at the university. It was about integrating systems into the environment in such a way that they go unnoticed. One example was a farmer who wanted to know whether a female pig was pregnant or not. He was presented with many solutions, but he didn’t want any of them. Today, he has two LEDs on the wall—a red one for pregnant and a green one for not pregnant. The pigs go about their business as usual; technology installed under the floor scans the pigs, and the LED indicates whether they’re pregnant or not. The farmer knows right away. That’s my favorite example of ubiquitous computing.

The other important point from this course is „time to market.“ There’s no point in having the best system if no one uses it.

„When I graduated from college, I walked away with two ideas that have stayed with me to this day: systems that work invisibly, and products that arrive on time.“

Hendrik Dahmke

The university left me with two ideas that have stayed with me to this day: systems that work invisibly, and products that arrive on time. Then came my professional life: Scrum teams, SAFe, quarterly planning sessions. These are good frameworks, but somewhere between management’s vision and the engineers’ deep expertise, something gets lost. Not because the people are bad. But because the system fails to build a bridge between them.

Scrum, SAFe, and the Missing Bridge

As part of a Scrum team, I learned how to develop software together using agile methods. Agile means responding to user needs. Scrum is about delivering value within set timeframes, whether that’s new functionality, adjustments to existing functionality, or value for the team in the form of refactoring.

But what if the team, after Scrum is working, but the customer isn't, and the customer wants to make changes during those time periods?

But then there's also SAFe, or "Scrum" for short, on a larger scale with multiple Scrum teams. At its core, it’s about sitting down together, thinking about what we can accomplish over even longer time frames, and making the dependencies we have with other teams visible. This communication is intended to give us a better picture of the big picture.

To this end, SAFe has expanded to include agile hardware development. This is another step toward ubiquitous computing: When the hardware knows what the software wants, the hardware can be adapted—and vice versa.

But what if management is at the top and doesn't fully understand exactly what the teams are doing? Management had a vision, an idea, and wanted to put it into practice. But what if the CTO doesn't fully understand how to implement it or what's needed to do so?

If management doesn't fully understand how these Scrum teams work, how can management be confident that the vision is being implemented correctly? If the CTO doesn't fully understand how to implement the vision from a technical standpoint, how is the technical team supposed to implement it?

Product Velocity Opens Up the Problem Space

The vision isn't the problem. It's the driving force behind why we do things. The teams are supposed to bring this vision to life. Scrum and SAFe are frameworks primarily designed for software development. One aspect I felt was missing is system development—or the problem space: What should this system be able to do? What tasks should it solve? This is where Product Velocity into play.

Product Velocity takes a systems engineering approach to development—covering hardware, software, and management. This allows us to broaden the scope of the problem and determine what functionality the system needs to accomplish its tasks. This is precisely what fosters a shared understanding.

I like the term "product velocity." To me, velocity is a vector with speed. The speed is the sum of management, hardware, and software. So the product can only move as fast as each of these three components individually.

Responsibility and Technical Autonomy

Product Velocity, therefore, directly holds management accountable as well. A management team that takes responsibility also delegates this responsibility to the teams, and the teams, in turn, demonstrate greater responsibility. This sense of responsibility gives rise to stories like that of Ingenuity. When a sensor needed for positioning could no longer be used as intended, NASA engineers turned to an existing inertial measurement unit (IMU)—sensor technology similar to that used in smartphones. Using the IMU’s accelerometers and Mars’s gravity, they were able to mathematically determine the drone’s tilt. Instead of requiring new hardware, they solved a hardware problem using existing sensors, software, and a deep understanding of the system.

Product Velocity doesn't start with a framework. It starts with the question: Does management truly understand what the teams are building, and do the teams truly understand where management wants to go? If the answer to both questions is yes, the product moves forward. If not, only time moves forward.

„Autonomy is a condition created for engineers so that they can make and implement decisions within their area of expertise, rather than waiting for a process to dictate every decision.“

Hendrik Dahmke

Autonomy is a condition created for engineers so that they can make and implement decisions within their area of expertise, rather than waiting for a process to dictate every decision. Management must create precisely these conditions.

An AI Project as an Example

In my case, I’m leading a project in which we want to use artificial intelligence for systems engineering tasks. I was given the freedom to create a roadmap on my own. Even though I had a general idea, I had to familiarize myself with the topic and experiment on my own. That’s how I created a requirements validation pipeline using Claude in seven minutes. I stated what I wanted to do: a project for validating and verifying requirements—nothing more, nothing less.

A few minutes later, Claude had created a prototype. I hadn't realized just how extensive the scope was or what AI systems are capable of today. I didn't know the terminology. Claude built and explained all of that to me.

This gave me a foundation for creating a potential roadmap, defining use cases, and outlining where the project should be headed. Armed with this, I was able to lead the project and keep it on track.

But I don't know everything. The underlying software architecture was developed by my colleague. Just like me, he had read up on the subject. He had drawn up his roadmap for this area. Together, we combined our ideas.

Our management didn't tell us how to use AI. They described the problem we wanted to solve. We had to figure out how to get there on our own. That's exactly what I mean by technical autonomy. It doesn’t mean that no one is keeping an eye on things. It means that everyone understands the problem that needs to be solved and trusts the engineers to find the best way to get there.

The Cost of Control

Let’s imagine the opposite for a moment. For every technical decision, we’d first have to convince management. For every change in direction, we’d need approval. Every new insight would have to go through several levels of approval before we were allowed to try it out. If we’d had to explain and get approval for every decision first, we’d probably still be debating the first use case. Instead, we had a working prototype within minutes. Not because we were smarter, but because we were allowed to try things out.

The alternative sounds so absurd that it can’t be real. Unfortunately, it’s a reality in many companies. A lack of trust and a lack of technical understanding are replaced by control. Long-term goals—and thus genuine innovation—are replaced by arbitrary performance metrics in an Excel spreadsheet that must be met month after month. Management hasn’t simply traded trust for control; rather, it has optimized what it could measure, since no one has built anything better for management.

Conclusion

It’s not about asking what we can or cannot do. It’s important to accept that, for management, responsibility means understanding what the team needs. For the team, it means taking the initiative. Only then can we ask the question: Are we ready to take on responsibility?

About Hendrik Dahmke

Hendrik Dahmke works as a systems engineer and creates system models. He is interested in how people understand technical systems, how components and functions interact, and why systems that work technically still lack clarity.

On his blog The Systems Engineer He writes about systems engineering, software, organizations, and technology that’s easy to understand. His goal is to make systems transparent so that engineers and users can understand their interrelationships and the decisions behind them.