Developing Competitive Services, Part 2: Thoughts about organization
How do we end up with a specific organizational model? In a traditional organization, there are people who do the work and people who tell them what to do. This model seems to have evolved over time when there was a need for hands to perform predetermined tasks. The doers only need to know how things are done, while someone else has thought about why they are done. To expedite tasks, the number of people has been increased, and the work still happens as a result of someone else’s thinking.
As the volume of tasks increases, it’s natural that the number of required people also increases, with the majority still being doers. The person in charge of the organization oversees the group of doers until they feel that time is no longer sufficient for managing everything. At this point, an intermediate layer is introduced, where individuals are responsible for part of the whole, approaching a large hierarchical organization, which companies have operated with for as long as they have existed.
Such an organization is functional, but does it produce the best possible results in knowledge work? If we revisit my previous writing on customer value, we realize that the expertise required for service development is highly diverse. Technological expertise affects the service’s reliability, usability, and the costs of creating value. Business expertise helps understand parameters affecting potential returns and assess the amount of sensible investments. Understanding customer behavior is yet another area of expertise that impacts the service’s success.
Can we then think that the traditional organizational structure achieves the best possible service? Does such a top-down model consider everything, and is the prioritization between technology, business, and customer needs balanced? Is the person who defines what and why truly well-informed about all factors influencing the service’s success? Are the people implementing the service satisfied with their work if everything is predefined, even though they might have experience and insights to do things better?
Organization itself directly affects the emergence of innovations, and especially in large organizations, there is a risk of becoming siloed. The traditional managerial organization, where the team leader is also the team’s manager, easily leads to a situation where the manager’s thoughts are not challenged, and the entire service’s future relies on one person’s ideas. When this manager still has a superior, perhaps overseeing multiple teams, we approach a situation where the person at the top of the hierarchy has only a small part of their capacity available for managing each team’s activities. Hierarchical management models and top-down assigned tasks inevitably slow down the service’s development in the best direction.
The person responsible for the service plans the implementation of requested new features. Their manager reviews the plans and gives approval. Subsequently, implementation monitoring begins. Employees’ potential bonuses are often tied to promised schedules, causing the motivation for making changes to disappear. Therefore, traditional hierarchical organization leads to the loss of agility. Similarly, prioritization for creating the best possible customer value becomes very one-sided.
The innovation challenges caused by organization are often attempted to be fixed with a separate innovation organization. Innovations do emerge commendably in such an arrangement, but integrating these new innovations into daily business operations is challenging. Timing, compatibility with technologies and architecture, fixed release schedules, personal relationships, and different goals pose challenges to integrating new innovations. Sometimes finding a clear “home” is also difficult. Efforts are made to push new innovations from separate organizations into organizations with existing plans.
In service development, one cannot rely on a hierarchical organization; the entire organization must be involved. Only in this way can the best possible knowledge capacity be utilized.
In our opinion, the best organizational model is an agile, multifunctional team without hierarchical relationships. The Product Owner’s task is to form the best possible synthesis of customer value to fulfill business goals. The Product Owner must have an understanding of business, customer interface, and technical possibilities.
When goals are set in such a team in a way that the team has the freedom to think of the best possible way to achieve them, the service begins to develop in the right direction.
Even in agile organizations, there is a possibility of siloing. When the service scale requires multiple parallel organizations and multiple levels of organization, the teams developing services move away from each other. As a result of siloing, prioritizing tasks across the entire organization becomes difficult. An imbalance and shortcuts arise from which less valuable things consume the time of implementing teams. In one organization, tasks may come to the table that would not fit on the worklist in a parallel organization due to more important business matters.
If communication works and the company’s goal hierarchy is built correctly, the mentioned problems can be avoided. However, often the situation needs to be corrected with horizontal organizational structures such as product management, architecture, and design. The right things must be implemented in the right way in the right place. The mentioned horizontal structures are crucial for the end result, as they ensure communication works and goals are correct.
Fixed organizations and associated costs are also a combination that complicates agility. If the organizational model is not flexible, most of the available funds are tied to the organization. In a model based on business areas and led from the top, this leads to an imbalanced situation again from the perspective of creating customer value and optimal business success. Organizational silos have never had difficulty finding tasks with existing resourcing.
Flexibility must be found in the organization and financial allocation. Experts must be able to move between different teams, and teams must be able to change their activities according to current needs. If the organization’s size and the content of tasks change agilely, where should the financing be based? Team performance can be kept good with the DevOps model, where the team’s size is scaled according to changing requirements.
In financial planning, there must be an understanding of business operations. However, as a separate organization, finance can set goals that complicate business development. The same applies to procurement. If procurement has no direct link to organizations engaged in business, they can set goals leading to consequences harmful to the company.
Support functions must work under the same goals as business, and at least partly in the same organization.
As this is a subject that could be discussed endlessly, we are more than happy to continue thought sharing with you – don’t hesitate to contact us!