Once a Role Steward is in place, she must not only do the work, but lead, communicate, and create living processes.
The creation of a human institution is largely the creation of stories, and the creation of rituals in service of those stories. But how do we tell the stories, and decide on the rituals?
It is worth beginning by discussing the claim, in the context of a startup.
A startup, initially, is a mission. The mission is meaningful to the founders, meaningful enough for them to quit their jobs and start building something that furthers the mission. While mission statements are generally encapsulated as a single statement, that statement is really the conclusion of a broader story: a story of a problem that needs addressing, a story of what the world can be like.
The founders then establish some basic rituals. They may start their day with a standup meeting and then write software for the rest of the day. They may have lunch together and discuss progress. They may raise venture money when they need it.
Over time, the rituals become more involved. They may organize their software schedule into two week sprints. They may have weekly recruiting syncs. As they hire out a team, they may have regular all-hands meetings.
The stories, too, become more involved as well. To the story of the mission, they add the story of the product. They add the story of the values. Other people on the team add to the story as well; a product manager may add the story of a feature. The first hire in people ops may add the story of the culture.
While this process – this creation of a story architecture – happens in every startup, it happens differently at each startup, and some companies do it better than others.
One of the best companies at creating a story architecture is Amazon. Whenever Amazon begins a new product or feature, the product lead writes a prospective press release, as if the product has already launched. The product lead also writes a comprehensive FAQ associated with the press release. The press release and FAQ tell a story of the product. The collection of press releases and FAQs create the story architecture of Amazon. This is one of the key reasons for the extraordinary success of Amazon; clarity of story is an extremely powerful tool for aligning work.
There are several key considerations in building a story architecture. The story architecture should be easy to read. It should very clearly articulate the Why, the What, and the How. It should do so in a way that is easy to skim. It should be persuade the skeptic. It should be beautiful. It should force the storyteller to think rigorously. It should connect each new story with the rest of the story in a coherent way.
All of these point to a Pattern format, consisting of: a name, an image, a set of contextual patterns, a problem statement, a discussion, a summary statement, and a set of related patterns.
The name, image, problem statement, and summary statement allow people to easily skim the pattern. The problem statement gives the why, the summary statement gives the what, and the discussion gives the how. The discussion section also includes an in-depth discussion of the why, a discussion of alternatives, and empirical evidence supporting the pattern, persuading the skeptic and forcing the pattern-writer to think rigorously. And the contextual patterns and related patterns connects the story to the rest of the story architecture.
Ensure that the company is organized around a well-articulated story architecture, and make that story architecture accessible to everybody in the company. Tell these stories in many ways, but importantly, make sure at least one of those ways is through a pattern language for the company. Create pattern languages not just for the company, but for each substantive realm and project and neighborhood. Structure each pattern as a follows: name, an image, a set of contextual patterns, a problem statement, a discussion, a summary statement, and a set of related patterns.
For each role, write the Vision, Strategy, and Objectives as patterns. Like any decision, Role Stewards are responsible for writing patterns related to their role, so long as they go through the Advice process. In engineering, these patterns will resemble traditional design docs.