SLAM Teams, or SLLLAM teams?

PepsiCo coined the term “SLAM” teams as a way to address teaming in large, complex organisations. SLAM teams are:

  • Self-organising
  • Lean
  • Autonomous
  • Multidisciplinary

These characteristics combine to foster agility, alignment, collaboration, and speed. Despite a large organisational size, this enables people  to act more like a network of small, tightly-knit teams. By organising around the work to be done, rather than the lines and boxes of an org chart, teams avoid becoming siloed and disconnected from value. These terms are usually associated with software delivery or engineering teams, and the concepts are part of the DevOps cultures and practices in general, but SLAM teams are appropriate for use in many domains from engineering to healthcare, and education to armed forces.

The people closest to the problem have the best information necessary to accomplish the task. A self-organising team has the freedom to decide how the work gets done and who completes which tasks. The manager exists as a coach and guide, not as a dictator.

There’s a limit to the amount of information we can store in our mind and the limitations of our working memory make it difficult to manage the complexities and communication overhead of large groups. Working in large groups slows us down, subjects us to greater decision fatigue and often impedes our ability to build psychological safety and carry out experiments. A Lean team is limited in size to 7-9 members, reducing communication complexity and improving decision capability.

Autonomous teams move quickly. We enable autonomy and reduce the number of external dependencies by clarifying what decisions can be made by the team members.

Having all the skills required in the team to make decisions and carry out the work from start to finish is the key point behind cross-functional, multi-disciplinary teams. If the team need to go outside the group to ask for decision support or worse, execution help, the pace of work slows down dramatically and the ability of the team to support the product also diminishes.

However, I’ve always felt there were some key points missing from SLAM teams. A key element of high performing teams is how long they exist for. Sure, we can have high performing teams that form and disperse over short timescales, but it’s harder, becomes very tiring over longer periods of time, and short-lived teams will never reach the very high performance that a long-lived team will do. So how about we make some tweaks?

  • Self-organising
  • Lean
  • Long-Lived
  • Autonomous
  • Multidisciplinary

SLLLAM teams not only self-organise, make their own decisions, and possess only the required team members with the right skills, but exist for a long time. The products we build should exist for a long time (or as long as is required), and the team should exist for at least as long as the product exists.

180 Factors of Organisational and Digital Transformation

The below is a simple but extensive (though non-exhaustive and growing) list of factors to address and discover when working on organisational and digital transformations.

I’ve used this list as a helpful reminder when carrying out discovery sessions with clients, and you can too! If you’d like to suggest additions or changes, please let me know!

Organisation

  • Line of business
  • Risk register / immediate risks
  • Risk appetite
  • Public / private / shareholding / equity holding
  • Impediments and current challenge
  • Tracking up or tracking down
  • Industry volatility and disruption
  • Competitors
  • Urgency
  • Cost of delays
  • Cost of changes
  • Regulatory compliance needs
  • Locations
  • Time zones
  • Organisation size
  • Organisation age
  • Diversity of business lines/units
  • Purpose and values
  • Mission statement
  • History and folklore
  • Past mergers and acquisitions
  • Organisation identity in the world
  • Public or private
  • Short term pressure / long term pressure
  • Heterogeneity of leadership / board
  • Finances – cash, P&L, share price, turnover, EBITDA
  • Cost sensitivity
  • Preference for opex vs capex
  • Exit strategy

 

People

  • Organisational culture
  • Heterogeneity of culture across the organisation
  • Leadership buy-in to transformation
  • Key stakeholders
  • Prior transformation attempts
  • Psychological safety (org-wide / in-team)
  • Customer expectations
  • Customer base (business, consumer, public, other)
  • Ease of customer feedback
  • Diversity
  • Equality, gender pay gap visibility
  • National identity and culture
  • Survival anxiety
  • Team member churn rate / length of tenure
  • Organisational structure, reporting lines, matrix, hierarchies
  • Geographical distribution
  • Permanent teams vs outsourced teams
  • Skill and mastery level
  • Tacit knowledge in the organisation
  • Capabilities and gaps
  • Promotions, recognitions and awards
  • Pay scales
  • Orthodoxies
  • Defined roles
  • Cross-teaming
  • Training, coaching, mentoring, support
  • Career paths
  • Physical working environment
  • Communities of Practice
  • Remote vs on-prem (degrees of remoteness)
  • Longevity of teams
  • Centres of Excellence / Enablement
  • Stream aligned teams / function-aligned teams / hybrid
  • Known rituals
  • Facilities, office design, open vs closed offices, physical space
  • Exposure to “business” information such as cashflow, profit, turnover, and granularity.

 

 

