Leading during a Time of Quarantine: The Service-oriented Organization (SOO)
In these times of unprecedented stress on organizations, there is a need more than ever to move quickly, take decisive action, to reorient and reinvent for survival. More than ever before businesses are discovering their need for agility and innovation. The current crisis has given many people the opportunity to shine, to show their leadership and express skills, capabilities and behaviors that were never in their job descriptions. Companies are discovering their real leaders. While leadership and innovation are admirable and required qualities in a crisis, they can count for little without an ability to execute. Organizational management skills are needed now more than ever in our lifetime. In a work from home (WFH) world, we’re discovering that there is no team, that we should lead by communicating shared purpose, and that each employee at home has become a service provider. In a world shaken by crisis, where there is likely no return to the old ways, the future of the organization is service-oriented.
The future of the organization is service-oriented!
In the field of large-scale business agility, it turns out there is already an archetypal example of a dynamically reconfigurable organization, designed to rapidly respond to emerging demands and uncertain requirements. Built by Jeff de Luca, a director of IT at United Overseas Bank in Singapore in 1997, his organization reinvented the bank’s lending system. Their doctrine was named “Feature-driven development” (or FDD). We can learn a lot about the future of organizational design from a project of 50 plus people, more than 20 years ago.
In 1997, we lacked the language of service-orientation with which to describe the processes and organization on the PowerLender IT project (codename “CLS II”) at UOB. Every programmer, every business analyst, several other specialists such as user experience designers, and a team of testers all provided services which were dynamically orchestrated feature by feature over 2 years to completely replace all of the bank’s lending operations with a single integrated IT platform.
It all started with a map of the territory, a model of the lending domain and the system requirements. The map was then carved up with different sections of the code allocated to programmers as “class owners.” The concept was simple and intended to maintain code quality and design integrity. Each “owner” would deeply comprehend and understand what that section of code should do, and they would ensure, the proper “coupling” and “cohesion” (technical terms in software engineering) to ensure design integrity and long-term maintainability of the system architecture and code function. FDD made a trade-off that was unfashionable amongst programming methodologists – it traded flexibility of the workforce, for internal code quality. Unlike, Extreme Programming (XP) which was also coming into fashion at the time, FDD gave ownership of sections of the code to individuals. In Jeff de Luca’s world it was considered easier to coordinate people than to maintain the quality and integrity of the code. XP took the opposite view, let the people have the freedom to roam the entire codebase. This created flexibility amongst the workers to take any new request that came along. They could move quickly. Colocate the team for easier communication. Instead FDD used the domain model to facilitate communication. XP assumed that code quality was easy and coordination of humans to work together was challenging. While the XP approach came to dominate the IT world in the past 20 years, through its more corporate mutuation of Test-driven Development (TDD), there remains plenty of evidence that code quality is not easily maintained and design and architectural integrity remain challenging for programmers the world over.
In FDD every programmer provides a set of design, coding and unit testing services, for their territory within the overall map of the system and its business domain. Every analyst provides a feature-oriented requirements explanation and elaboration service, and every tester, a feature-oriented integration testing service. Specialist dependent services such as system architecture, data-base administration and user experience design are called upon when required.
The entire project is viewed as a large collection of features for delivery. The term “chief programmer” was used in the FDD literature to describe someone who was responsible and accountable for the design, development, testing and delivery of a given feature. Today we might better use the language of service provision and call that person a Feature Delivery Manager (FDM) where the service provided is a Feature Delivery Service. An FDM would use their knowledge and experience to quickly assemble the team required – essentially orchestrating the set of service providers needed to cooperate and collaborate to complete the needed work.
The feature: its requirements, its user expectations, and delivery criteria defined the shared purpose for a “feature team” – an orchestrated set of service providers who collaborate to make it. While the greater grand vision and mission of the project, to integrate the consumer, commercial and corporate lending systems enabling UOB to make faster, better lending decisions, to be a more agile bank, gave the entire project team of more than 50 staff a shared purpose to drive alignment, trust, pride, achievement and collaboration.
Individuals working from home must have clearly defined service interfaces. There must be no role ambiguity. People want to know what is expected of them and how to perform against expectations. Everyone wants respect, status, recognition and dignity in their work. The foundation of happiness in the workplace is a set of unambiguous well-defined service definitions. And in this new WFH world, we need these service definitions at the granularity of individual workers. While this sounds onerous and cumbersome, it need not be. FDD has shown us that it is perfectly possible to have large-scale business agility enabled by a set of (micro-)services performed by individuals. What is needed is a map of the territory and a set of cleanly defined service interfaces for every provider in the network.
Rapidly reinvent your workplace as a service-oriented organization (SOO)
Rapid reinvention, true business agility and the resilience to cope gracefully with unfolding events and emergent conditions, comes from a flat, service-oriented organizational structure. Managers must develop the skills to quickly orchestrate sets of services to deliver any and every request. They must lead by communicating purpose and context to align sets of service providers asked to cooperate and collaborate at a moment’s notice and for the briefest of time. If you want to relieve your people of endless tiresome hours of video conferencing from their homes, the nature of work has to change. Realize the truth… there is no team! Rapidly reinvent your workplace as a service-oriented organization (SOO) with managers who orchestrate sets of service providers to deliver customer-valued work.
