Constructing the Web
We have already alluded to the idea that the promise made at the end of the Negotiation phase (Q2) of the Workflow can be viewed like an OKR: the Customer holds the Objective, and the Performer promises to deliver on some Results. This can be operationalized into planning for the whole company.
A company consists of many Workflows at a time. These Workflows themselves can correspond to different time horizons. For instance, in a small company, the CEO may be on a three year Workflow with the board (ie. making a three year promise), while a more junior employee is only on three month Workflows (ie. only making three month promises) with some project lead. Project leads themselves might be on one year workflows, perhaps making promises to the CEO, and so on.
This cascading time structure can be used to organize and plan OKRs for the whole company by articulating objectives at different time horizons and conceptualizing each one as a workflow, with a dedicated Customer and Performer at each stage. For instance, there may be a single three year Workflow where the CEO is the Performer and the Board of Directors is the Customer. At this point, the CEO is the only one able to make a three year commitment to the board. This three year promise captures the broadest scope and longest term objective for the company, what it needs to achieve in the world in the next three years.
Others, who are able to make promises on a smaller time horizon (i.e. the CTO on one year) would be the Performer for the CEO, who would now take on the role of a Customer on the shorter workflow. The CTO knows that the CEO has made a longer term commitment to the Board, so the CTO works with the CEO to make a series of one year promises which will help the CEO fulfil their three year promises to the Board. In turn the CTO may be a Customer on other Workflows with other members of the team, like individual engineers, on one year or three month time horizons.
In this way, the Performer in a Workflow at one time horizon is often the Customer for a Workflow on a smaller time horizon. For instance, the CEO makes three year promises to the board, the CTO makes one year promises to the CEO, and an engineer makes three month promises to the CTO.
Time Horizon | Customer | Performer | Results |
---|---|---|---|
3 Years | Board | CEO | Make the Company Awesome |
1 Year | CEO | CTO | Build Awesome Tech for the Company |
3 Months | CTO | Engineer | Implement Awesome Feature |
Notice how the Performer on one time horizon (eg. the CEO on the 3 year) is the customer on the next (eg. the CEO on the 1 year)the CEO o..
By mapping out the set of Workflows for the company’s core objectives and projects, we can get clarity over the accountability structure without needing to invoke “reporting lines” and “management”. Instead, we get an effectively equivalent but more explicit model of how the company is organized based on the kinds of promises people make, to who, and over what time horizon. This then directly illuminates a trajectory to scaling the organizational design, by empowering people to make promises of broader or narrower scope, and of shorter or longer time horizons. “Hierarchy” emerges here from the explicit responsibilities people are willing to take in terms of the scope and time-horizon of promises they are willing to make.
In the end, the goal is for every employee to be asking themselves: “what promises do I want to make, to whom, and on what time horizon? And what promises do I want made to me, by whom, and on what time frame?”
For any given time horizon, say three months, there may be multiple interlocking Workflows. For instance, a Product Owner will make a three month promise to the CEO, while engineers make a three month promise to the Product Owner. The Product Owner is now a Customer for the Engineers who are Performers.
Time Horizon | Customer | Performer | Results |
---|---|---|---|
1 year | CEO | Product Owner | Ship an Awesome Product |
1 year | Product Owner | Engineer 1 | Implement Part of Awesome Product |
1 year | Product Owner | Engineer 2 | Implement Part of Awesome Product |
Promises contained within Workflows between various Customers and Performers are necessarily dependant on each other, and thus their Workflow negotiations are "interlocking". This process of surfacing dependancies between Workflows will take place during the negation phase in Q2. For promises to be properly manifested, negotiations will need to take place with other team members. Often times, many promises will be negotiated at the same time and become interdependent with each other. The planning process for the company thus consists of settling interlocking workflows during negotiations so that everyone can make a set of aligned promises for their time horizon.