Process

  • Operating model
  • Policies
  • Standards
  • Processes
  • Regulation of process
  • Standardisation appetite
  • Finance process
  • Budget cycle
  • Business case requirement
  • Hiring process
  • Procurement process and duration
  • Adherence to frameworks
  • International & national standards
  • Audit frequency and type
  • Governance, risk, compliance processes
  • Product vs project
  • ITIL / COBIT / other frameworks
  • Environment provisioning
  • Preference for waterfall vs agile
  • Handoffs
  • WIP limits
  • Communications cadences and expectations
  • Current methodologies and practices
  • Security clearances
  • Natural / habitual cadences
  • Agile adoption
  • Scrum adoption
  • Methodologies at scale (SAFe, LESS, etc)
  • Statistical Process Control – level of automation and adoption

 

Data and Tools

  • Wall space or digital tools – information radiators
  • Data-driven insights capability
  • Communication tools – asynchronous vs synchronous
  • Silos of information
  • Data feedback loops
  • Dataviz and analytic tools
  • Degree of tool integration
  • SSO
  • “Shadow” IT
  • Degree of autonomy / lockdown of machines
  • AI/ML
  • Volume of data
  • Information availability, default to open/closed
  • Data treated as asset or liability
  • Default information openness
  • Dashboarding and reporting

 

Products

  • Number and characteristics of key products
  • Criticality (life/death or just for fun)
  • Cost of delay for features
  • Level of planning expectation
  • Estimates and deadlines required
  • Risk appetite
  • Reliability requirements
  • Scaling requirements
  • Quality requirements
  • Degree of coupling
  • Degree of cohesion
  • Current lead time
  • Current flow / wait time
  • Current quality
  • Internal regulation
  • Unplanned vs planned work
  • Product lifespan
  • Feature lifespan
  • Marketing approach and capabilities

 

Technology

  • Satisfaction of technical capability
  • Common platform?
  • Architecture – monolithic vs microservices / APIs
  • Potential fracture planes
  • Team topology
  • Corporate network (MPLS, VPNs, hybrid, SDN, etc)
  • Cloud usage (production) – private/hybrid/public
  • Edge and IoT technology
  • Preferred technologies and codebase
  • Build and Deployment pipelines
  • Deployment strategies – canary, blue/green, rolling, A/B
  • Engineering skills
  • Engineering practices
  • Service Desk?
  • Infra as code
  • Containerisation
  • Test and QA approach
  • Work definition approach – user stories, MoSCoW etc
  • Rate, predictability and volume of work requests
  • Where does work come from?
  • Environments
  • Monitoring and observability
  • Degree of automation
  • Branching strategies
  • Existing reliability
  • Existing rate of change
  • Accelerate metrics
  • Technical debt
  • Pair programming, mob programming practices
  • Ratio of junior to senior engineers
  • Dev workstations and tooling
  • Dev / Ops teams & handovers
  • On-call culture and process
  • Infosec team / function and interactions

Please feel free to use this however you’d like, and if you think something needs adding to this list of organisational transformation factors, please let me know!

Digital Transformation and DevOps: Enterprise Resilience

digital transformation

Digital Transformation is having a real moment in industry, in part due to the huge changes as a result of the pandemic of 2020.  But as usual, there’s little agreement about what it means. In contrast to previous “transformations” such as ITIL, Lean, Agile, or DevOps, digital transformation doesn’t simply mean automating processes, becoming more efficient, offering your existing products and services online, creating an app, or shifting your infrastructure to the cloud. Even the annual State of DevOps Reports are beginning to focus more on digital and organisational transformation rather than a specific focus solely on DevOps.

What is digital transformation?

True digital transformation means transforming everything about your organisation in respect to people and technology towards an engaged, agile, happy and high performing organisation. DevOps was (and still is) one key aspect of this approach. The only way to truly achieve organisational resilience or enterprise agility is to fundamentally transform the foundations of the organisation. The list below describes just some of the aspects of digital transformation and the areas to address

  • Culture, values and behaviours
  • Practices and ways of working
  • Communication structures
  • Hierarchies
  • How financial budgets and funding models are managed
  • How teams and people are measured and incentivised
  • How and what metrics are used
  • Cloud native architectures and practices
  • Moving from projects to products
  • Team structures, topologies and interactions
  • Recruitment and onboarding/offboarding practices
  • Value stream alignment
  • Breaking down silos
  • Embedding the ability to change and adapt
  • Reducing cognitive load
  • Psychological safety in delivery teams, senior leadership teams and functional teams
  • IT services and operational technologies
  • Facilities, colocation, office layouts (especially options for open-plan or not)
  • And many many more – in fact, here is an (incomplete) list of organisational factors relevant to transformation.

