If you work in a growing, Agile organization, you will sooner or later face the challenge of trying to keep your multiple, autonomous, Scrum teams rowing in the same direction. I work at Appian where the Engineering team builds a low-code platform for rapidly creating Web/Mobile Enterprise apps. Appian Engineering has grown from a few dozen people to over two hundred over the past few years! Like many software product companies, Appian Engineering has staff with the following core competencies:
As we started growing, we quickly realized that we would have to make way more decisions than could be handled in a timely manner by a centralized management team. Additionally, our staff had to be aligned with departmental goals and we had to draw boundaries to clarify ownership of features and bug fixes. We knew we needed to bring some order to the chaos, while still preserving the independence and speed of our teams.
We came across the Spotify model that promised both alignment and autonomy by grouping Scrum teams into Squads within a Tribe, with intra-Tribal Chapters and cross-Tribal Guilds to connect people with related skills or common interests.
As we adopted the Spotify model, we tailored it to our specific needs and built internal applications to track all of this by dogfooding Appian. We manage our priorities via a Product Annual Plan of initiatives, loosely projected over the next 4–6 quarters. Longer term priorities are maintained in a Product Portfolio Backlog. We found that the various “personas” that touch the Appian platform map naturally to Tribes:
- USER: those who use Appian apps
- DESIGNER: those who build Appian apps via configuration, not coding
- INTEGRATOR: those who integrate Appian with external systems/data
- ADMINISTRATOR: those who manage the whole Appian platform
Because each Tribe serves a specific persona, its directives and missions are easy to define. Tribe-level decisions are made quickly by senior staff such as the Tribe Lead (all Software Engineers report through him/her), the Persona Lead (all Product Owners report through him/her), and Quality Lead (all Quality Engineers report though him/her).
Each Squad focuses on one of its Tribe’s missions and takes anywhere from a few quarters to a few years to complete. For example, one of our Squads is working on Mobile Push notifications. As Squads finish their missions, they may re-form around new missions. Squads also allocate up to 20% of their time to maintain code health.
A few Infrastructure Pods (small teams) work on build and deployment tools. For example, they may help streamline CI (continuous integration) testing to speed up our release delivery pipeline.
Chapters are groups of 3–9 people within a Tribe focused on professional growth. We set aside 5% of our work hours for “learning time” which may be via Chapters or other less-structured means, ranging from group discussions, spiking, building tools, and getting certifications to consuming or creating training content.
Guilds form around areas of common interests or needs, such as the Education Guild, which my colleague Dale wrote about recently. One fun Guild is our Community Guild, which focuses on ensuring that we retain our sense of community as we grow; they organize team events (picture below) and outings that encourage people to mix and bond, helping keep Appian one of the “best places to work.”
One gap we noticed in the Spotify model was that as we added more Tribes, we needed a way to keep them aligned along common dimensions of strategy, people, process, and technology. To close this gap, we invented the concept of Councils. Think of a Council as a Guild with mandatory attendance. The Councils below help us manage a rapidly growing department:
Councils drive cross-departmental improvements and communications. Councils have representation from each Tribe and departmental function. The diagram below depicts our matrixed leadership model:
Each Council is led by a Vice President in the department and convenes on a monthly basis. Councils have to be adept at influencing teams and driving organizational change. For example, read how we encourage collaboration around the investigation and choice of technologies.
- Systematically identify issues and solutions with multiplicative impact
- Exert broad influence, inspire initiative, and spark collaboration
- Organize activities, define processes/artifacts, and measure outcomes
- Relentlessly rally support around strategic initiatives
- Mediate conflict and drive prompt resolution
We’ve had Councils in Appian Engineering for the last couple of years and continue to refine what they focus on and how they operate. So far, our Councils have played a prominent role in managing departmental strategy/capacity, improving staff management, streamlining our processes, and in formalizing design reviews/debriefings. Could Councils help your organization? We’d love to hear your thoughts!