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!