How do you manage a development department in a results-oriented way?

How do you manage a development department in a results-oriented way? Is the result perhaps the value that the end user attaches to the result? But this is a questionable view, because in most cases development engineers have no choice between high and low value projects. They are given a task and are required to complete it within a budget and to a deadline.

It is said that only what is measured is managed. So we need to think about how we should measure the results of development. But what do we want to measure in development? The number of specifications that have been written? The speed with which components are connected on a board in routing? How do such things relate to performance?

Well, Galileo said that "You have to measure what is measurable and make measurable what is not measurable to begin with". So how do you make results measurable in a development organization? Well, there is a simple answer from the 1950s: Earned Value Management (EVM).

In EVM, the planned costs of the project are set in relation to the actual costs. This can be used to measure progress and also to forecast how the project might progress. This works particularly well in the construction industry and is required of suppliers by the Department of Defense in the USA, for example. However, the method has a decisive disadvantage for a team of developers: it is measured in currencies (EUR, USD)!

Anyone who knows developers knows that this becomes a problem. Developers want to concentrate on the technology and not have to think about the euros. Fortunately, there is an alternative: you can easily measure both planned costs and actual costs in hours.

This means that hours are planned for an (interim) result and when the result is achieved, these planned hours are taken as a measure of what has been achieved, the "earned value", and compared to the actual hours, the actual costs. The currency in development is therefore the development hour.

The method works well and allows the organization to focus on creating an adequate database and processing tasks efficiently.

But I don't want to hide the fact that, especially in organizations that have not yet done this, even development engineers with a lot of experience sometimes find it very difficult when they are asked for the first time to submit their own estimates of their own work and then to stick to them in the project.

This is because it is not expedient to have the team leader estimate the work and then expect the person carrying out the work to feel bound by these estimates.

How do you see this? What do you measure in your development?