Why digital transformation?

What’s your organisational goal? Maybe it’s increasing your speed to market for new products and features, maybe it’s reducing risk of failure in production and improving reliability, or maybe it’s to keep doing what you’re doing but with less stress and improved flow. If you’re only looking to reduce costs however, digital transformation is not for you: one of the core requirements for a transformation to succeed is for everyone in the organisation to be psychologically safe, engaged and get behind it, so reducing costs and potentially cutting workforce numbers is not going to create that movement.

What is Enterprise Resilience?

Resilience Engineering is a decades-old field of applied research that focusses on the capacity to anticipate, detect, respond to and adapt to change. Organisational “robustness” might mean being able to withstand massive disrupting events such as pandemics or competition, but enterprise agility represents the resilience engineering concept of true resilience – not just “coping” with change, but improving from it and future challenges. I believe that Resilience Engineering is the direction that DevOps is evolving into.

Why is digital transformation so complex?

Despite many attempts to simplify the concept of digital transformation, it remains one of the most challenging endeavours we could embark upon.

Galbraith Star model
Galbraith Star model

I’m not a huge fan of over-simplifying organisational complexity into components, especially models such as Galbraith’s Star that place “people” as one of the components (and certainly not models that consider anything other than people to be the primary element). Whilst models such as this may help people compartmentalise the transformation challenge, in almost every case, the fractures between the various components don’t actually exist in the way they’re presented.

Organisations are not simply jigsaw pieces of technology, tools, and people that react and function in predictable ways. As the Cynefin model shows us, systems exist in multiple different states. Complex states, such as the state in which most sociotechnical systems (the organisations that we work in) reside in, require a probe-sense-respond approach that applies built-in feedback loops to determine what effect the intervention you’re working on is having. Everything in digital transformation is an experiment.

upload.wikimedia.org/wikipedia/commons/1/15/Cyn...

It’s also important to avoid localised optimisation – applying digital transformation approaches to one part of an organisation whilst ignoring other parts will only result in tension, bottlenecks, high-friction and failures elsewhere. We must observe and examine the entire system, even if we cannot change it. Ian Miell discusses here in this excellent piece why we must address the money flows in an organisation.

Likewise, changing one small part of a system, especially a complex system, will have unintended and unanticipated effects elsewhere, so a complete, holistic view of the entire organisation is critical.

Digital transformation is a series of experiments

This is why, if anyone suggests that there is a detailed “roadmap”, or even worse, a Gannt chart, for a digital transformation project, at best it’s naive and worst, it’s fiction. Any digital transformation process must be made not of a fixed plan, but a series of experiments that allow for iterative improvements to be made.

Digital transformaiton - everything is an experiment

When you think about digital transformation in this way, it also becomes clear why it will never be “finished”. Organisations, like the people they consist of, constantly change and evolve, just like the world we operate in, so whilst digital transformation is undoubtedly of huge value and an effective approach to organisational change, you will never, ever, be “done”.

In my role as Transformation Lead at Red Hat Open Innovation Labs, we use the Mobius Loop approach to provide structure to this experimental, feedback-based, continuous improvement and transformation journey.  If you’re interested in digital transformation, DevOps, Psychological Safety and how you can begin to set transformation in motion in your own organisation, get in touch.

 

Remote Working – What Have We Learned From 2020?

Remote working improves productivity.

Even way back in 2014, evidence showed that remote working enables employees to be more productive and take fewer sick days, and saves money for the organisation.  The rabbit is out of the hat: remote working works, and it has obvious benefits.

Source: Forbes Global Workplace Analytics 2020

More and more organisations are adopting remote-first or fully remote practices, such as Zapier:

“It’s a better way to work. It allows us to hire smart people no matter where in the world, and it gives those people hours back in their day to spend with friends and family. We save money on office space and all the hassles that comes with that. A lot of people are more productive in remote setting, though it does require some more discipline too.”

We know, through empirical studies and longitudinal evidence such as Google’s Project Aristotle that colocation of teams is not a factor in driving performance. Remote teams perform as well as, if not better than colocated teams, if provided with appropriate tools and leadership.

Teams that are already used to more flexible, lightweight or agile approaches adapt adapt to a high performing and fully remote model even more easily than traditional teams.

The opportunity to work remotely, more flexibly, and save on time spent commuting helps to improve the lives of people with caring, parenting or other commitments too. Whilst some parents are undoubtedly keen to get into the office and away from the distractions of home schooling, the ability to choose remote and more flexible work patterns is a game changer for some, and many are actually considering refusing to go back to the old ways.

