The Champion, the Chief and the Manager

Successful product development projects are often characterized by having an enthusiastic product champion with solid domain knowledge, a visible and proud chief engineer, and a clever and supportive project manager. And of course, the most important thing, a group of exceptional developers. From an organizational point of view it makes sense to require that all projects should clearly identify these three roles:

The Champion: The product champion is a person that dreams about the product, has a vision about how it can be used and can answer questions about what is important and what is less important. The product champion is required to have a deep and solid domain knowledge and will often play the role of a customer proxy in the project. This position can only be held by a person that is deeply devoted and has a true passion for the product to be created. The product champion is the main interface between the project and the customer/users. (Sometimes also known as: Product Manager, Project Owner, Customer Proxy…)

The Chief: The chief engineer is a technical expert that has a vision of the complete solution and is always ready to defend this vision. At any time, the chief engineer should be able, and willing to stand up to proudly describe the solution and explain how everything fits together. He/she should feel responsible for technological decisions that the exceptional developers do, but also make sure that the solution is supporting the business strategy. The chief engineer is the main communication channel between this project and other projects. (Sometimes also known as: System Architect, Tech Lead, Shusa, …)

The Manager: The project manager is a person that leads a team to success by managing the resources on a project in an effective and sensible way. He/she will be responsible for actively discovering and removing impediments. The project manager is the main interface between the project and corporate management. (Sometimes also known as: Scrum Master, Team Leader, …)

Of course, for very small projects these three roles can be fulfilled by one person, but for projects of some size there should be three people filling these three roles: one product champion, one chief engineer and one project manager. These three people must work together as a team, form an allround defence (aka kringvern) around the project, while being available to the developers at any time. Their task is to “protect” and “promote” the project to the outside world so that the exceptional developers can focus on doing the job.

I believe that identifying these three roles is the only thing an organization needs to impose in order to increase the chance of success. Then the team of exceptional developers together with their servants decide everything else, including which methodology and technology to use.

Software Architecture is a key enabler for your Business Strategy

Last month I organized an internal 4-day workshop in Software Architecture at my company. Twelve lead developers representing several product groups and development sites attended. The instructor was Dana Bredemeyer himself.

The workshop was excellent, although quite different from what I expected. Bredemeyers workshop was all about techniques for translating your strategy into architecture. Little was said about how to translate architecture into implementation, but that was ok. I have to admit that so far in my career I have thought about software architecture as something that first of all is useful for the implementation of software. But now I realize that for a business relying on complex software, focus on architecture is indeed a key enabler for your business strategy.

All software implementations have an architecture. By studying the code base and a running system you might be able to both illustrate the architecture and explain the expected behavior of the system. For many, perhaps most, development efforts this is a sensible way of working – apply most of your energy on writing code and just take a brief look at the resulting architecture at regular intervals to see if it makes sense. Let the user requirements drive the implementation, and use your test scenarios to verify the product. Because you will never get exactly what you plan for, the resulting product will determine which business strategy you can use to make money and the architecture will restrict how to evolve your business. The products drive the business (see figure 1).

For a business with only a few products on the market this can be a very efficient way of making money. Your product might be successful and the business attracts money that can be invested in making the same product even more fancy to attract even more money. Adjust your business strategy according to the products that are available.

However, as the business grows and the product portfolio diversifies, you need to focus more on architecture. Why? Because you might want a mechanism to let a strategy run the business, not the products. The key is to focus more on architecture so that you can drive it with your business strategy, and let the architecture strongly influence the implementation so that you get products that support the strategy. It is then possible to let a strategy drive your business (see figure 2).

Beware, I am not trying to tell you that heavy focus on architecture is the only way to succeed. It is certainly possible for huge businesses to experience massive success with large and complex software systems without paying too much attention on the architecture. However, the key point is that if you want to control your business by defining strategies you need to focus on the architecture – otherwise not much will happen if you position yourself inside the strategy bubble and try to twist the knobs.