About The Playbook
Korio is a group of professionals who came together to help companies re-platform and become agile and fast. We prefer to work with established companies in the mid-market who might be struggling with the transformation to digital. Collectively, we have gone through dozens of transformations. We have witnessed successes and failures.
Based on what we have learned, we have become quite opinionated on what works and what doesn't. This short post is part of a larger Playbook that we have assembled based on what we have learned.
For details on each on our approach to organization and team structure, explore the links below.
As we learn more from our clients and if we think that the learning is: A) actionable, B) validated and C) doesn't state the obvious, then we will add it to our Playbook.
Remember, everything we propose can be done incrementally and with very little lead-time. If you want to adopt the plays in a more gradual manner, go ahead but consider setting each up as an experiment: have a hypothesis, measure the impact and act on what you learn.
The Play: Introduce Small Autonomous Teams
Most enterprises try to cut corners on Agile practices. They usually end up refering to the mess they are left with as "hybrid Agile". In our experience, there are certain aspects of Agile you should not mess with and team size, composition and mandate is most definitely one of them. We refer to these as Small Autonomous Teams (SATs).
The definition is pretty straightforward.
3 to 7 people, at most
Amazon's Jeff Bezos calls this the "Two Pizza Team". It works like this, if you can't feed the entire team with two pizzas, your team is probably too large. Research seems to back him up on this and, more anecdotally, we have learned that small teams - with a proper mandate - are far more effective than large teams or no team at all. Bezos famously suggests that the need for "communication is a sign of dysfunction" and that large teams need artificial mechanisms to facilitate communication. Wow. There is a lot to unpack in that statement. It deserves its own post. Suffice it to say that we agree. When we have seen companies or individuals fixate on creating communications or, worse yet, channels of communication, we tend to see mediocraty or, at least, bureaucracy. SATs are small enough to interact and make things happen in real time - and they leverage real data to do this. Communication happens organically and effortlessly. For those who are not part of the SAT, but have an interest in their scope, they must also be given access to the data. If the data isn't doing all the communicating deemed necessary, then you don't have the right data or the right people interpreting it.
Compelling scope:
our SATs are always organized around Value Maps and Value Maps are always defined around meaningful, value-creating flows that usually come with clear expected outcomes and associated metrics. Unlike the current organization chart that might be defined around functional disciplines, the scope and mandate of a SAT targets value creation for the client, regardless of how many functions those journeys may touch.
Team membership and structure:
Our SATs always have a lead or Solution Owner. In Agile this is usually called the Product Owner. Either term works. We always consult the current organization chart to see if we have a potential Solution Owner evident there that most clearly owns these metrics already or, at least, ought to own them. If there is no clear owner then we may have a bigger problem. Sadly, we see this mismatch between critical metrics and ownership of those metrics quite often. SATs can help with this where shifts in the organization chart or rewriting conventional job definitions might not be practical. In either case, be sure your SAT has a compelling scope and don't compromise on the SAT and/or Solution Owner's clear accountability for the metric or metrics that describe success within the team's scope. Use the opportunity of SAT creation to establish clarity on what is critical to the business, the measures used to keep us on track and the single point of ownership for achieving the result.
In our experience, in terms of the time commitment, the Solution Owner will go from at least 50% dedication to SAT-related work to around 25% dedication. This usually is highest during the first stages of re-platforming or transformation and might ramp down over time. If your conventional job descriptions are truly aligned with what your business needs, then doing the work of the SAT should just feel like they are doing their job.
If you commit to Value Maps as a driver of how you operate, but your organinzation structure is oriented by function, your Solution Owner may need the specialized support of additional members to cover the full scope of the mandate. Be open to letting the Value Map set the scope rather than falling back on your org structure because Value Maps are more comprehensively shaped by your strategy and by what it means to be exceptional in the service of your end customer. Given the scope, add Subject Matter Experts (SME) from the other functions, as necessary. Ideally a SAT needs no more than 3 SMEs. SMEs should be prepared to dedicate 10% to 25% of their time to the SAT.
There are two additional roles that all SATs should have access to: a developer from IT and a Business Analyst. Usually we name these individuals as permanent members of the SAT. In both cases, supporting SATs is their full time job, so they can serve on multiple SATs. Sometimes, given tools now available to us, both these roles can be done by one person.
Because these teams almost always depend on digital capabilities and technology to achieve their mandate, we almost always need a developer embedded on the team. Embedded IT is a central feature in our Playbook. In summary, we believe the developer of the future needs to focus more on achieving business outcomes and spend less time wrestling with software frameworks. With the emergence of powerful low-code environments, we don't need as many highly-paid software engineers to build and maintain highly patterned aspects of our platforms. Instead, we need team members with entry level or intermediate scripting skills to work inside the SAT. With the right tools, the SAT can meet, consult the data and build and deploy a new customer-facing microservice in two to four hours. While this isn't always possible - sometimes you need more hand-coded logic - but this incredible lift in velocity is possible more often than you may expect with the right tools and team structure.
Finally, we need someone to play the role of the Business Analyst. Our methodology requires the creation of highly structured Value Maps. The BA is responsible for these artifacts and for applying the methodology that produces and maintains them. These artifacts are living documents and must stay ever-green. They define the expected outcomes, metrics and flows of work necessary to compete in our chosen market. This discipline produces a very short list of critical artifacts that our SATs need to make a difference. In some cases the developer can also play the Business Analyst role. We have even seen it work the other way around as well: because low-code development isn't particularly challenging, it can often be learned by a BA who has an interest in scripting.
Regardless of whether the Developer/BA combination is filled by one individual or two, the area where we always hope to see the most notable engagement is around data. One of either the BA or the Developer needs to really run with the data side of things. To be clear, everyone on the SAT needs to be comfortable with data and metrics. What we are talking about here is the knowledge, ability and curiosity required to capture, extract and analyze the data to bring new insights to the SAT. To a large degree, the data aspect can be learned.
Autonomy within a risk-managed scope:
Autonomy, in this context, assumes a rich data environment and it assumes SAT members are trained on how to use data to support fact-based decisions. Within that context, the team has full autonomy and should be encouraged to make decisions informed by data without hesitation. Naturally there are some guardrails here. Our Playbook targets companies with an established presence in their market - companies that may struggle with going digital, but who understand the space in which they operate. This understanding means they can pinpoint the types of decisions that go outside a prescribed risk appetite for the business. When a SAT ventures close to this line, it is time for a more formal business case process to kick in. If it isn't close to that line, avoid business cases at all costs. In our experience, calculating the ROI on tactical actions usually amounts to creating hopefull works of fiction. It is better to just do the thing, watch the actual data and react accordingly.
Why Bother
- Speed: small teams are just way faster.
- Momentum: larger teams with more fluid boundaries (those two things tend to go together) simply can't maintain momentum. With SATs roles are clear and and shirking of responsibility will be noticed.
- Quality of decisions: when backed by rich data, decision-quality and, through rapid iteration, eventual outcomes will improve dramatically. Larger teams tend to drift towards group-think. They over-rotate on things and seem to respect the data less. Small teams, on the other hand, know they don't have enterprise-wide consensus when they make a decision, so they must respect the data when they make decisions because they will need to use it as evidence to take whatever direction the data suggested.
- Elevation of data: it bears repeating - fact-based optimization is critical in the new enterprise. SATs need rich data and, when they get it, they use it to great effect. When they use it, to show success or to fail fast, it elevates the profile of data in the business and that is a very good thing.
- Ownership & accountability: large teams tend to drift and lose focus. Small team members have nowhere to hide. Put more positively: they take pride of ownership. They get up every day knowing they can make a difference - and make a difference they must.
- Engagement and learning: smaller teams can always ask for expert help, but they also need to work towards self-sufficiency. Because SATs are always assigned a strategically critical segment of the business, they have something very specific and unambiguous to learn, care about and affect. In our experience, SAT members develop a level of passion and excitement about producing meaningful outcomes in their assigned areas of autonomy.
What To Avoid
- Uneven of tentative committment: if the key stakeholders in the business aren't able to grant full autonomy to the SAT things will unravel quickly. It is critical to show very visible evidence of support for this model. Like all Playbook plays, for something this important, it might be a good idea to script how we discuss it with others. We cannot afford to let the SAT concept fray from a lack of visible committment at all levels and in all areas of the business. Often to show committment at the highest level to SATs, leadership will celebrate the wins and the failures of the SATs. By acknowledging the failures and highlighting the lessons learned, we make it ok to be innovative and take reasonable risks - as long as we have a committment to data, iterations and course-corrections that will get teams back on track.
- Fear of failure: related to the point above, avoid punishing failure, even indirectly. Because the team is small and usually relatively junior, they might not feel they have a true mandate. Signalling that they do, in fact, have autonomy within a risk-managed scope, is critical.
- Excluding IT: The "business-IT-divide" is a concerning trend that dramatically limits our ability to become a modern, digitally-enabled enterprise. For us, the new model for IT is what we call embedding - and SATs are where that embedding happens.
- Team member lock-in: some folks just aren't cut out for SAT membership or they just aren't passionate about the scope, mandate or focus of the team. We find it is best to prepare teams for this at the outset so that, when the time comes to rotate a member, there isn't any drama involved.
- Project mindset: SATs are forever. At Korio, we generally don't believe in "projects", as such, so it goes without saying that SATs don't have a stale date or some final deliverable. Their role is about getting to a level of differentiating excellence ... and that high bar is always shifting.
- Collision with the formal organization structure: this one is hard to navigate. Before SATs were given their scope or mandate, someone - or many someones - had a job that put them in or around that same scope. The interesting thing with SATs is, because they are usually designed around segments of the customer journey, the merits of their defined scope become so apparent and powerful that the existing structure will shift to accomodate it or can be made to shift to accomodate it. SAT introduction goes most smoothly, obviously, when optimal team membership and the current incumbents in roles that overlap the scope are the same people.
The Fallback
- At the very least, elevate data: if SATs cause too much friction in your business and they can't be given firm mandates then you must bring the role of data to a whole new level. By elevating data and a coherent set of signals, you give yourself a fair shot at achieving excellence. When your data signals an issue, and your data-centric culture isn't capable of ingoring the signal, you can still trigger the kind of focused action that a SAT would normally bring.