What works for some, doesn’t work for others, and it will change for all of us over time, as our circumstances change. But having that choice is critical.

However, remote working is still (even now in 2020 with the effects of Covid and lockdowns) something that is “allowed” by an organisation and provided to the people that work there as a benefit.

Remote working is now an expectation.

What we are seeing now is that, for employees at least, particularly in technology, design, and other knowledge-economy roles, remote working is no longer a treat, or benefit – just like holiday pay and lunch breaks,  it’s an expectation.

Organisations that adopt and encourage remote working are able to recruit across a wider catchment area, unimpeded by geography, though still somewhat limited by timezones – because we also know that synchronous communication is important.

Remote work is also good for the economy, and for equality across geographies. Remote work is closing the wage gap between areas of the US and will likely have the same effect on the North-South divide in the UK. This means London firms can recruit top talent outside the South-East, and people in typically less affluent areas can find well paying work without moving away.

But that view isn’t shared by many organisations.

However, whilst employees are increasingly seeing remote working as an expectation rather than a benefit, many organisations, via pressure from command-control managers, difficulties in onboarding, process-oriented HR teams, or simply the most dangerous phrase in the English language: because “we’ve always done it this way“, possess a desire to bring employees back into the office, where they can see them.

Indeed, often by the managers of that organisation, remote working may be seen as an exclusive benefit and an opportunity to slack off. The Taylorist approach to management is still going strong, it appears.

People are adopting remote faster than organisations.

In 1962, Everett Rogers came up with the principle he called “Diffusion of innovation“.

It describes the adoption of new ideas and products over time as a bell curve, and categorises groups of people along its length as innovators, early adopters, early majority, late majority, and laggards. Spawned in the days of rapidly advancing agricultural technology, it was easy (and interesting) to study the adoption of new technologies such as hybrid seeds, equipment and methods.

 

Some organisations are even suggesting that remote workers could be paid less, since they no longer pay for their commute (in terms of costs and in time), but I believe the converse may become true – that firms who request regular attendance at the office will need to pay more to make up for it. As an employee, how much do you value your free time?

It seems that many people are further along Rogers’ adoption curve than the organisations they work for.

There are benefits of being in the office.

Of course, it’s important to recognise that there are benefits of being colocated in an office environment. Some types of work simply don’t suit it. Some people don’t have a suitable home environment to work from. Sometimes people need to work on a physical product or collaborate and use tools and equipment in person. Much of the time, people just want to be in the same room as their colleagues – what Tom Cheesewright calls “The unbeatable bandwidth of being there.”

But is that benefit worth the cost? An average commute is 59 minutes, which totals nearly 40 hours per month, per employee. For a team of twenty people, is 800 hours per month worth the benefit of being colocated? What would you pay to obtain an extra 800 hours of time for your team in a single month?

The question is one of motivation: are we empowering our team members to choose where they want to work and how they best provide value, or are we to revert to the Taylorist principles where “the manager knows best”? In Taylors words: “All we want of them is to obey the orders we give them, do what we say, and do it quick.

We must use this as a learning opportunity.

Whilst 2020 has been a massive challenge for all of us, it’s also taught us a great deal, about change, about people and about the future of work. The worst thing that companies can do is ignore what they have learned about their workforce and how they like to operate. We must not mindlessly drift back to the old ways.

We know that remote working is more productive, but there are many shades of remoteness, and it takes strong leadership, management effort, good tools, and effective, high-cadence communication to really do it well.

There is no need for a binary choice: there is no one-size-fits-all for office-based or remote work. There are infinite operating models available to us, and the best we can do to prepare for the future of work is simply to be endlessly adaptable.

Measuring Psychological Safety in your Team

measuring psychological safety

We know psychological safety is crucial for high performance teams, and particularly so for technical delivery teams. Innovation is so critical for creating products that delight customers and serve critical business needs, and psychological safety is a fundamental enabler of innovation.

Below are ten questions that you can ask yourself or your teams to determine the level of psychological safety in your team. Rate agreement with the below statements on a scale of 1 – 5. 5 being “completely agree” and 1 being “completely disagree”.

When carrying this exercise out with your team, perform the survey anonymously – if it’s possible that your team are psychologically unsafe, they will be more likely to be honest if the survey is anonymous. If the team are very psychologically safe, then it won’t matter if the survey is anonymous or not.

It is also important to allow for qualitative, verbose feedback for each question as well, because that verbose feedback will facilitate and clarify some of the actions that you may need to take in order to improve these scores.

  1. On this team, I understand what is expected of me.
  2. We value outcomes more than outputs or inputs, and nobody needs to “look busy”.
  3. If I make a mistake on this team, it is never held against me.
  4. When something goes wrong, we work as a team to find the systemic cause.
  5. All members of this team feel able to bring up problems and tough issues.
  6. Members of this team never reject others for being different and nobody is left out.
  7. It is safe for me to take a risk on this team.
  8. It is easy for me to ask other members of this team for help.
  9. Nobody on this team would deliberately act in a way that undermines my efforts.
  10. Working with members of this team, my unique skills and talents are valued and utilised.

To explain the context behind each question:

1 – On this team, I understand what is expected of me.

It is essential that team members understand what is expected of them in terms of delivery (speed, quality, cost, and other factors) and behaviour (everything from dress code and punctuality to coding standards) to foster psychological safety. Ensure tasks are clear and well defined, behaviour expectations are explicit, and negative behaviours are dealt with.

2 – We value outcomes more than outputs or inputs, and nobody needs to “look busy”.

Outcomes (such as revenue generated or satisfied customers) matter more than outputs (emails sent, lines of code written, or meetings attended). If the team focus on what truly matters to the business, they are safe to make decisions that can improve outcomes, even if those decisions reduce output. The ideal is a team that possesses enough psychological safety to decide not to do something that could make them look good in the eyes of others, but doesn’t deliver outcomes for the business.

3 – If I make a mistake on this team, it is never held against me.

A psychologically safe team will never blame a member of the team for a genuine mistake if their intentions were good. Indeed, by enabling mistakes to be made without a fear of blame, you enable innovation and risk taking that can drive your organisation ahead of the competition. Utilise systems thinking and DevOps approaches to prevent mistakes before they happen or mitigate the impact of mistakes when they do.

4 – When something goes wrong, we work as a team to find the systemic cause.

Related to the previous point but important enough to warrant its own question, a system of discovering the root causes of mistakes and failures means that not only do team members feel able to take risks without being blamed, but every single “failure” is an opportunity for learning and improvement. By building psychological safety through these retrospective exercises, everyone on the team gets to learn from mistakes, meaning mistakes are a gift, not a threat.

5 – All members of this team feel able to bring up problems and tough issues.

In a psychologically safe team, all members of the team are able to bring up problems and tough issues, ranging from personal struggles to concerns about other (even senior) members of the team. This psychological safety is crucial for allowing both vulnerability to show when you’re struggling and need help, and courage to raise difficult topics.

6 – Members of this team never reject others for being different and nobody is left out.

Evidence shows that diversity in a team results in higher quality products and happier team members, but diversity in itself is not enough: it is crucial that team members are all included in decision making and delivering results. To facilitate psychological safety (and high performance) every member of the team needs to be invested in the decisions made and the outcomes generated. This is particularly crucial for remote and distributed teams, where it is more difficult to see if a team member is becoming disengaged.

7 – It is safe for me to take a risk on this team.

Mistakes happen unintentionally, but risks are about taking actions that might not work, or may have unintended consequences. Psychological safety provides the framework for positive risk-taking, enabling innovation and ultimately, competitive advantage.

8 – It is easy for me to ask other members of this team for help.

In psychologically unsafe teams, team members try to hide their perceived weaknesses or vulnerabilities, which prevents them from asking for help. In a psychologically safe team, members prioritise the team goals over individual goals. Helping others helps achieve the team goal, and because team members feel safe to ask for that help, psychologically safe teams achieve more of their goals than unsafe teams.

9 – Nobody on this team would deliberately act in a way that undermines my efforts. 

In an unsafe team, members compete with each other to achieve their individual goals, and may even undermine other team members if it could benefit them or it is perceived that doing so may elevate their “rank” within the team or organisation. In a psychologically safe team, that counter-productive competition doesn’t exist, and the success of the team is more important looking good in the eyes of others.

10 – Working with members of this team, my unique skills and talents are valued and utilised.

We all bring our own unique experience, skills and knowledge to the teams that we’re in, but we also bring our own prejudices and biases. In a psychologically safe team where members are valued for being their true selves, biases are less likely to manifest. Indeed, team members may feel safe enough to identify, raise, and discuss their own biases or those of other team members. By doing so, we provide space for each individual to maximise their potential from utilising their own unique skills and talents.

Regularly Measuring Psychological Safety

By measuring the degree of psychological safety on your team, you can begin to build your own unique strategy for developing and maintaining it. For instance, this may involve running more regular retrospectives or by workshopping the team’s values and behaviours.

Measurement is only a tiny part of the process. Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

Remember to be patient: this is a journey, not a destination, and work on your own psychological safety too. You can’t effectively help others if you don’t look after yourself.

Take this survey for yourself.