I want to make it clear that any comparisons to context on TV or any other sources is strictly for illustrative and entertainment purposes and not aimed at anyone I know. This is a reflection on commonalities between the work environment and family gatherings that occur at the end of the year with a touch of tongue in cheek.

Context

My recent end-of-year holiday was spent with my partner’s family, celebrating Christmas and two birthdays all in one action-packed week.

Like many families, as they grow and spread out, gathering everyone becomes more complicated. Children become adults, go off to college or university, find partners, and get jobs. As a result, annual gatherings involve travel, coordination, meticulous planning, and a lot of coordination—meals to cook, events to organize, and ingredients to buy. In our case, we flew in from the UK, while others traveled from different states in the U.S.

For many, the end-of-year Christmas celebration is the main event where everyone reconnects. Of course, not everyone has family or chooses to celebrate with them, and for those, a more friends-based gathering is becoming increasingly common—think "Friendsgiving" as an alternative to or in addition to Thanksgiving in the U.S.

Hopefully, some of this feels familiar. The key point here is that a holiday gathering requires real effort. We call it tradition, it often feels more like a ritual—a carefully choreographed dance of planning, cooking, and eating (with drinks flowing liberally).

The Parallels

Think of your family group as a project team tasked with delivering multiple meals, complete with diverse dishes and the added complexity of dietary restrictions.

You have deadlines (flexible or firm, depending on how many glasses of wine have been poured) and a mountain of preparation to manage: what to cook, how much to buy, who will do the cooking, and how much cutlery is needed.

In many families, there’s usually one or two people who take the lead. Rarely is the work evenly distributed across a team. If you’re lucky, there’s a written or digital plan. In our case, there was a spreadsheet—shared with some people but not all (because part of the plan was organizing a surprise party). This information gap, well-intentioned or not, led to questions like:

• “What’s the plan for today?”

• “What time is meal X?”

• “What can person Y do to help?”

Then there was the well-meaning individual who bought extra ingredients when we already had plenty.

To complicate matters further, the family hosting the event took the planning reins, but this limited contributions from those who normally led the cooking efforts. Visual management was sorely lacking. I half-jokingly suggested a Kanban board on the fridge to organize the agenda and sequencing. The idea was praised and forgotten.

The Chaos of Good Intentions

When people ask how they can help—or worse, suggest last-minute changes—while the cooks are elbows-deep in pots and pans, it leads to confusion, multitasking, and sometimes a few outbursts. Good intentions aside, it’s a perfect storm of stress. This reminded me all too much of certain workplace dynamics.

Layer on top the traditional family roles: the youngest, the eldest, the matriarch, and so on. These dynamics further complicate the holiday kitchen, making it resemble a high-stakes corporate project under a tight deadline.

The Strategy

I took a different approach. I volunteered for the unglamorous but essential tasks—dishwashing, trash duty, and vegetable chopping—and played gatekeeper to shield the cooks from unnecessary interruptions. I fielded questions, delegated simple tasks to willing helpers, and kept the kitchen traffic-free.

When my work was done, I mingled with the rest of the family to keep them entertained (and out of the way).

Reflections

I don’t presume to “fix” Christmas at the in-laws—there are lifetimes of traditions, roles, and interactions at play. However, minor nudges can reduce chaos. This is not a company-wide agile transformation; it’s more like introducing a few lightweight processes. My goal was simply to make things a bit smoother.

While tensions may rise in the family kitchen, the intentions are always rooted in love. If you want a dramatized version of this dynamic, I recommend the holiday meal episode of The Bear (it takes kitchen chaos to an 11—yes, a Spinal Tap reference).

Goals for Next Time

• Create a visible plan—an Obeya wall for roles, timelines, and a list of one-time tasks (“buy eggs”) could be a game-changer.

• Focus on empathy and communication. Listening and understanding motivations (instead of judging) often reveals the heart behind holiday traditions—a way to honor loved ones, past and present, through shared meals and rituals.

While the family celebration was chaotic at times, it was filled with love. The food was delicious, and everyone largely agreed the celebration was the calmest on record.

What stories do you have?

How do you handle family dynamics and shared responsibilities during festive gatherings? I’d love to hear your tips, tactics, or funny moments!

Influences

Some other recent influences that contributed to my thoughts on the topic

1. Course: Cleaning Toxic Waste - Modus Institue courses in general but mor specifically “cleaning toxic waste” course which takes an in depth look at how people interact in the workplace and what anti-patterns of behaviours can occur that lead to levels of toxicity. These are far more nuanced than you might imagine, it isn’t about being a jerk although that sure is part of it. Jim Benson is one of my heroes and more recently I‘d like to think I can call him and the Modus team friends. For those of you who don’t know Jim Benson, cocreator / author of Personal Kanban with the incredible Tonianne DeMaria back in the mid 2000s. Jim is one of the most thoughtful humane thinkers I know and has a wonderful punk rock ethos to the world which is both fun with a strike of rebellion. I cannot recommend the course enough and Jim has a book on the topic he is finishing off which I know will be brilliant and the course offers you a peek into the book.

2. Blog Series: Failureship - by Chris Matts (on his IT Risk Manager Blog)

3. Blog Series: The Gervais Principle, or the Office According to the “Office” - (recommended to me by Chris Matts)

4. TV Series: The Bear and in particular the “Fishes” episode which explores a rather tense memory of a dysfunctional Italian American holiday celebration of “the seven fishes” which is a traditional meal of seven different fish dishes the day before Christmas say. Seven courses sound like a look and in the episode of the Bear it really becomes apparent, just how stressful, and toxic things can get when there’s lots of people present, people falling into their own roles and some people taking on tasks whilst other sit, watch the TV and wait to be served.

5. Movie: Office Space by Mike Judge (of Silicon Valley and Beavis and Butthead fame)

There’s plenty of other stories I am sure we are familiar with; the goal of this blog is not to catalogue the history of toxic culture in media but illustrate a few poignant examples that amplify the observations.

Photo attribution by Kelsey Chance on Unsplash

A New Chapter in Sydney

After 15 incredible years abroad, I’m thrilled to return to the “motherland” and see what the future holds. Fortunately, I’ll continue my journey with my current employer, TeamForm.co, a nimble company making waves in the ways-of-working, strategy to execution and teaming space.

What’s Ahead?

Moving back to Australia after so long will be an adventure. I’m eager to establish roots, build a local network, and reconnect with the community, starting with the people I already know. Meeting new people and finally connecting with others in person is something I’m really looking forward to.

My partner and I will initially settle in Sydney and take some time to find our footing. This move represents a bigger adjustment for my partner, who isn’t from Australia. However, the change in environment and climate promises to be refreshing for our physical and mental well-being.

Reflecting on 2024

The past 12 months have flown by. Working for a smaller, more agile company with a clear sense of purpose has shown me just how fast you can move when you’re focused and unencumbered by bureaucracy. After years in financial services at a large, heavily regulated bank, the contrast couldn’t be starker.

TeamForm’s dedication to enabling customer value has been a breath of fresh air. This isn’t a post about TeamForm, though, as much as it’s about how major changes—jobs, roles, organizations, countries—can open up new opportunities and perspectives.

Initially, I had concerns about making such a significant transition:

• Could I navigate a different organization, or was I only suited to my previous one?

• Did I have what it takes to succeed elsewhere?

• Were my skills and experiences transferable?

The short answer: yes to all three.

The longer answer deserves its own blog post. For now, it’s clear to me that both the “agile” and “product” communities are experiencing growing pains. As product management evolves, there’s a risk it could repeat some of agile’s missteps, such as over-reliance on one-size-fits-all solutions and certification-driven approaches. Chris Matts’ recent blog offers a thoughtful, yet tongue in cheek prediction of what could go wrong if this trend continues.

There’s no universal solution to every problem or context. While it’s tempting to package and sell such solutions, they often fall short of delivering the outcomes organizations seek. If we’re not careful, Flow could become the next over-commoditized topic. My friends Steve Pereira and Andrew Davis explore this in their 2024 book, Flow Engineering. It’s an excellent read, but like all methodologies, it’s not a panacea.

Looking to the Future

Despite these challenges, I’m optimistic about what’s ahead. The world is full of incredible people to learn from if you’re paying attention.

For this blog in 2025 and beyond, I want to share insights, reflections, and lessons across a variety of topics. My goals include:

• Helping at least two people land new jobs.

• Writing at least five blog posts here.

• Reading at least 40 books.

• Publishing at least five book reviews.

• Delivering at least two talks (meetups/events).

I’m particularly interested in exploring value streams, value networks, and what it takes for portfolio-level teams and teams-of-teams to interact effectively and continuously improve those interactions. I also want to deepen my understanding of socio-technical systems and the complexities they entail.

Additionally, I see opportunities to create more open-source and Creative Commons content to build shared language and understanding within communities and organizations. Too often, people use the same words but mean entirely different things. This is especially true for tooling vendors.

What Do You Want to See?

What topics would you like me to explore? I’d love to hear your thoughts and ideas. Let’s make this space a platform for shared learning and growth.

We have seen articles of late, that talk about organizations getting rid of ‘agile’ roles CapitalOne being the most recent example and it got me thinking.

There are many tropes of Agile and Agile Coaches that have exhausted organizations of late and it is really challenging for them to understand, let alone justify the cost of such a misunderstood role

Is the ‘agile coach’ a long-lived role within an organization, is it a transitional role, is it an anti-pattern or a different beast all together? I do not think there is a simple answer to this topic, it really depends on your organizations reason for change.

How are the agile coaches going to be organized?

• is there a central team / competence center?

• is there a federate model in place so that coaches are closer to the organizations they are working with?

• how are you funding the agile coaches?

• how are your agile coaches interacting in terms of a team and across the organization (are they in a community of practice)

• what is the relationship between your agile coaches and your scrum masters / delivery managers?

How are the agile coaches aligned in terms of strategy, goals and practices?

• Is the team of agile coaches aligned with a common set of priorities and goals of the coaching organization?

• Are the coaches aligned to the priorities of the people they are ‘coaching’

• Are the coaches there to be long lived with a given set of teams or do they roam to new areas after either a period of time or some kind of adjustment to the environment?

How are the agile coaches measured for performance?

• do the agile coaches have a set of performance goals that are unique to them, the team or the broader coaching population?

• what are the incentives in place for an agile coach, are they optimizing for themselves (e.g. internal recognition of doing a good job, being seen as helpful, having completed lots of training or are they acting as a compliance / policing function)

• is the agile coach there to stir things up and challenge the status quo on how the team(s) are performing?

• is the agile coach there to make the team happy or push the team to conform or perform?

Are you building, hiring, or augmenting?

• If you are treating agile coaches as an accelerator / change agent, you are likely to be hiring people that are used to going into an environment and then leaving after some kind of agreed context.

• This can result in local optimization, minor changes that make teams happy but do not embed the long-lasting behaviours of continuous improvement. This often happens when consultants come in, roll things out and then move on.

• External agile coaches are there to get paid to do a job — so they will often have easier ways of measuring things that seem useful but are often superficial outputs that don’t translate into team or business outcomes.

Some options

• Hire many agile coaches into full time roles

• Hire some agile coaches into full time roles

• Hire many coaches as contracting roles

• Hire some agile coaches into contracting roles

• Identify internal champions

When it comes to hiring agile coaches, I have written about this before.

Looking at the article I wrote more than a year ago, my view on how an agile coach fits within an organization has become more nuanced after seeing the effects of agile coaches in an organization with local incentives.

What is the career path for an agile coach?

Depending on how your organization is setup, there may not be a lot of clear options for your agile coaches, depending on the size of the organization you may have options like:

• Agile coach to more senior leadership

• Agile coach to more teams

• Specialized focus on areas such as product or technical practices

• Manager / leader of other agile coaches

• Taking on a delivery role (e.g. becoming a product manager, delivery manager etc..)

What is the talent pipeline for future agile coaches in your organization?

• Regardless of the approach you decide to take, thinking about the future of this role in your organization is really important if you want people to stick around and if you want to build a pipeline so that you don’t have to go to market to find another agile coach who doesn’t know your organization. Things like setting up a competency model can be helpful, treating the role as a real profession with a few possible paths for how one can get into the role, establishing a team who train, mentor and coach future agile coaches within the organization. Just be careful to not rely on linear models that follow a step-by-step approach as agile coaching is a broad set of common practices but does not have the boundaries that these models suggest, especially if certification is involved.

• If you are becoming an agile coach you really need to get used to the idea of ambiguity and constant learning, if you are not learning anything new you are already falling behind. Any ‘Agile coach’ who claims they do not read or invest in their learning anymore as they have done it long enough is missing emerging practices and broader disciplines like complexity science, anthropology etc.

• When ‘coaching’ keeps an eye out for enthusiasts and champions who show a natural enthusiasm to the approach and practices.

• Invest time in mentoring if they show interesting in becoming an agile coach, in my experience these are the people who will show the most promise within the organization as long as they have the support they need to develop and the expertise around them to deal with challenges they face that they’ve not yet had the exposure to in the past e.g. dealing with conflict, toxic leadership etc.

• These are all tricky topics that require ability and practice so going into such a cold environment can be dangerous. This is where having a small team of coaches who are there to coach the other coaches can be fruitful — it gives them a support mechanism to fall back on and enables them to broader their learning and experience from people who have learned many lessons in other organizations but may not have your organizations context.

• This makes for a powerful combination — expert agile coach and an internal coach working together.

Hard won lessons…

• One of the key observations over the past few years is that if you only hire people from outside of your organization to act as agile coaches you end up with more opinions on how things should be done than you may desire…

• Agile coaches are quite opinionated people and do not often work in teams so if you are bringing in a lot of individual contributors who are used to working solo — this can cause a lot of disruption internal competition based on who has the most ability etc. a kind of natural pecking order of who knows the most…

• This is a potentially dangerous scenario if you have individuals working on agile coaching assignments and there is not an incentive for those people to work together to share knowledge, to pair and work on things together.

• This is where you can work as a team to produce shared goals for the coaching team so that you have a mixture of goals that are based on their individual coaching focus, a goal around team collaboration and a goal around overall community contribution e.g. presenting, sharing, teaching, mentoring etc..

• This is one way to express intent to the team so that they know behaviourally you are not looking for a team of individuals acting in isolation but instead a team of practitioners who work together to solve problems, learn, and grow from each other.

In summary… is all hope lost?

• I challenge you to consider the above and review your rationale for your approach on a regular basis.

• Think about how you give your agile coaches and future agile coaches a career pipeline, skill / competency for progression and make sure that they are supported with training, mentoring, and coaching or they will leave.

• Regardless of the approach you take to agile coaches, work with people who have been through similar context before, make sure they are pragmatic (rather than dogmatic) and focused on enabling the teams to be self-sufficient rather than becoming the teams admin / cheer leader.

• Decide on the types of outcomes you are going for and if you think that your organization can reach a stage where it can self-sustain its own continuous improvement and learning through communities of practices and with leadership acting as coaches? If that is achievable then you may not need to have agile coaches long term, you may however need expertise in certain domains such as technical practices, leadership coaching, product coaching etc… there are areas where ‘those who remain’ may end up specializing or contributing.

• A certain type of agile coach, who is used to a rinse and repeat approach — like to go into organizations for a couple of years and help teams get setup but are not interested in finding the underlying cause of hard problems that they may be facing (e.g. architecture. leadership, quality etc..)

• Do not be surprised if those coaches look to move onto the next gig after 18–24 months, they naturally reach a limit with their ability to change and influence and find it easier to move to the next engagement rather than roll up their sleeves and jump into the trenches with the teams.

• This can be ok if you know what you are collectively getting into, this will require clarity, trust and safety in the coaching team so that everyone knows what each other is looking for from the role they were hired to do. There is a time and a place for different types of coaches — just make sure you go in with your eyes open so that you know what is needed at the time and you have the necessary organizational probes in place to know when the coaching approach / stance is working and when it needs to adapt.

Things to look out for…

• Organizations can reach a natural state of equilibrium which could lead to a rejection of agile coaches. You can think about rotation as a way of keeping things fresh and even better if you have coaches working in teams, they can already be more familiar with the domain and teams even if they don’t already know the teams in detail.

• If you bring in an agile coach from another organization — the team(s) will not care how much expertise the agile coach has if they do not understand the business domain the teams are working in. To me this is a case of learning your domain and adopting language that works in your environment rather than coming in waving hands about theoretical practices that the agile coach has used in the past — not in ‘this context’.

• Another scenario I’ve seen many times, is when the agile coach is a ‘professional agile coach’ they get judged for not having ‘delivery’ experience, this can be a particular problem for teams who think they do not need a coach or are sceptical they can learn anything new from an outsider. I find in most cases coming in with an agenda is a surefire way to get kicked out of the room.

• Teams won’t trust you if you are here to implement things, you need to gain their trust and to do that you need to prove value to the team.

• Look for pain points and challenges, go and fix them, no matter how small. This will generate goodwill and eventually the teams will open up to you about the real problems they are facing. Anything they reveal before that is likely to be surface level.

What to do in a cross-functional team, when your organization is still using its existing approach to performance management and compensation.

This is one of the hardest topics to change in an organization, before you get yourself disappointed (in search of a silver bullet) — realise that there are things you can do in your cross-functional team. Things that do not require you to overthrow the whole organization’s system.

This topic is often categorized as ‘here be dragons’, if you are looking for the complete overhaul, you are going to need executive leadership (including CEO and your head of HR) to sponsor the change.

As an incremental approach — look for ways to small make changes, that help reduce friction between outdated systems and more modern ways of working. This topic strikes at the heart of an organization, it directly impacts everyone who is an employee (or part of the system).

Taking small steps is helpful for teams, be careful not to create a divide between teams and executive leadership. Executive leadership are actually meant to be a leadership team, with shared goals and outcomes. In some companies, executive leadership are compensated based on overall company performance (or at least as a percentage) compared to their own departments performance.

This is a start, quite often the wider organization is not aware of this. It may be a useful device to discuss with people looking for radical revolution to meet somewhere in the middle. You can start by looking at the company quarterly and annual reports to see how compensation works. This is also a good first step to discuss and how it can affect transparency, incentives, strategy and goals.

Understanding how your teams' goals contribute to the overall company strategy and goals is important and a way to combat local optimization to the point of reducing internal competition and instead enabling alignment towards common goals and outcomes that help the company over the department / division.

Have you been here before?

For anyone who has worked in an organization with individual performance reviews and incentives, you know there is a game people play to capture feedback on things they’ve done (‘achieved’) throughout the year in the hope that their manage will prioritize getting them a decent bonus (often the same or hopefully better than last year regardless of relative improvement).

This can end up with a last-minute flurry of grandstanding, over communicating and sharing praise (just as the reviews are being ‘locked in’).

Internal competition has always felt dangerous, if you are working for the same company, the customer only benefits if the company is doing well, not if one department or set of individuals do well and the rest do not. This is often where the analogy of a sports team comes into play.

Having an opaque system, only visible to leadership, creates a divide of workers and managers. It can feel like a game of roulette, where your manager decides where you land, compared to your peers.

When not working well, the process can be subjective or worse, based on the strength of your relationship with your manager. Do outcomes matter if your boss likes you? (sarcasm) This type of rating ends up being about individual contributions and often output related ‘things you did’ rather than outcomes realized as a group.

Having shared goals causes friction with an individualistic performance management process, it is hard to tell how one individual contributed to a shared goal compared to those in the team. This is even worse when the process and goals are annual and rely on feedback from others. The manager really needs to understand the work and the employees contributions, objectives and ideally, employees are coached by their manager continuously. This also means adjusting the goals over time to better calibrate the current reality vs something written 6–9 months ago that is no longer relevant. COVID was a prime example of this but you will on doubt think of your own recent examples where things changed drastically in your organization.

Recommended reading: an interesting book on this topic by Alfie Kohn (who also wrote ‘punished by rewards’)— No contest: the case against competition — Alfie Kohn 1986.

People end up resorting to strange, but expected behaviours, which prioritize the individual over the team — let alone the overall organization.

Note: moving to cross-functional teams that you intend to be empowered and aligned inevitably end up having incompatibility with an existing performance management system that pit individuals against each other.

Key questions people tend to ask

• individual goals vs team or team of teams etc.

• who performs the review, if the individual is in a cross-functional team

• if the individual does well but the team doesn’t realize the outcomes will the individual be unfarely penalized

• are individuals in a cross-functional team measured individually or against each other

• how does this work if the team is composed of different roles e.g. product vs engineering vs design.

Small steps

• have the team establish shared objectives and review the objectives periodically (e.g. every quarter)

• have individuals goals that focus on learning outcomes (individual learning / stretch objectives that allow the individual to demonstrate own leadership and learning behaviours), team outcomes (support the teams development e.g. helping others learn new skills / capabilities), community outcomes (e.g. contribute to a community of practice in multiple ways)

• as a team, talk about the individual contribution towards the goals / objectives, consider if this can be done in public rather than 1:1 or only in a system of record

• ensure that the line manager of each individual has a view of the feedback from the cross-functional team and an understanding of the cross-functional goals

On motivation

We know from research and books like Drive by Dan Pink, that the effects of extrinsic motivators have limited long term appeal on people, when compared to intrinsic motivators (mastery, autonomy and purpose) — what many people struggle with is how that works in the context of a team vs the individual.

We also know from Punished by Rewards by Alfie Kohn that punishment or reward can have an adverse effect on people — even when we have the best of intentions, by doing something good for people — the pat on the head type approach. Without thinking, topics like gamification, public praise, and just well meaning ‘good job’ type comments can really affect how people behave.

People are familiar with giving everyone a trophy for ‘participation’ where people are rewarded for not doing anything of note but taught that they deserve recognition anyway. What is lacking is people’s ability to thoughtfully praise the behaviour, as opposed to simply the results.

This is quite easy to say and in practice quite hard to do. Many people working in organizations, have annual performance reviews which incentivize people with financial incentives and promotions.

How do you feel your organization it setup to enable the individuals and teams for success?

Is your organization rewarding learning, behaviour and team focused outcomes or are they using an outdated model where individuals are pitted against each other and left to a chance process, where your managers influence plays a larger role in your future rewards than your actual contribution.

A more significant change is to drop stacked ranking (typically where parts or all the organization is mapped to a bell curve usually between a 3 or 5 rating scale. This is sometimes using 2 different dimensions around goals and behaviors but this is usually just a mechanism to differentiate compensation and promotion. Dropping of stacked ranking happened at Skype and eventually Microsoft (see Microsoft insider blogs from 2004/05).

The approach used was a study of the effect stacked ranking had on the organization and how the numerical approach just did not work — getting rid of or not compensating a certain percentage of the population puts potentially great people at risk. A simple example — if you have a team looking after the legacy systems that has technology that is hard to source in the industry and those people leave you put the whole company at risk. In extreme cases e.g. Jack Welch at GE famously did this with rank-and-yank where the bottom x percentage of the lowest population would get fired to ‘motivate’ others to work hard. If you have a high performing organization and everyone is doing a great job then you are getting rid of great people because of a flawed system. This encourages people to only do better than the bottom rather than aspire for something greater.

Changing the system

If the people responsible for changing these systems and processes are also participants in the system itself, what are the incentives for them to change how it works if they risk affecting their own compensation and incentives in the process. If it easy to be sceptical on these topics of course, many large companies have more complex / nuance reward recognition approaches when it comes to senior leadership where there are incentives are put in place to be spread over a longer period of time as a way of helping limit the focus on purely short term benefits. This is a great move in my mind given the existing system we find ourselves in but are those timelines long enough to encourage the types of long-term thinking and benefits we want out of an organization.

That is an interesting question and explored by W Edwards Deming in his work as well as a recent book Learning to Lead, Leading to Learn by Kate Anderson with contributions from Isao Yoshino from Toyota fame. In the book they talk about Toyota having a ‘100-year plan’ which is a document that gets updated every 5 years as a process to get the company to think, not only in the short term e.g. quarterly results but the medium and long term views as well. These long-term views way cause a nervous reaction to the ‘agile’ types who somehow are allergic to long term planning — I see this more about understanding vision, strategy, and purpose for the organization and what long term changes a company is to make to make meaningful change in the world.

Given that Toyota is traditionally thought of as a manufacturing company the time scales people work on are likely to be different to a pure services / digital product company, I find the important take away (much like in public office) that systems put in place to make changes that can only be measured in the short term tend to be the changes people make — in government 10–20+ year investments which will far exceed your average politicians tenure at the top and then the competition come in they are also likely to change what the previous ‘party’ did, it makes things that much harder.

Edit: I recent heard on a recent podcast with Joe Justice, Elon Musk plans on a 1,000 year horizon — that makes sense given the super ambitious goals his companies tend to aspire to, Joe talks about the granularity in the podcast and doesn’t have detailed plans out that far in advance.

The notion of a north start / moon shot can be powerful when it comes to enabling an organization to align on a common purpose and direction of travel. This type of mechanism is a way to get an organization aligned around common outcomes and is an opportunity for people to move away from individual performance and compensation incentives.

I would be a hypocrite if I said I did not enjoy the prospect of a bonus at the end of the year, but is the pain / effort and anxiety it causes people throughout the process and on ‘the day’ worth it? That is a question I ask myself regularly. Quite often people find out ‘what they got’ and do not have clarity why they did better or worse than a peer in the same team, if often feels a bit like a lucky draw at times. There’s little transparency and people feel that they are at the mercy or the organization in the process. This is along winded way to say that an annual bonus can also be a disconnected way of giving someone the pat on the head that someone else thinks that they deserve, quite often without understanding how the rewards relates to the behaviour or outcomes. A great manager will often do a far better job of delivering this message but even with the best of intent it is a strange experience.

What is more motivating than finding out your colleague got a great bonus when you are the one who was helping them improve all year? Is the organization rewarding the results, the behaviour, the team — there are many possible variables and this is even less obvious in a cross-functional team with multi-discipline colleagues working together some different skillsets e.g. how do you value a SW engineer vs. a product manager vs. a product designer.

So what is the answer?

• There are a number of options to explore that will not end up looking like a silver bullet

• This is the most challenging part of changing behaviour and ultimately culture in an organization looking to become more ‘agile’

Is it even possible?

Can you really change your performance management and get the results we all aspire for, quite likely no — it is just one of a number of elements that are needed to put the systems in place to change how people work and how they measure and improve. If we look at Beyond Budgeting for example they tie performance management into a wider context of targets, forecasts, resource allocation, performance evaluation, rewards, coordination — looking at one in isolation is detrimental.

• I encourage you to investigate Beyond Budgeting and what they have been doing there for many years 25+ in some cases, they have case studies, books and lots of great literature that is helpful but not overly prescriptive!

On reward

There’s three ways to reward people (shamelessly taken from a chat I had with Chris Matts)

1. you give someone a bonus (private — once off / discretionary)

2. you give someone a pay rise (private — cumulative)

3. you promote someone to the next rank (public)

Think about the 3 types, yes, they are all possible in a good year. If you want to signal to your organization that behaviour is what you value most for the organization — you should choose to reward behaviour — since that is public, you should be looking to promote the people who best stand for the behaviour the organization wants. If you are trying to change culture and ways of working — this is a highly effective way to signal this to the organization. Behave how the company likes and you will be rewarded.

Sometimes you will need to keep people happy that do not behave in way that you’d like to make public and let them know their results are being rewarded but not their behaviour — then a pay rise is most likely the choice.

Finally, if you cannot promote someone due to quotes but want to at least express in private that someone is showing the right behaviours then pay rise is a nice way to do this as it keeps year on year so every pay rise you get will be on top of the last one.

Then those you may be rewarding with only a bonus (the results reward type), they may choose to stay and adapt their behaviour based on what is being recognized or they may choose to look for another role internally or externally.

So as a leader / manager considering options, there are levers you might want to think about.

I am in favour of ideas like profit sharing, you might think of me as a hippie. I find it hard to have shared goals and outcomes, yet not shared performance and compensation. You can read up on the alternative options to compensation in Beyond Budgeting and other such books like Corporate Rebels and Radical Enterprise

So what steps can be taken?

• what ever you do, pilot it and don’t do a big bang / monolithic change, use feedback from employees to drive how the approach / process works

• think about what you are trying to signal with your system

• for existing processes, more frequent gives people an opportunity to more closely align with goals vs outcomes vs ability to adapt

• a monolithic set of annual goals for individuals and teams is a strait jacket for an adaptive culture

• don’t rely on a tool or some expensive large consulting firm to do all of this for you, you should actively learn and participate in meetups / communities, read up on the latest trends etc but don’t fool yourself into thinking just because other companies are doing something that ‘we should too’

• every company has its own unique identity, values and culture so copying someone else’s approach is at risk of being rejected by the organization for something that is inflicted on people rather than based on the organizations context

The holy grail

It is easy to blame leadership for everything these days, but the employees outnumber the leadership / management by a good amount. So, whilst you cannot radically change the way an organization works by yourself, it is possible to make progress to make your team or department's lives a little more enjoyable when it comes to performance management.

If you really want to turn things up to 11 (Spinal tap reference), you are going to need complete leadership by in and sponsorship. If you don’t have that, it is incredibly unlikely to go very far, this is because they are part of the same system as you are (in most cases) so unless the changes benefit the organization and the executives it is really going to be extremely difficult to change.

What other approaches / systems / resources have you seen work well?

Some interesting resources
- https://deming.org/dr-deming-called-for-the-elimination-of-the-annual-performance-appraisal/
- https://deming.org/deming-on-management-performance-appraisal/
- https://www.youtube.com/watch?v=2F1rhik2_X0
- https://www.alfiekohn.org/punished-rewards/
- https://www.danpink.com/books/drive/
- https://kbjanderson.com/learning-to-lead/
- https://www.bcg.com/publications/2020/budgeting-in-an-age-of-uncertainty
- https://bbrt.org/wp-content/uploads/bb_principles.pdf
- https://hbr.org/2016/10/the-performance-management-revolution

Editor note: Chris Matts pointed out that John Cuttler also has a blog by the same name, I only found this out after I authored the article and was not ready to rename the article. Check out John’s article here.

Complex adaptive systems

When large complex organizations invest in ‘Agile Transformations’, they look for results often more quickly and larger than is realistic. Words like Agile and other overloaded terms like velocity sound desirable — who doesn’t want to go faster?

That can have consequences on teams, the organization, and the agile coaches are often then ones expected to deliver the changes rather than the organization as a whole — quite often local optimization is only possible in the short term as tackling systemic impediments requires buy in from across the organization.

This is further constrained by a complex web of challenges that includes, new roles, organizing structures, metrics, tooling, terminology, and a significant number of agile coaches who in many cases are new to the organization and often full of hope and internally perceived as theoretical hand-wavey types living in the clouds.

“you do not understand our challenges,

we have different problems to other companies”

— incumbents

This is best illustrated by incumbents being sceptical to the changes and risk averse, so they ask for agile coaches for extremely detailed checklists, templates, role & responsibilities definitions that are now far more granular and constraining than how things worked before.

Ironically this approach ends up creating more learned helplessness rather than less as the so-called empowered teams are now dependant on templates and checklists to know how to do their job even though in many cases it is only marginally different to before.

As soon as things get difficult or off-piste then the templates and agile coaches are deemed ineffective.

Learning to learn

When executives think that agility only happens at the team level, there are limited opportunities outside of local optimization. A high paid executive who is nearer the end of their career is not looking to fundamentally change how they lead. So before you can learn how to learn, you must learn how to see (the system of work).

An organization needs to learn how to shift from focusing on the delivery of work to also focusing on how the system of work is performed and improved. This involves a lot of learning of ‘new’ practices for the organization which many of the individuals were aware of, but seldom have the discipline to put them into practices. Learning how to learn and improve is critical if organizations want to deliver customer value and keep up with the competition.

Sadly, many organizations expect “Agile” to solve their problems. The reality is that agile simply helps you find out the problems, it doesn’t tell you how the solve them. This is ironic, as Agile is often sold as a solution, executives expect it to solve things. This creates tension when an organization is looking for answers. They don’t find it helpful then they are told that they are empowered and need to think for themselves.

Focusing on the small

Often organizations end up with measurable improvements (changes) through the Hawthorne effect as any more meaningful outcomes require time and effort to reap the benefits. Agile coaches are desperate to demonstrate their value-add and the savvy amongst them are looking for small victories to help amplify a coaches impact in the short term when in reality things take longer and they are likely to happen in incremental steps, and at different rates throughout an organization.

This can also lead to agile coaches spoon feeding teams to quickly get them up and running but the teams aren’t learning the why or what to do when things stop working or new problems are uncovered via retrospectives.

I’ve seen this happen with other improvement programs such as a lean or simplification program where people optimize to meet targets, rather than establish a culture of continuous improvement. Programs have end dates, which puts a big damper on the continuous part.

The priority ends up being to get teams into a regular cadence, measuring four or so metrics and little context as to why they are doing them. The gap between a new scrum master and a seasoned agile coach is significant and giving people a little knowledge can be more harmful than useful in the medium to long term.

People try things until they find edge cases where the practices do not work and either revert or try to do things without any support and end up tying themselves in a knot as they do not have an experienced practitioner by their side to help them through the learnings.

This is foundation building, rather than a sustained rhythm of learning and improvement. Teams, especially those with existing systems / applications, are in dire need of refactoring / rearchitecting and rarely supported by stakeholders to invest the time and effort into improving their ability to build, test, and deliver.

One metric / dashboard to rule them all

One approach people take is deploying standard metrics across an organization used in a consistent way, this addresses enterprise concerns such as data sourcing, common approach to calculations and a ‘consistent look and feel’.

When these metrics / dashboards are surfaced organization wide, leadership cannot help but compare their teams vs their peers. A common anti-pattern is velocity — why would you not want to keep increasing that — what could go wrong. How is that any different to cracking a whip?

This can be destructive and there is a whole host of topics wrong with ‘vanity metrics’, especially if leadership compares teams across the company rather than within their own organization and context, this leads to shaming rather than supporting.

This can be further complicated when the agile coaches in the organization become the enforcement of the metrics e.g., team A is not performing — the coaches will be set to go and fix the team's performance. This absolves leadership of any opportunity to understand the system work and the constraints the teams may be facing.

When it comes to metrics and how the metrics are presented, be careful those metrics do not turn into a beauty pageant for teams who are not suffering the same impediments as others. I know countless teams at the mercy of 1990s era architecture styles that have constrained the teams so much that they don’t know how to engineer their way out.

I suggest you limit the views to a specific persona / context to enable useful, rather than harmful views. Some metrics are useful for a team, others are more useful to a team of teams or above. When metrics are made visible to higher levels, they should be summarized to protect the innocent.

I’ve seen this happen with the infamous DORA metrics, it was too hard to measure things due to tooling data model gaps, so they measured a proxy based on a JIRA attribute, this led to teams creating fake JIRA releases to look good as their management set explicit performance targets.

Think in terms of relative improvement, this way we are encouraging improvements to the system of work, rather than a race to an artificial target. A target most teams were never going to hit given their technical debt, technology stack and a whole host of other variables.

Another thing to watch out for is the cadence of the business and products in question, in parts of an organization where they have business models that benefit from time to market, teams will face far less resistance than in parts of the organization where people are more conservative, risk averse and focused on longer term sustainable revenue (e.g. a bank with 30+ year mortgages) or controlling functions (e.g. your compliance department).

It is quite likely the teams that are already doing well, have already overcome their own impediments over years rather than anything that was recently done to a centralized effort.

E.g. automating tests takes time and building up stakeholder trust, if you want to speed up your time to market you must increase quality and that quality needs to be repeatable — that is where a healthy amount of automation and testing can used to demonstrate that things are improving and they now need far less manual inspection as quality is being built into the work rather than after the work.

Justifying existence

If you are an agile coach and new to a team or the organization, it is incredibly unlikely that a team will feel comfortable enough to share actual issues they are facing if they think you will run off to management. Transparency and honesty require trust, which takes time. Turning up to a team’s next meeting with a set of red metrics is only going to cause the team to close off.

Things get complicated through incentive alignment, or how agile coaches prove value to the organization. There is a real chance where the agile coach is more interested in outputs of teams (or worse) the agile coach themselves.

This perverse incentive usually ends up challenging integrity. They need to decide between supporting and nurturing the teams vs. focusing on reportable. Things such as events held / running, training completed, maturity assessments performed or changes in metrics like velocity.

So now what

One of the constraints we all need to be aware of is the top leadership patience and expectation of a return of investment. This is particularly tricky when leadership is not used to thinking in terms of outcomes and are looking for measurable outputs or big changes. This is an impedance mismatch — we are looking to create sustainable change and continual improvement over time. That is harder to demonstrate especially when things often get worse before they get better.

I’ve seen this happen too often for it to be a myth. I believe this is the case because there is so much inefficiency in the system of work that once things change, the perceived productivity drops — when teams are trying to focus on getting some work done, rather than doing all of the work but never completing anything. People tend to confuse this ‘being busy’ with being productive, doing lots of work and not finishing it quickly is not a good measure.

An agile coach has a small window to help the team move out of the trough of despair and back up to something more sustainable. The challenge is managing the expectations of stakeholders who aren’t comfortable hearing that a team may not do work they are expecting to happen to have delivered.

Putting expectations into context with leadership is critical to enabling sustainable pace of improvements, especially when quite often things get worse before they get better — we see this in the Kubler-Ross model J curve / Satir change model / Diffusion of Innovation etc.

This is further worsened by language such as ‘fail fast’. If your organization is risk averse this is the last thing you should be doing if you are looking to create organizational awareness of validated learning. Having language that works in the organization is far more effective than what is in the textbooks. This is incredibly important if you want things to embed, beware of people who already know the terms thinking that you are washing the integrity of the terminology away. Real practitioners will not have a problem adapting to company specific technology.

Wrapping things up

Investing in metrics, dashboards and visualization is essential if you want to measure improvements to ways of working, however what you measure, how you measure and crucially how you visualize is even more important from a behavioural perspective.

Teams won’t trust agile coaches if the data is being used to ‘snitch’, if teams suspect the data will be used for enforcement or punishment, they will gamify things to get management off their back.

Having useful incentive systems in place can really help here e.g., using relative improvement metrics for comparative views rather than absolute, not just as a team level but also organizational.

You can make improvements fun like an awards ceremony rather than having explicit absolute targets. e.g., most improved over time, most sustained performance, most helpful teams (a team who helps other teams).

If you treat improvement of work as important as the work itself, invest in regular retrospection driven by data, people can discuss problems based on the data rather than just their opinions.

Consider keeping the number of agile coaches you introduce to a low number but with high degrees of expertise, instead have a small team of experts that focus on capability building ( an agile coach production line) that has a clear set of exit criteria and a few named individuals who will remain if they choose so that everyone has a clear view on how things should work when the ‘transformation’ dollars are spent. This will also ensure that your central group of experts are not expected to always be there for a team, and they know that they need to learn themselves over time.

There are no silver bullets, we are not hunting werewolves.

I was recently at a book club and someone made a point that got me thinking. The book club was discussing Jim Benson’s amazing book “The Collaboration Equation” read it and rejoice!

I recommend Jim’s work, both he and Tonianne are an inspiration and their work and learning content is up there in terms of value for money and impact on my own behaviors and how I think about the world.

The comment was in reference to how Jim’s book focuses on humane working practices and professionalism. From Jim’s point of view, Lean and Agile just don’t focus enough on humanity.

Someone suggested that agile attempts to cover this in the Agile Manifesto lines:

‘We are uncovering better ways of developing software by doing it and helping others do it. 
Through this work we have come to value: 
Individuals and interactions over processes and tools

Source: https://agilemanifesto.org/

That got me thinking, yes, we are trying to uncover better ways of ‘working’ by doing it (adapted for non-software), people often misinterpret the topic as ‘Agile is better than Waterfall’.

Why I suspect the over simplified messaging of Agile vs Waterfall wasn’t intended to be so simple and lacking in nuance. I have reflected and see the messaging as learning and adapting in how we work as the ‘better ways of working by doing’.

Thankfully, the Agile Manifesto doesn’t go into specific practices and instead focused on values and principles (a way to remain timeless) but also an opportunity for everyone else to try and fill in the gap with their own interpretations, products, and certifications.

This is typically further amplified by people (falling into the Dunning-Kruger effect trap) of espousing ‘xyz isn’t agile’. Quite often because that person knows just a little (e.g. a 2 day course) and they’ve not had years of practice and learning to understand the breadth of the domains. I really dislike the oversimplification of something being a binary is or isn’t. Life, people, and everything just aren’t that simple (edit: clear in Cynefin).

Next time you hear someone saying something is or isn’t agile, get them to walk through what they really mean. You both might learn something. I am not a fan of the trope of the ‘agile police’ a group of agile practitioners in an organization who correct people not using the words / terms ‘correctly’. If it comes to that, then your organization is missing the larger point about ways of working.

Having observed a significant amount of change and transformation in the past few years around ‘Agile’ (the good, the bad, the ugly), things are usually not what they seem and require additional inspection. Forcing conformance is always dangerous, this is why ‘Agile Transformations’ inflicted onto people rarely stick with long lasting impact.

I will refrain from all the ‘agile is dead’ rhetoric, but I can see the impact the ‘agile industrial complex’ has had on how people see and behave when it comes to these practices. Running around using new terms and correcting others for using different terms is missing the point entirely.

These days I try not to use the ‘agile’ words as much as I can and try to understand the context of the people / teams I’m talking to and meet them where they are, trying to avoid introducing new jargon as much as possible. I see the same happening with other words like autonomy, empowerment, psychological safety, failure, and I’m sure there are many more you would relate to.

In summary

Talk to people, don’t lecture them. Help them with the problems they are facing rather than you trying to inflict new processes because of a company mandate.

Practices are context sensitive; uncertainty and ambiguity are rampant in knowledge work. Focusing on the team and building the team's trust so that they learn the value of regular learning and improving is what gets the outcomes.

Extras

Check out books / videos by

• Rob England (The agile manager etc.)

• Daniel Mezick (The Culture Game etc.)

• Jon Smart (Better Value Sooner Safer Happier)

• Joshua Kerievsky (soon to release: The Joy of Agility)

A few views with Jim Benson that I recommend you watch!

Having started this blog in 2022 and keeping to a regular routine, I thought it would be interesting to capture some lessons learned.

Observations

Writing is easy enough, filling a page with content is easy enough. Writing content that people like and engage with is really challenging. I have a long way to go in that respect, I’d love more engagement.

Aside from the ego aspect, I want the engagement so that I can learn from my readers in terms of what works and what doesn’t. So far, the only meaningful metrics I’ve managed to get from Medium are around views and average time on each article.

I see a general correlation that shorter articles do better than long, but I don’t really know why that is. Is it reader preference or am I boring people and waffling on? These are areas where I’d like to learn and improve.

Quality

I’ve typically taken an iterative approach to refining my content, I am not a perfectionist. I am keen to improve the quality of my writing, I also appreciate the ability to go back and edit content for readability / conciseness etc.

Some options I’ve explored:

• Beta readers: sending out a draft copy to a few people for input → it can be useful, but results may vary and if you are working to a clock / schedule this may not be a good option.

• Listening to your article using text to speech (have it read out), this is quite a good mechanism for me as I tend to hear things better than reading them off a page (hence why I listen to audio books over traditional reading)

• Writing the content in advance and then revisiting a day or two later with fresh eyes → this has worked well for me where I’ve been able to stay organized enough. My fall-back option here has been to simply re-read what I’ve published a couple of days later and then make tweaks and republish.

Motivation and frequency

This one has been challenging, sticking to a weekly cadence, and publishing has done a lot in terms of habit forming and discipline but it has taken its toll in terms of work life balance. Taking a time boxing approach is useful here in terms of not spending too long on an article and separating ideation and research from the writing itself has yielded the best results.

I now keep a concise list of ideas for articles which I continue to maintain and refine but don’t constrain myself to if inspiration strikes, I can write something I wasn’t planning to.

I might experiment with having multiple articles written in advance so that I have a short buffer of content I can use, instead of writing and publishing all in the same step (which creates a lot of unnecessary pressure).

Looking to next year

I’m going to continue to write this blog, the location / platform I use may change for better analytics and engagement. I enjoy the outlet especially as it helps me crystallize my thoughts and keeps as I learn and reflect. Perhaps you will find the information useful to you too!

I have enjoyed the dialogue I have had this year with readers, I’ve made lots of awesome new friends and look forward to strengthening my network and knowledge.

What would you like to see out of this blog in the new year? (content / format etc.)

What article did you enjoy reading the most?

Happy new year everyone!

I’ve recently started getting into the topic of user experience, design and what it means to run a team of designers, thinking about how designers can effectively engage with cross-functional teams. One key pitfall I’m keen to avoid is having designers end up like architects, where they are always trying to get more engaged but only perceived to be desired when the team needs them.

These roles are specialized and not embedded in every single team. This tends to lead to the problem where these specialists get involved too late. This makes it hard for them to make impact as they are often seen coming in telling teams things that would effectively derail their work for weeks or months depending how much focus has been placed on the architecture and design of an application / product.

Having worked as an architect for several years, this was a common occurrence in the past. Teams would come looking for you when they realized that they couldn’t proceed to deploy without the architects ‘blessing’. This experience often ended up in a log jam as architects raise concerns that teams often don’t think of when they are trying to ship code.

Thankfully, this type of thing happens less and less, but many people are familiar with the anti-pattern of where an individual / SME is needed but the team only realize too late and then bring them in just before the team are looking to do their first release into production.

The moral of the story is to get engaged as early as possible, build relationships with teams, and get them to understand how you are there to help rather than hinder and if these discussions happen up front then collaboration and a smoother glide path is possible.

Back to design and user experience, engaging earlier and more often is an opportunity to create value and often to create cheaper and faster feedback loops. We know from ideas like MVPs and similar that validate your learning as early and cheaply as possible allows you to not fall victim to your own confirmation biases and validate or invalidate potential ideas as early on as possible.

Like all things in life, there can be too much up-front design / architecture / analysis, so it is important to do these things in a way that allows teams to learn and iterate with their approach. What is clear is that the later in the process a team is, the more costly change can often be. The alternative is often a refactor or a significant redesign and that often causes a lot of friction with the team and the SME often feels like the bearer of bad news.

I imagine it can be quite easy for a UX designer to over design an experience for a product, which can lead to the designer being too committed to their artefacts / design. Low fidelity wireframes and prototypes are often a good balancing way to keep things light weight and not gold plated.

If your product manager or stakeholders cannot stomach low fidelity mock-up of a design, then having a design system can allow for faster but ‘better’ looking wireframes that are closer to what you’d like in real life but be careful again with the biases that people can interpret a high-fidelity prototype / mock-up as a finished product, so keeping people aligned with expectations and context are key.

This experience will depend on the organization perspective and experience around design and user experience and product management as well. If the organization is focused on creating value and they are product centric, they are more likely to orient towards user needs. This is an opportunity for product people and UX people to truly collaborate.

I intend to keep this article concise but there’s several ways to get engaged with teams that are lightweight, low cost and yet incredibly effective.

Recommendations for working with teams

• Lean UX — Geoff Gothelf & Joch Seiden

• User Story Mapping — Jeff Patton

• Dual Track Development is not Duel Track — Jeff Patton

• Continuous Discovery Habits — Teresa Torres

• Sprint How to solve big problems and test new ideas in just five days — Jake Knapp

For future articles, I’m interested in sharing and exploring more User Experience related topics such as the value proposition of user experience, adding value to an organization, design systems, information architecture, experiment, and testing practices.

Recommendations for people getting into user experience and design

• The Design of Every day things — Don Norman

• Don’t Make Me Think Revisited — Steve Krug

• User Experience Strategy — Jamie Levy

• Jobs to Be Done — Tony Ulwick

• Change by Design— Tim Brown

• Good Services — Lou Downe

As many people will have noticed, there is a new owner in town for Twitter and that is having a radical effect on the organization, the remaining employees, and any remnants of psychological safety.

I’m also growing increasingly concerned about the long-lasting impact on other managers / leaders, using the new Twitter CEO as justification.

Organizations have several aspects where they do better and worse, so when a new owner is in town there are opportunities for that leader to assess the organization, its capabilities, its strengths / weaknesses, and the culture.

I will keep my opinions out of this article, but I do personally believe that treating people with respect, transparency and empathy are important values to me.

So how do you measure and assess an organization? There are many ways / approaches, some of them more meaningful / statistically valid than others but they tend to be quite interesting and food for thought either way.

Dave Snowden and Sense-Making

Dave Snowden is well known for his decision-making framework Cynefin around complexity. Another part of his work is Sense-Making and the software his organization offers ‘SenseMaker’. More information here.

The key message from Dave’s work (and the rest of the Cynefin co) is that culture cannot be built, it is emergent which means it cannot be ‘rolled’ out as part of a transformation. See OMG They want to change the culture

Dave’s approach to Sense Making takes a triangle as a way of making you decide where on the triangle you feel your answer fits over 6 different narrative captures.

As part of the capture, each point on the triangle has all positive qualities / words to it that for your brain into a system two thinking mode because having all positive qualities makes your brain itch and must slow down and think. This is a powerful way of capturing people’s feelings towards an organization, department, or team.

Dave challenges the notion of the Likert scale type questionnaires and surveys because people often fill them in without thinking and the fact that filling out such surveys often comes with a level of guilt or lack of safety how open and honest people feel comfortable being, let alone the fact that strongly agreeing or disagreeing tells you little.

Westrum’s Typology of Organizational Culture

When it comes to culture, there’s a model I find useful from Dr. Ron Westrum, known as his typology of organizational culture.

The three typologies below have an influence on the way information flows within organizations, in some ways can be thought of as Conway’s law for organizations.

Organizational culture is also measurable too, according to Dr. Westrum’s research / findings. Here’s the measures used (from 1–7) and the scores are averaged to give you a single score overall.

Westrum’s culture metrics (1 Strongly Disagree, 4 Neutral, 7 Strongly Agree)

1. On my team, information is actively sought.
2. Messengers are not punished when they deliver news of failures or other bad news.
3. On my team, responsibilities are shared.
4. On my team, cross-functional collaboration is encouraged and rewarded.
5. On my team, failure causes inquiry.
6. On my team, new ideas are welcomed.

This model has featured in many books from Continuous Delivery to Accelerate.

Psychological safety

We know from Google’s studies on performance and psychological safety that organizations / departments / teams who have greater safety perform better.

One of the key findings that really made an impact on me was”

Who is on a team matters less than how the team members interact, structure their work, and view their contributions. Google RE:Work blog

Google identified five key dynamics that set ‘successful’ teams apart at least at Google. (source)

1. Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?

2. Dependability: Can we count on each other to do high quality work on time?

3. Structure & clarity: Are goals, roles, and execution plans on our team clear?

4. Meaning of work: Are we working on something that is personally important for each of us?

5. Impact of work: Do we fundamentally believe that the work we’re doing matters?

Overfitting culture impacts diversity

An article on HBR around The NEW Analytics of Culture takes an interesting approach to culture and how to measure. One thing that really sticks out is thinking about culture from your own perspective vs the perspective of someone joining your organization and what that looks like if you are hiring people into your organization.

This raises an interesting question for how you hire, are you hiring to

• fit your existing culture (do people align to your teams' norms etc.)

• create adaptability (the ability to learn and adapt to culture over time)

• diversify your culture (increasing misfits to create broader creativity / innovation)

Chris Matts and Failureship

Chris has authored several articles on his blog about the dark twin of leadership (Failureship). It is a polarising view and no doubt bound to upset some people, knowing Chris that is intentionally by design. Chris talks about culture with two perspectives Risk Manged Culture and Risk Averse Culture as a way for talking about how people talk, work, and collaborate with each other.

This quote stuck with me:

Transparency is when you give someone the information they need, in the format they need so that they can make the decisions they need to make to fulfill their responsibilities. Chris Matts blog post

• Introducing Failureship

• Failure Cultures Reward failure

• aacennprrsTy and the failureship

• Step away from the office, and join the team!

• Failureship deliver things instead of value

Summary

If you are changing your organization's ways of working, driving out cultural / organizational change, you should think about the type of organization you want to create and not just the outcomes you are looking for. You cannot implement the type of culture you think you want; you need to let it emerge through the behaviors that are working and then through amplifying those.

When actions are taken by leadership, this sets a precedent for how others should follow. This can be a positive or negative thing depending on the actions taken.

Looking at people’s motivations is also an interesting lens to apply to what is motivating people and their own or systemic incentives. Especially when you consider what Dan Pink describes are the motivators for people: Autonomy, Mastery and Purpose.

If you aren’t keeping these things in mind when you are making changes, you may end up creating a toxic culture, learned helplessness or a high-performance organization.

The point I’m trying to make is that cultural change is complex and there is no obvious best practice to apply when it comes to changing culture and organizational behavior.

Experimenting / probing and getting feedback is critical to consider. Don’t be that person who takes suggestions from ‘experts’ and blindly applies them to your context without paying close attention. People do not simply take transformation and behavior change and follow / comply, people tend to need social proof from their peers rather than a shiny video, website, or presentation.

References

• https://itrevolution.com/articles/westrums-organizational-model-in-tech-orgs/

• https://cloud.google.com/architecture/devops/devops-culture-westrum-organizational-culture

• https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/

• https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/introduction/

• https://thecynefin.co/use_cases/sensemaker-powers-the-orgscan-a-powerful-way-to-see-organizational-culture/

• https://thecynefin.co/omg-they-want-to-change-the-culture/

• https://www.fca.org.uk/insight/measuring-corporate-culture-warning

These days, the world is making things a game, reading the most books, completing the most certifications etc… it is such an attractive offer that we often complete the content, but don’t embed the learnings.

This gamified modern world we live in often has us acting like human sized hamsters, running in wheels looking for the next dopamine hit.

This could be social media, notifications, likes etc, it could be the number of steps you’ve taken in your day, carioles consumer etc. or more recently the number of certificates / courses one has completed.

I’ve explored the waste associated with not embedding new information when you are learning (see my previous article).

We know from Alfie Kohn in his book ‘Punished by rewards’ that even with the best of intentions, things can go wrong when it comes to trying to reward people. Without applying a thoughtful approach, you risk doing more harm than good.

We know from Ivan Pavlov and classical conditioning that you can incentivize people to behave certain ways often without them knowing why (in the experiments case, a dog). This often borderlines on manipulation if people are not careful. This is often a technique used by game designers and app designers to create a sense of Dopamine rush when using their games / apps.

We know from Dan Pink, that human motivation comes from autonomy, master, and purpose. If you are rewarding or punishing someone through extrinsic rewards you run the risk of teaching people how to get more rewards, rather than finding motivation in the reward of completing the work itself. This means, that if the rewards stop, so too does the behavior.

From Jane McGonigal, games follow these four essential elements:

1. Goals

2. Rules (aka “constraints”)

3. A way to track progress

4. Opt-in participation

We also know that stressing people in a negative manner impacts your motivation and productivity. So, when you are having trouble with a challenging task and your boss is breathing down your neck to complete it you are likely to perform well and feel terrible at the same time.

If you are trying to build a learning organization, and enable teams to have more autonomy, these are crucial aspects you need to consider. This is even more pronounced when your organization's corporate incentives are not aligned to your cultural and behavioral incentives.

Here’s a scenario

• Your organization is establishing cross-functional teams, where the team has no boss, you are promoting the idea of teams being empowered.

• The end goal is for teams to self-manage and take accountability because that is how you create a culture of continuous improvement and empowerment.

• Your organization continues to use its legacy performance management process for ratings, promotions, pay raises and bonuses.

• This process is geared towards individual performance and leads to a culture of competition which means prioritizing oneself over others or the team.

If you want to reduce handovers and broaden skills amongst the team, how likely are the team if the incentives are not setup to encourage and support that behavior.

As organizations go through change in ways of working with the emphasis on business agility, the organization needs to be able to collaborate and align towards common goals and strategy. This becomes harder to do when your performance and incentives approach haven’t changed to match the desired behaviors and outcomes.

This is also where OKRs can cause a lot of danger, specifically where OKRs occur at every level of the organization, and they cascade down form up on high and cascade all the way to the individual.

Unless people in teams align to a common goal / direction, the chances of them changing their behavior and effectively collaborating are quite low.

Is it all bad news?

To be clear I don’t think gamification is bad, I just think that it can be dangerous if not carefully thought through.

Gamification in a company is example where if not thought through, runs a very real risk of people focusing more on the rewards than the outcomes themselves. In the worst cases it can lead to unhealthy competition between peers that can lead to unruly behavior just to get the reward.

e.g. having a leaderboard where points / ranking are based on completion of activities (such as complete a course, take a test) vs. an outcome (such as improving performance in a team, improving customer feedback)

We know in extreme cases where incentives have had material impact on companies who have tried to optimize for the wrong thing. (Refer to the Wells Fargo example below).

Summary

Some of this may come off as doom and gloom, it is more of a cautionary tale of ensuring that anyone in your company looking at incentives, performance management, gamification platforms and systems, having leaderboards for metrics etc really need to be careful and study the impacts carefully for unintended consequences.

Supporting resources

Books (big thankyou to Chris Matts for some of these)

• Drive by Dan Pink

• Punished by rewards by Alfie Kohn

• The Culture Game by Daniel Mezick

• Reality is broken by Jane McGonigal

• Gamify by Jane McGonigal

• Predictably Irrational: The Hidden Forces That Shape Our Decisions by Dan Ariely

Articles

• https://www.wired.com/story/power-and-pitfalls-gamification/

• https://en.wikipedia.org/wiki/Wells_Fargo_account_fraud_scandal

• https://www.shrm.org/resourcesandtools/hr-topics/technology/pages/gamification-at-work-can-go-very-wrong.aspx

In knowledge work, it is often tempting to oversimplify or tell someone else what to do and how to do it. This leaves little room for experimentation, learning and growth.

When it comes to learning new skills in knowledge work (see: Learning to learn or learning for a purpose?) people often think the following will help…

• a prescriptive set of best practices (in knowledge work, most of your work is either complex or complicated, and so best practices do not work)

• completing a short course / training and certification (we know from how the brain learns and remembers that you are unlikely to retain much of the information you learn in a 2-day course unless you take thoughtful notes, summarize, and put the learnings into your work / share with your colleagues etc.)

• a checklist to follow (checklists don’t work for complex or complicated work, however they can be used as a high-level procedure to check things off)

• a lengthy set of instructions (also known as a run book, these are often error prone and are best acting a set of requirements to automate a process instead)

• a combination of the above

There are other ineffective approaches I’ve likely forgotten; in this case I’m trying to be concise. One of the things that I see most often is a lack of context specific learning and practices. Specifically, I am referring to the domains from the Cynefin framework.

In order to decide how to respond, you need to know what context you are in, all work is not created equal and in knowledge work there is usually a group of people who are comfortable and used to working a certain way because that is how they have learned to do things either through formal education, courses or on the job. When someone’s way of working changes (either through their own or someone else's choosing), their whole can be tipped upside down. When this happens, how you respond and the guidance that you give can be potentially dangerous even if you have the best of intentions.

Anti-Patterns to look out for

• people asking for checklists (e.g. people need to know how to do their jobs and the checklists will help them remember how to do it.)

• people asking for overly specific examples of things when they are being introduced to a new concept (e.g. OKRs, ‘show me a very specific example that is just like my context’)

• people responding that you are being very theoretical, and they want more practical guidance (e.g. When you learn any new domain, you are bound to feel uncomfortable when something confronts your existing knowledge)

These types of changes can be hard for anyone, therefore people who understand change suggest things like ‘invite over inflict’ (Sooner Safer Happier) so that the individuals are the ones doing the exploration. The acceptance rate of anything new is far more palatable when people are motivated to learn.

In large companies, this can be a challenge in times of change. Organizations are often incentivized to get things done and start showing results. Organizations sometimes mistake change management with project / program management and therefore end up treating transformation like it is a project you deliver and then wind down at the end of a 2-year period. What people don’t often appreciate is once you go down the path of changing your ways of working, it never ends.

You do not simply learn Scrum and have them work in cross-functional teams and you are done. If only it was that easy!

One uncomfortable aspect is that we are in an ambiguous / uncertain world, the people teaching / sharing cannot answer all your questions. They can show you the door and you are going to have to walk through it. Changing ways of working is a journey, not a destination. The people teaching should be helping people how to learn, how to experiment and how to improve over time as a team.

Give people the tools and context (I do not mean JIRA), don’t give people the solutions. It is easy to tell people what to do, especially when you’ve seen things repeatedly, however, very rarely does that instruction stick and embed in a way that cultivates continuous learning and growth.

Was there a point?

As responsible practitioners and avid learners, take into consideration that there are no magic pills or silver bullets. All of this is challenging, and it requires effort, exploration, and learning. If you aren’t interested in learning new things, you are going to be in for a challenging ride. Remember that learning is key to getting better and you cannot learn just by reading books, work with your peers, get a mentor and get practicing. Then finally, pay it forward and share what you learn with others!

Learning is crucial if we want to improve, if we do not stop and learn, we will never get better. If you are doing knowledge work and you aren’t spending part of your day or week learning, practicing, and reflecting, then you are likely to be stagnating or regressing.

If your organization doesn’t tolerate failure and experimentation, and therefore learning — it is unlikely that you will have the support required for learning to happen in the workplace. Without a culture of learning and safety, people only learn if they are passionate about learning will do so out of work hours. If they are incentivized by a gamification* mechanism, they may be incentivized by the reward rather than the outcomes.

*Not all gamification is bad, please be careful when using it. There are many studies and real-world examples where things have gone bad.

As an avid learner, I’ve often struggled to connect what I watch, listen to, or read, applies to real work. Recently however, I’ve found that some things are starting to stick and embed. I suspect context, format, time and the people behind the content or course play a big part.

Recently I completed an incredible course by Modus Institue (Jim Benson and Tonianne DeMaria) called Lean Agile Visual Management (LAVM). It is a self-paced online learning where you watch videos, read plenty of articles and then apply your knowledge to a series of assessments / homework. Assessments are submitted in the open for others to comment on, not just the organizers. I had many great interactions with the learning community and ended up improving my assessments because of their feedback.

This is one of the few classes I’ve done (over about 9 months) that I have actively retained and put into practice daily.

In my experience, knowledge tends to go in one ear and out the other. Even as a child, my teachers would tell my parents at parent teacher meeting, that my reading comprehension was something to work on.

I would find myself going through the content but not really being able to properly embed that information for future retention.

I’m not sure that I have fully remediated that leaning challenge, but I have developed approaches that when followed tend to help.

1. Keep notes as you learn, write down important quotes etc. (I’ve yet to develop a solution for audiobooks). This one could be an article in its own on how to take great notes.

2. Collective learning is one way to learn together. Applied learning is where the magic happens. (Check out Situated Learning by Lave and Wenger)

3. Share what you learn with others — share with your team what you’ve learned the next day / week. Being able to crystallize what you have learned helps you embed that knowledge.

4. Read / watch / listen to many versions of the same topic, get diverse opinions, and see the points of view that others have. Even the contrarian / sceptical opinions. Another option is re-read the same thing multiple times — this could be a chapter / video etc but revisiting the same part multiple times in multiple environments can help you absorb.

5. Write a blog about the topic or create a talk / presentation on your learnings / observations and interact with others. If you aren’t comfortable doing this, then at least join a meetup on the topic of interest to hear what others think.

This is just a brief list but I’m sure with the amazing resources out there, you’ll find some more specific guidance that is scientifically backed.

There’s a full set of other learning resources and areas of focus that are about becoming experts (10,000 hours etc.), memory retention, super learning, speed reading etc. I think many of those are interesting to pick and delve into.

Practically having a reason to learn something helps, ideally a problem or a goal and even better an opportunity to apply the learning. Learning just to learn could land you in inadvertently gamifying the learning just for the sake of it… I have recently fallen victim of this in my annual Good Reads reading challenge.

I suspect if I’d read half the books within the same period and spent more effort in applying the learnings, I’d have retained far more. My approach now is to revisit the content and read it a second or third time once I have a specific problem that I think the content can help with.

Some other interesting learning models that Chris Matts shared with me a while back:

Conscious competence model (Wikipedia)

• Unconscious incompetence

• Conscious incompetence

• Conscious competence

• Unconscious competence

Kolb’s experiential learning cycle (Wikipedia), although Chris has a modified version

• Concrete learning (Kolb) / Observation (Matts)

• Reflective observation (Kolb) / Modelling (Matts)

• Abstract conceptualization (Kolb) / Experience (Matts)

• Active experimentation (Kolb) / Reflection (Matts)

How do you approach learning as an individual or a team?

What have you found most helpful as a technique / approach?

Resources for learning how to learn

• The executive learning trap — Chris Matts

• Learning to learn in a risk managed culture — Chris Matts

• Kolb’s learning model

• Conscious competence model

• Mindshift: Break Through Obstacles to Learning and Discover Your Hidden Potential — by Barbara Oakley

• Make It Stick: The Science of Successful Learning Hardcover — by Peter C. Brown, Henry L. Roediger, Mark A. Mcdaniel

• Situated Learning: Legitimate Peripheral Participation (Learning in Doing: Social, Cognitive and Computational Perspectives) — by Jean Lave, Etienne Wenger

• Thinking, Fast and Slow: Daniel Kahneman Paperback — by Daniel Kahneman

• Deep Work Rules for Focused Success in a Distracted World — by Cal Newport

• Atomic Habits: An easy & proven way to build good habits and break bad ones by James Clear

TL;DR — we know from Brooke’s law that the more people you add to your team, the more communication pathways there are and the greater impact it has on trust levels (see Dunbar’s work etc.)

Communication overhead increases as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing. — Wikipedia Brooke’s law

A cross-functional team should have the necessary skills needed for the regular delivery of customer value. If your teams end up having lots of individual contributors where work is handed over between the people in the team to each other, you are not likely to be able to increase flow. This is where bottlenecks arise and if you are not careful, teams end up starting too much work out of fear of not being sufficiently busy.

It is hard for organizations to let go of being ‘busy’ and instead being ready to swarm around work and pair together. This is often due to people having come from a background or education where optimizing for cost and resource utilization was seen as a better measure than have spare capacity that is used to create fast flow and respond to change.

One of the common behavior anti-patterns is where people want to hire more people / experts to do work, rather than learning how to prioritize and sequence work so that teams can learn to do it themselves. Often teams are super competent and just need a nudge and some capacity to pick up some new skills. The challenge is amplified by managers who aren’t willing for people to free up capacity to slow down and learn something new.

A lot of product development work is complex, we build things we’ve not built before. Learning by doing, is a way to quickly acquire those skills (task based, broader skills take longer time and more specific learning / deliberate practice).

This is where the notion of an enabling team from the book Team Topologies can be helpful. Rather than experts going into a situation and doing the work for the other team, (this applies to contractors as well), the enabling team can do in and help the team and effectively teach them to ‘fish’ rather than simply giving them a fish. People often say that they want ‘a fish’, when they mean they don’t have the capacity to learn something new or they aren’t confident to learn the new skills themselves.

Another practical solution (if someone else in the team has the necessary skills) is to pair and cross-skill and the pair work together and learn from each other. This not only increases trust and cross-skilling it allows the pair to build quality into their work since there’s two pairs of eyes looking at the work, rather than one. For example, if you have a tester, have them pair with a developer so they both learn and build quality in, they can and should take turns coding and writing tests. That same ‘tester’ should then work with other developers in the team, so they can share and learn across the team. That way you end up building a stronger mesh of skills within the team.

A typical composition of a cross-functional team is product, delivery, and engineering (gold star if you have design / UX).

If you hear someone say ‘Only person X can work on that’ then you know this is an opportunity to learn. Warning - apply pragmatism, clearly not all skills and capabilities can be easily / quickly acquired or transferred. A lawyer cannot easily become a surgeon and vice versa. An engineer and a tester may be more likely to learn from each other. Another perspective is that the lawyer and surgeon may not require the full set of skills to do the work, they just need enough to get some more repetitive work done. So, both roles would still be required but one person could take on some of the other person's work if needed. That wasn’t a great analogy, hopefully you got the point.

Learning from your own team and often outside of your team too (think team of teams etc.) is a brilliant opportunity to pair up on work and have the less knowledgeable person on a given task take the lead and the more experienced person work with them to pair up.

This way you are building up knowledge with support and not falling for the ‘bus problem’ (what happens if person X gets hit by a bus). You also have a safe pair of hands to guide you, so you aren’t on your own.

Teams get stuck on work waiting for other teams all the time. That leads to teams and individuals within a team to start new work before they finish what is already in progress.

Stop starting, start finishing!

Outside of your own team, you might be relying on a skill set from another team — which can be for many reasons, sometimes skills, other times due to specialization or access (e.g. the Database Administrators). This is another opportunity for your team to find the team they are waiting on and help them with the dependency, dependencies come in many shapes and sizes as I’ve written about before. That database administration team may not have the capacity to invest and automate their services so if you go and help them, you may also be allowing them to get additional capacity to further automate their offerings. This is how dependencies can be resolved and how collaboration happens instead of a culture of blame.

You might depend on another team for many reasons: knowledge, tasks, or resources — analyzing your blockers and known dependencies will allow you to plan for them, ensure the other teams are ready for you when you need them and can be resolved through collaboration, simplification, skill acquisition or automation.

We release quarterly because it takes too much time and effort to do it faster. I’m not sure who said it first ‘if it hurts, do it more often’, I’ve heard Martin Fowler and many others say the same. (it also features in the book Continuous Delivery by Dave Farley and Jez Humble)

This is often a symptom of large batch sizes and lack of quality being built into the process, so it is all pushed to the right at the end of the planned release. This is when re-work occurs, bugs crop up and quite often the developers have moved onto new code, which means they’ve forgotten the context of the code.

Reducing your batch size and releasing code more frequently is how you reduce and impact of your release.

You don’t need to be a magical DevOps unicorn to do this, making minor changes and building quality as you go, will allow you to improve your coverage and quality as you go.

“I didn’t have time to write you a short letter, so I wrote you a long one.”

— Mark Twain

Before you start complaining that the teams now have too many things to learn, you are in fact correct. This is where Team Topologies helps yet again, with a clear focus of empathy to the teams and leveraging the notion of cognitive load. Teams should have the necessary skills that they need to deliver value, if there’s a lot of skills required to get something out the door and into the customers hands, that is potentially an opportunity to look at a platform-based approach where you can take complicated activities away from the individual teams and solve such problems for a large group of teams instead. I frequently use Cloud provides are the example.

I don’t call up AWS / Google Cloud / MS Azure if I need a server / database etc. I trigger an API based on the documentation and I am up and running in no time (excluding your companies many layers of bureaucracy of course). Condensed version: don’t create platforms that require even more coordination to use them. Platforms should solve common problems and do so far better than an individual team could.

Additional resources

Skills Liquidity — Chris Matts

• Introducing staff liquidity 1

• Introducing staff liquidity 2

Situated Learning

• Situated Learning: Legitimate Peripheral Participation — Etienne Wenger, Jean Lave

Troy Magennis (thanks to Nick Brown for the recommendation)

• Capability matric (template)

• Skillset planning (template)

• Focused objective site — courses

Maturity mapping

• Maturity mapping — Marc Burgauer, Chris McDermott

Emily Webber

• Capability Profile Mapping

• Mapping skills and capabilities to communities of practice

Mapping Skills and Capability
I have loved QCon and I've learned so much about what is hot in the industry, what's coming up next and what are people…www.infoq.com

Over the past year or so I’ve had the privilege of building a large team of ways of working practitioners. This has been in the face of a challenging economic environment and a competitive industry for amazing people.

The mission

• build the team within 9 months

• hire a mix of people from both outside and inside the company

• end up with an amazing team culture where psychological safety is there from day one

• hire the team over multiple time zones / countries

• don’t hire too quickly, or too slowly

• don’t screw it up

We were confident it could be achieved, none of us had done anything on this scale or period before but we knew if we all worked together, we could find amazing people. Which meant the challenge was challenging, not impossible.

What approach did we take?

We applied a real options approach to what we were doing, because the one thing we knew up front was that we didn’t want to over commit on day one.

For those not familiar with Real Options (popularized by Chris Matts and Olav Massen)

• Options have value

• Options expire

• Never commit early unless you know why

We prioritized finding awesome people as the priority over filling specific roles. We focused on building the environment for most of the teams to emerge and end up self-managing. That way all that was required was the occasional nudge. I’m a believer in the notion of ‘make the commitment at the last responsible moment’ (Preston Smith).

We also leveraged our networks and online presence to attract a few candidates as well. Whilst this didn’t result in a lot of hires, it did allow us to get a few people that really would add to the team’s collective IQ.

How did we manage?

‘Never commit early unless you know why’ — One of the challenges with keeping our options open was really a simple case of dealing with having too many people reporting to me directly until we had all the necessary structure in place (team leads etc.). So rather than wait until all forty people arrived, we created a scaffolding approach whereby we kept enough flexibility as needed until we had to decide. That way we had as many people in the team as possible so that we could then build up the structure with as much information and confidence as possible.

‘Options have value’ — Hiring people into certain roles was going to be risky when we had not done this before and at this scale so we thought hiring good people and then letting the rest emerge would be a more pragmatic option if we were transparent and fair with people.

In some cases, we didn’t always get the balance right. We knew it would be risky, hiring so many people in such a short amount of time. Instead, we swarmed around the joiners and made sure they had buddies and a support network in place, so they didn’t feel isolated. I am particularly proud of the state of the team as of today and look forward to closing out the last couple of roles before the end of the year.

What did we learn?

‘Options expire’ — you can always find people that are amazing, but at what cost to the rest of the team. Whilst it is tempting to go chasing every option (your ‘white whale’), you do so at the risk of diminishing returns and you can only have so many lead singers in a band so we wanted to prioritize team players over dragon slayers.

We took a pragmatic approach, we hired for team fit and aptitude over qualifications or expertise. We really didn’t want a team of unicorns all with their own personal favorite flavor of ice cream (or whatever unicorns eat); we wanted a team who could work together and do incredible things as a team.

Before you call me a collectivist, I do appreciate individuality and what each person brings to the table, it is just not at the expense of the team dynamic and collective team IQ. There is no perfect balance but involving as many people in the process of hiring as you pragmatically can is an effective way to build consensus and collective ownership of the process. That allowed us to continue to tweak our heuristics and approach over the year and get better at finding our goldilocks zone. Would this person ‘play well with others’ or would they be a ‘lone ranger’.

The number 1 thing we wanted to see was if people are actively engaged in continuous learning and were the type of people who kept strong views but loosely held when presented with new information. The world changes so quickly, no one can know everything and quite often what people do know is not always up to date or accurate, so we wanted to be able to challenge each other and learn as a group. No top-down imposition, just best approach and results wins and then share with your team to build sustainability.

How does this help?

I am sharing my experience with the hope of showing you what worked and what didn’t. The one thing I cannot stress highly enough is that you cannot and should not rely on a recruiter to do the heavy lifting. They are a partner, not a service provider to you. Work with them, build, teach and collaborate with them in a high bandwidth sense.

Having regular touch points and if you are hiring a lot of roles, then having a visual board is key to having everyone on the same page. A simple Kanban board can work well for everyone as each role goes through each step in the value stream.

Finally, don’t think that your work is done after someone has signed the contract, you have their on-boarding and then next steps to contend with. Give people as soft a landing as you can, I cannot tell you how many times I’ve seen people join a company and must hit the ground running and are then plagued with admin work and getting up to speed with the organizations structure, terminology, and ways of working.

Lastly get all your new joiners to challenge your team's on-boarding guide, mission, thinking and approach. e.g. review the team norms, comms agreement, ways of working and visualization etc.

Getting an outside in view is super helpful to validating your approach and making sure you are not getting complacent and remember to keep your options open!

Reading Recommendations

• The Team that Managed Itself: A Story of Leadership by Christina Wodtke

• The Five Dysfunctions of a Team: A Leadership Fable by Patrick M. Lencioni

• The agile Manager: New Ways of Managing by Rob England, Cherry Vu

• Open Management: Better work for a better world by Rob England, Cherry Vu

• S&T Happens: Surviving and Thriving in a VUCA World by Rob England, Cherry Vu

• The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition by Steven J. Spear

By busy, I mean maximizing ‘resource efficiency’ over ‘flow efficiency’— either through overloading teams or people. (see: The efficiency paradox).

I’ve been exploring the nature of teams, cross-functional and whatever the opposite is called (functional?) and the relationship between them (see: Should every team be cross-functional).

If your teams interact with other teams / individuals for support / help, they may have to reach out to those teams on an ad-hoc basis which leads to unpredictable demand and creates a potential tension for when people have enough time to interact.

This creates additional communication overhead not only between the cross-functional team and the individual group, but between the groups themselves e.g. the architecture team and the security team. It also makes it difficult for these other teams to plan their own capacity when demand is unpredictable, this either leads to lengthy delays or people working overtime to help people, either of which are not great for the individuals, the teams, or the organization.

Sooner Safer Happier talks about Safety teams which is a more advanced version of the topic. Effectively it involves creating another type of cross-functional team of experts from various teams / departments who serve a group of teams with related concerns (e.g. a team of teams or beyond).

This allows for trust to increase between the teams, as the relationship will be one of partnership and professionalism rather than chaotic 11th hour escalations for help.

Teams may not need help from a lawyer on a regular basis but may have to interact with an architect more frequently. Whilst you may not interact with every single member of your safety team every week or month, it is important that everyone has transparency of the work (visualized) so that everyone can see what the team are working on and when people should engage (a roadmap, a Kanban board, an Obeya wall etc.).

The implication is that your backlog needs to be written so that others can read it, rather than in cryptic language only your team understands.

If you are in a cross-functional team and improving your ways of working, you will very quickly realize that other areas or experts you need are likely to not be able to work at the same ‘pace’ or cadence of the team. This is no fault of their own, it is simply a way of working and crucially interacting.

Rather than having a huge team with ‘one of everything’, you setup a way to interact with the individuals or safety team on a regular cadence to interact with them so that it is predictable, transparent, and enabling a shared understanding across the people involved.

In some organizations you can imagine each department having their own risk specialist, one for technology and one for operational risk. I’m sure they have some overlap of concerns and need to work together occasionally.

If you bring the distinct groups together and create a shared understanding, you can reduce the need for separate / offline conversations on the same topic.

You can have core team members that really are long lived, and a group of individuals you interact with semi-frequently or infrequently and there is also in between which I might explore in a subsequent article. All of these are valid, what is more important is maintaining the relationships and building a sense of trust so that shared understanding of the domain can be achieved, and you don't end up needing those experts at the 11th hour.

People tend to get annoyed when they are required on a random basis, and it makes collaborations strenuous at best. I’m sure you’ve experienced a team wanting to release software, only to realize they need their architecture to review and sign off before they can go live. The most expensive time to change something (architecturally) is after it has been built and the team are committed to what they are trying to release.

If you had brought in your architect at the beginning, then everyone could have been on the same page and agreed to what was needed at the beginning to then set a glide path for the team.

There are other skills which will vary depending on the nature of the team, the product they work on e.g. a Designer may be needed if you are involved in a user facing product they may act as a long-lived team member on a temporary basis (please hire more designers — see John Cutlers video below).

In summary

If you work with supporting / enabling teams on a semi-regular basis, I suggest bringing them into your planning or review / demo events more often. They don’t have to attend all such events but if they are brought in to support and given guidance on a more predictable basis you are far more likely to have a shared understanding. That shared understanding allows those people in the safety teams to engage with you more effectively and with other teams too.

If they can then see the work, you are doing and how that relates to their concerns e.g. risk story etc. Then you can start to introduce others into better ways of working that are compatible with yours. You never know you may end up finding some allies and form better relationships as a result.

Focusing on efficiency makes you less efficient — Niklas Modig

What do you see as the most common misunderstandings of efficiency and utilization when it comes to knowledge work?

I’m reading a delightful book (This is lean — Niklas Modig and Par Ahlstrom) and there’s a corresponding TED talk to go with it.

Only making teams independently more efficient (higher utilization) makes the overall customer experience worse, not better. Solving problems from a customer perspective allows organizations to focus on flow efficiency rather than resource efficiency. Whilst related, it is different to local vs global optimization. They often interact but there’s many other ways of optimizing outside of efficiency.

In all cases it should never be one over the other but both, however starting with flow efficiency will lead you to better outcomes than resource because it is focused on the customer. Niklas Modig refers to this as changing the camera's perspective from the person doing the work to the customer.

Visualizing work across in a value stream or a customer journey is crucial to having an adult conversation with teams and leaders if you want to improve ‘the system’. Just don’t fool yourself into thinking one and done, there’s always hidden work and what Dave Snowden calls Dark Constraints that you can’t see but impact you anyway.

Visualizing bottlenecks and calculating the flow efficiency can be a conversation starter, beware that many of the tools out there will give you misleading data. Digital tooling doesn’t really help you differentiate between active work in a queue and the active work that you are currently doing. (Thanks to Nick Brown for that insight!)

Flow efficiency calculation — percentage of amount of active work / amount of total elapsed time the customer is waiting.

Resource efficiency — focusing on the individuals or functions independently, how do you maximize utilization. e.g. Four teams passing work between them to deliver something of value.

Flow efficiency — focusing on efficiency from the perspective of a customer, how long does the customer have to wait and how many steps are involved to get value out of the experience. e.g. a cross-functional team with all the necessary skills to deliver something of value.

How can efficiency be bad?

Lately I’ve been curious about how some people think of efficiency. They act like more is better. That has never really sat well with me, it doesn’t feel very efficient to make more of anything than you need.

“It’s possible to make an organization more efficient without making it better. That’s what happens when you drive out slack. It’s also possible to make an organization a little less efficient and improve it enormously. In order to do that, you need to reintroduce enough slack to allow the organization to breathe, to reinvent itself, and to make necessary change. “

— Tom DeMarco Getting Past Burnout, Busywork, and the Myth of Total Efficiency

Toyota and other companies had that realization, long before I started to think about the topic. Ideas like just in time, building quality into work, pull-based work systems, and thinking about value and waste from a customer perspective are far more helpful frames in thinking about the ‘efficiency problem’.

Given the state of our tiny blue planet, creating more of anything as a flex, just doesn’t sit well with me. This is even pronounced when you learn about things like intentional obsolescence which prevents your products from being repaired and maintained (e.g. instead of replacing the battery in your phone when it dies, the manufacturer makes you buy a new phone).

This type of understanding still seems to perpetuate large companies who are stuck in the industrial era thinking cost savings, resource utilization over customer value and flow efficiency. The difference between Henry Ford having all cars produced quickly in black but full of defects vs. Toyota being able to produce cars in any color with fewer quality defects.

It is easy to see how organizations can think that producing more of a thing benefits from increased (resource) efficiency. Being efficient often impacts your ability to respond and adapt to market conditions (a similar goal to agility).

I hear people say ‘that is fine for traditional goods and services’ — what about products that are partially or fully digital? Similar work challenges exist, but manifest in different ways. If you see work piling up in a queue, it is likely that you have identified a bottleneck and they are someone else's dependency. Check out the Theory of Constraints for more on this topic.

From the perspective of the team’s manager — that large queue may mean that they are ‘busy’ with high utilization. From the perspective of the teams or customers depending on them, they can be seen as causing huge delays and incredibly inefficient. That leads to failure demand — people generating more work to find out the status of the work and causing more context switching.

There are multiple ways to approach this, typically you can throw more people at the problem or be clever and suggest automation, so that the services provided by the team can be consumed as self-service, but this is hard and requires capacity to do so. When will people get that capacity if they are always fully utilized? This being stuck in a hole and digging your way out…

Is it good to be busy all the time?

That depends on what you mean by good

• If you care about having people as busy as possible, yes.

• If you care about something from a customer perspective, no.

You cannot respond to unplanned customer demand, if your teams are fully utilized. You need to have capacity for unplanned work (known as slack), if you want to be able to respond to change. Without spare capacity, where and when is that work going to happen? This situation makes teams feel helpless, disempowered, and likely to burn out.

Having slack for un-planned work is critical if you want to improve and have enough time to learn and adapt. When you have the next Log4J critical vulnerability occur, when are people going to be able to respond to that? If your only choice is to have people work over time or on weekends then we have a problem!

Perhaps a better analogy is spending money on your credit card and maxing it out each month. What happens when an emergency happens, and you need your credit card for that? That is an expensive experience, and the banks know that.

When you have separate teams for various tasks e.g. analysis, development, and testing / quality assurance. You end up with teams optimizing for their own needs rather than the customer. Every team is preoccupied with their own work, metrics, and priorities so they aren’t ready and waiting to take the baton when another team is ready to hand over work. This is the reason cross-functional team's work.

Taking things one step further, when individuals in the team have a good overlap of skills and they work together you get the best results. That way you aren’t handing over work, you are collaborating on work together. This is how you build quality into what you do and eliminate handovers. Team members get to learn from each other and gain new skills. I recommend checking out Skills Liquidity from Chris Matts.

Conflating efficiency with effectiveness

As we move away from focusing on resource efficiency and ween ourselves off the drug of ‘being busy is a good thing’. It would be wrong to talk about efficiency and not talk about productivity and effectiveness.

This can occur at all levels of work too — individual, teams, systems, and organizations.

If you are emphasising being busy over being effective (getting the right work done) you are likely to be taxing your people with context switching, cognitive load and the feeling that they are just cogs in a wheel. In knowledge work, you cannot be effective if you don’t have time to think. The highest performing organizations are often the calmest and not busy. People need time to learn, think and do deep work. Constant meetings, fire drills and instant messages are all incredibly disruptive and prevent people from doing great work.

This is often why you see people super early or late in the office. Not because they are busy working with other people. but because that is the only time they get to do deep / uninterrupted work.

As you move from the individual to the team, to the teams of teams, think about how frequently the other teams are being interrupted by you and others and how inefficient they will be because of context switching. So that means plan and collaborate your interactions, agree to scheduled time for collaboration and interaction (meetings where you do work rather than talk about status) and visualize the work so that everyone knows who is doing what and how work contributes to a larger goal. If you do this, it allows people to see and appreciate the bigger picture.

Visualizing a congested system of work is a powerful way to have a conversation with leadership. They should be helping with impediments and blockers, enabling the elevation of bottlenecks, and avoiding the need to escalate. If your leadership are flooding your system of work, they need to see the impact of that. How many pieces of work are the teams working on and how would they like a team to finish a given piece of work before they start another.

I find escalation to be the anti-pattern for collaboration, yet I see it happening all too frequently. How often does the xyz team get blamed for preventing a team from getting work done, whilst at the same time the team has had that piece of work in progress for months. It is only now that someone is asking about it that the blame game starts happening.

This is a bit like running to the teacher on the playground and telling them someone else won’t let you play with them. Then, having the teacher make the other person involve you in their activity.

Collaboration over escalation!

Internal competition between teams is incredibly unproductive if you are trying to work together on a common goal for the organization!

Recommended resources

Chris Matts — the IT Risk Manager

• Introducing Staff Liquidity (1 of n)

• Introducing Staff Liquidity (2 of n)

• Stress testing skills liquidity

Johanna Rothman (checkout the whole blog series)

• Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System

Books

• This is Lean: Resolving the Efficiency Paradox by Niklas Modig, Par Ahlstrom

• Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco

• The Mythical Man-Month by Fred Brooks

• Thinking, Fast and Slow by Daniel Kahneman

• The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt

• Deep Work by Cal Newport

I admit the title is a little clickbaity — I was reminiscing over an ad from 15 or so years ago, that reminded be of unblocking. Organizations looking for fast flow of value, can’t achieve flow if they are blocked.

Imagine having Terry Tate in your team or department to help you unblock work! (without the phsyical violence of course)

Back to regular programming…

One of the amazing things about the internet is when your passions cross-over with others. This happened to me recently as part of my exploration of teams, interactions, dependencies, and blockers.

I was thinking and starting to collect my thoughts for this article when I noticed that Nick Brown’s recent talk from Agile on the Beach was available to watch on the topic of blockers. I highly recommend you watch the video as Nick does a fantastic job of defining blockers, metrics, and observations.

“Dependencies are blockers waiting to happen “— Nick Brown

A few terms that are useful to define (do you agree with the definitions)

• Impediment: something that slows you down, hinders progress (e.g. a sick team member)

• Obstacle: something that gets in your way that requires you to navigate to overcome (e.g. a skeptical stakeholder)

• Dependency: a situation that occurs when the progress of one action relies upon the timely output of a previous action or the presence of a specific thing. Taken from Diane Strode’s paper “A Taxonomy of Dependencies in Agile Software Development” (e.g. Team A requires Team B to setup a new Database for Team A)

• Blockers: something that stops you from getting your work done (e.g. your test environment is down)

In my recent article (Individuals and interactions over processes and tools) I started to walk through several types of dependencies that exist, I didn’t get to explore how and when dependencies turn into blockers and what to do about them.

From a practitioner perspective, how do you nudge teams and leaders to solve not only the temporal nature of a blocker, but the underlying cause.

I previously mentioned Diane Strode and Troy Magennis in my last article. What I didn’t explore was the ability for an individual, team, department, or organization to resolve the blocker.

I went down the rabbit hole on this topic before I started this article. There’s a few ways to think about blockers (building on Diane and Troy’s contributions with a nod to Liz Keogh’s brilliant article on estimating complexity).

• the work — does the team know how to do the work, does the team depend on other teams or resources, can the work be started or finished until other work is done first

• reliance on individuals / experts — does the work require support from experts in other functions e.g. a Lawyer, a Compliance expert, Security expert etc. (if you don’t bring these people into the conversation early, they will become a blocker as they are not working on your team in most cases and they will likely be helping many other teams)

• the team's capability — does the team have the necessary capacity and skills to complete the work

• the environment / industry you work in, your architecture, governance, bureaucracy, regulations, laws, tariffs, etc…

• world events / threats like climate change, financial crisis, natural disasters, wars, pandemics etc. are these blockers to the team or just external impediments?

Estimating complexity

From Liz Keogh’s article — estimating complexity — Liz’ 5 point scale on levels of ignorance / certainty of the work (apply this to blockers as well — how would you approach solving those blockers based on the below scale).

5. Nobody in the world has ever done this before.
4. Someone in the world did this, but not in our organization (and probably at a competitor).
3. Someone in our company has done this, or we have access to expertise.
2. Someone in our team knows how to do this.
1. We all know how to do this.

How do you manage blockers?

From Nick’s video, he offers a great approach at a team level and even across teams but hasn’t gotten to the bottom of addressing systemic / organization blockers. I expect this is something Nick is thinking through and will cover in a subsequent talk. I imagine this area could be explored in parallel to things like having flight levels in place with different WIP limits at each level, do you consider blocker WIP limits too.

How bad do things have to get, in a team, department, or organization before they become a priority to solve. If you want fast flow of work, you must unblock the systems of work.

“Impediments are not in the path, impediments are the path” — Jon Smart

The job of leadership is to help unblock, if you are in an organization where leadership is not actively looking to help and unblock work, they are likely to be flooding your system of work instead which will create more blockers and reduce throughput!

I’ve paraphrased Nick’s slide and added a few observations. Nick suggests checking out the new Kanban Pocket Guide.

1. how long does something need to be blocked to be considered being blocked e.g. hours / days etc.

2. how do you identify blocked items in your tooling (approach will vary by tool but it could be labels, attributes, swim-lanes)

3. how do you identify the blocker is (as opposed to just not being able to complete your own work)

4. how do you think about your blocked items in the context of a WIP limit

5. what are the conditions for closing a work item as being blocked for so long that you can’t see a resolution

6. how does your organization deal with blockers, do you have a mechanism in place to escalate blockers if they are impacting a teams ability to deliver

7. how are you creating transparency on blockers across the organization and what can you visualize (data wise) for people to act on them

8. what are the sorts of metrics that will get people’s attention to act on the blockers e.g. number of blocked items per team, number of teams blocked by the same blocker, average age of blocked items, lead time for items that have blockers vs those that don’t (thanks to my friends at Nationwide on that one) etc.

9. after a blocker is removed, and work can be completed, how are your teams reflecting or doing a PDSA on how the blocker came about, is it something that could happen again in the future, how could it be avoided and what would it take to fully eliminate the blocker in the future.

10. can you cluster the blockers into common cause for broader resolution, this can be useful when looking at larger bottlenecks (Troy Magennis also mentioned dependency clustering in his talks too).

That’s enough of a list for now.

Nick also introduced the notion of a Definition of Blocked (DoB), which I really like, equivalent to a Definition of Ready / Done. Really a small policy for the team to provide decisions based on context of a blocker. A subtle way to reduce cognitive load and help if someone else joins the team. This seems like a great place to start experimenting.

Evaluating options based on needs

Next we can explore common types of blockers and what options might help address them. Some free advice, there is no best practice in knowledge work. Practices are context sensitive and, in many cases, will vary depending on your teams knowledge, clarity of the teams goals and many other factors.

Anyone selling you a silver bullet, you should apply some healthy scepticism towards.

In a previous article I explored the Individuals part of the title (Should every team be cross-functional?).

I recently stumbled upon (thanks to Charles Betz, Joshua James and Troy Magennis) a taxonomy of dependencies which is a useful frame to think with. It is common for people to think about dependencies as relating only to the work another team has to do. Depending on another team is not the only type of dependency and if you are looking to improve the flow of work you might want to consider some other type and how to handle them.

People often track work dependencies, which is a start, that doesn’t actually eliminate or improve them. Dependencies inhibit flow and since there’s more than one type of dependency to consider, you should really be putting a lot of focus on your dependencies and working as a team to manage and solve them.

Diane Strode — Taxonomy of Agile Software Project Dependencies (2012)

Diane Strode authored a seminal paper on dependency taxonomy in 2012 and then updated it in 2015 (although I’m not able to find an updated copy). A list of Diane’s other papers can be found on her Google research page https://sites.google.com/site/dianestrodepublic/

Troy Magennis — Managing Dependencies

Troy Magennis adds a fourth type of dependency which I think is also quite useful. That is ‘product dependency’ — where you may need to wait to release your product or an update to your product so that other component pieces are also available at the same time.

Troy’s example is a team waiting for Apple to release an updated version of an operating system version before a team’s app can be released / published in the app store. That is out of the team’s control but is critical to understanding and managing.

Troy also talks about blocker clustering which lets you assess what can be solved by the team doing the work or external factors.

Once this clustering is done, the number of days each cluster contributed to flow being blocked. Next, start by breaking down and analysing the problem — 1 understanding the problem (using the 5 whys), 2 finding solutions to the problem.

Once you’ve got solutions in mind, your team should experiment to see if they can reduce or eliminate the blockers. Be aware that if you fix one dependency or blocker, it is likely that another one, may pop up in its place.

The blockers can then be tabulated in a 3x3 matrix: items that are easy — hard to solve vs. the time items have been blocked e.g. high — low. You then focus on the easiest to solve with the highest time blocked and then go from there.

One point really stood out, that is worth repeating!

If it costs more to fix a blocker than it costs in the delay, then it SHOULD NOT be fixed — Troy Magennis

Team topologies — Team APIs

Another source of inspiration is from Team Topologies book and their recent workbook (Remote Team Interactions Workbook — by Matthew Skelton and Manuel Pais) talks about the notion of Team APIs as a way of visualizing and managing dependencies and interactions as interfaces.

Remote-first Team Interactions with Team Topologies - Team Topologies
Remote-first work is the "new normal" for companies around the world. There is no shortage of advice on how individual…teamtopologies.com

They have some great resources on the above page, the Team API template and Team Dependencies Tracking templates, however I suggest becoming familiar with it all rather than cherry picking.

• Team-API-template

• Team-Dependencies-Tracking

Summary

If you are writing or slicing stories (described in Be a samurai, not a lumberjack), understanding and managing the dependencies are as important as the stories themselves from a flow perspective. If you aren’t managing each type of dependency (see above) in an active way, you are allowing blockers to impede flow, which means you won’t be able to improve your time to market.

For learning and knowledge dependencies, you should invest and prioritize time in your teams, so that you aren’t just building a culture of learning (check out Getting better at getting better) - instead actually creating a culture of continuous improvement that can be linked to the blockers your team is facing. This is a more compelling reason for people, giving that learning and improvement a driver. Is that new certificate / online course really going to help the team, or just puff up someone’s LinkedIn profile.

So visualize items on your backlog for continuous improvement that unblock other items. Highlighting an item with a red flag is a first step but not enough. Most modern tools are terrible at creating the necessary data behind being able to effectively track the types of dependencies so you might have to resort to simpler systems until you find an approach that works.

Dependencies must be managed and eventually resolved through several different techniques. More time should be spent on this aspect of creating flow!

What do you think, and how do you manage the types of dependencies? I know SAFe uses red string to track dependencies across teams, which is really only one type, I’m not sure how much further it goes. I’d love to see what others are doing!

The below reminds me of a murder mystery, rather than anything else…

How it seems…

I had the pleasure of talking to Charles Betz on some topics and it got me thinking about the nature of teams, topology, and composition. (Note: this extends beyond IT or product teams, really any team in a company)

One such topic was the notion of x-in-a-box teams, where the x represents a profession, a team can be composed of.

Charles talked about having the alignment of x around Marty Cagan’s 4 Big Risk types that come from Marty’s book INSPIRED (2nd edition). See Marty’s blog post: https://www.svpg.com/four-big-risks/

Extract of Marty’s 4 Big Risks and an overlay mapping of professions.

1. value risk → the product manager

2. usability risk → the UX / CX designer

3. feasibility risk → the engineers and architects

4. business viability risk → various perspectives (marketing / sales / compliance / legal etc.)

I believe the original notion of the x in a box came from Marty Cagan when he was talking about 2 in a box PM in the context of a Product Manager and a Product Owner as an anti-pattern and cause of a lot of disfunction. So the ‘x in a box’ concept is different to Marty’s definition.

So, taking different perspectives and professions for your team will allow you to focus on what matters. Depending on how close you are to your customer / user, you may need more supporting / enabling help (what Sooner Safer Happier call — Safety teams) for your products to land viably in a market and within organizational tolerance.

In other cases, your teams may be working on internal products, platforms, they may be acting to enable others, or they may provide a service themselves such as a support or operations (e.g. payment processing, customer on-boarding etc.)

These teams can all benefit from product centricity as well, one important thing to remember is that even if you are going down the product centricity route, it doesn’t mean that every team needs its own product. In fact, having teams align to support a product or better yet a value stream will allow for many teams either cross-functional or functional to focus on the product and the customer. When teams do this, they focus on what matters rather than prioritize work that benefits their own team locally (e.g. cost efficiency) over effectiveness of an overall product or value stream.

Another consideration is the notion of long-lived teams, these are important for team psychology and trust boundaries. However, in many cases a cross-functional product team will not need to always have all the required skills e.g. legal, compliance, cyber security etc. So instead having a core team of long-lived members that are full time (not in multiple teams) is important, and then formalizing a relationship with the enabling, supporting or operational teams / individuals is how you keep them in the loop rather than at the end of your delivery approach.

Involve these people in discovery, planning, prioritization, testing and even reviews / demos. The more they understand the product or value stream, the more likely they are to contribute to it rather than treat you like someone who needs to go through 7 levels of stage gates.

I am a major fan of the book Team Topologies; however, it doesn’t go far / wide enough for the whole organization in its guidance and so you will need to tweak it to your needs if you want to apply it to your finance controlling team, payments processing team, customer success teams etc.

I’d urge you to experiment and see what works, equally don’t fall into the trap of a one size fits all approach to every single team or turning everything every team does into a product.

Even if you end up with a product team (stream aligned team in Team Topologies speak) — realize that all teams go on a journey and it takes take, they all need to grow together and not all product teams truly need to end up where the product manger achieves true ‘product mini-CEO’ status.

Resources

• Team Topologies by Matthew Skelton and Manuel Pais

• Extra-dependent Teams by David Kesby (a pre-cursor to the concept of a guild)

• Managing Digital by Charles Betz (coordination effectiveness section)

• Journey to Product teams — John Cutler

• Product Ops overview — Marty Cagan

In my previous article I left a few stones unturned, that deserve exploration.

Wardley Maps / Mapping by Simon Wardley

Wardley mapping is one of my favorite practices to use as an architect, turned agile Padawan. What problem does Wardley mapping try and solve, its visualization of value over an evolutionary axis to facilitate a discussion towards shared understanding. I’m sure many of you have heard ‘all models are wrong; some models are useful’. Wardley mapping supports the useful model discussions.

Simon is a gem of a human being and freely shares his work online under creative commons (also available in other formats). He’s given many talks on mapping as well as other topics and I can highly recommend the Wardley mapping community.

Why would you use Wardley mapping? I’ve personally found it useful for discussing options, decisions and strategy around products and their underlying components. As a former domain architect, one of the scenarios I found myself in frequently was people wanting to either build something from scratch or buy something they had previously used at a prior organization or from market analysis (the market analysis isn't the issue, it is how it is often used).

Here’s a simple example from Simon’s online book.

There’s a lot more to Wardley mapping, including purpose, landscape, climate, doctrine, and leadership (nicely aligned to the OODA loop). There’s a lot more to it. I highly recommend exploring the work further but to get you initially interested — I suggest starting with one of Simon’s many talks.

I also recommend Ben Mosier’s amazing resources Learn Wardley Mapping.

Real Options by Chris Matts and Olav Maassen

I had the pleasure of sitting next to Chris Matts for a couple of years when we worked at the same company, he mentored me in the ways of lean, agile and so much more.

What is Real Options? Real Options has its roots in Financial Option Theory which is scary for most people, the point I’m trying to make is that there’s serious rigour behind it. Real Options applies Financials Options to the Real world when it comes to making decisions.

You can read up on the details further on Chris’ blog (theITRiskManager).

Real Options says:

• Options have value

• Options expire

• Never commit early unless you know why *

* The latter nicely links with Preston Smith’s ‘Make the commitment at the last responsible moment’.

There is a lot more to the practice than the above 3 items and there’s a nice write up on InfoQ I recommend reading for the ‘how’ around the decisioning process. I see it as being useful because the practice puts you into the mindset of not over committing to ideas, equally getting you to consider all possible options and whilst many people often ignore black swan events as being improbable. Thinking through what would happen if such an event occurs allows you to plan / consider what you’d do in those situations.

Why would you use Real Options? To consider the future possible but without over committing to any one option. This gives you the ability to be agile in your thinking and not be fixed to a solution and it also allows you to break down options into smaller steps that allows you to defer options whilst still delivering something of value.

Chris even produced a graphic novel which you can get for free!

Cynefin by Dave Snowden

Cynefin is a sense making framework for dealing with uncertainty in the world. Cynefin breaks the world into domains. Cynefin is a Welsh word that means ‘Place of Your Multiple Belongings’. Some of these domains have gone through renames over the years e.g. simple, obvious, clear.

The work by Dave and his company ‘The Cynefin Company’ (formerly Cognitive Edge) is now freely available on their wiki here: https://cynefin.io/

I’ve observed from experience that practices are situational, and Cynefin explains that. Not all practices make sense in every situation. I often listen out for people using the term ‘best practice’ to see how they are using it and often strike up a conversation about Cynefin as a result. This is often something I see where people are asking for checklists or templates when it comes to agile transformation work. People are uncomfortable, they don’t have the experience and don't know the practices, so they want to be given templates to follow as scaffolding.

Be careful with templates, they can serve a purpose if created thoughtfully but you should avoid spoon feeding people as that prevents them from thinking independently and learning from experimentation and observation.

Why would you use Cynefin? The more you learn about Cynefin, the more you realise it can be applied generally. Cynefin helps you situate yourself and gives you a framework for how to act in that context. This made sense to me, when I heard Dave point out that users don’t know what they want until they see it.

When building products, especially new ones that teams haven’t built before, the work sits in the Complex domain. The needs are not clear as you are often solving a new problem for the first time. Needs emerge and cannot be written down and in many cases we don’t even know how to build the new product. Instead, running multiple safe to fail probes gives you a way to find out what is most valuable to your users, so consider doing this early and often to find your value.

The practices you use in a Complex context are different and more exploratory and allow you to quickly run multiple probes in parallel to find out what works and what doesn’t.

Check out the video below on Rewilding Agile for more on that.

Ordered

In Clear, you can apply a best practice to a situation (e.g. a checklist, knowledge base article) and there is one way of doing things. This is the type of context where everyone knows what to do and the approach is obvious.

In Complicated, you rely on the guidance of experts for Good practices to apply (e.g. a mechanic, accountant, doctor), the world is knowable but requires expertise.

Complex

In Complex, there are ‘Exaptive’ practices which is an evolutionary term to describe taking practices from other disciplines and applying them in a new way (e.g. the human body). The option here is to perform multiple ‘safe to fail probes’ (in parallel) to see what works best.

Chaotic

In Chaotic, there are no defined practices, and instead they tend to emerge from taking an action and sensing for input (e.g. when the COVID pandemic started and there was not known vaccine). This domain is typically a situation where a crisis starts out and people don’t know what works or is effective.

Confusion & Aporia

The Confused and Aporetic domain (the 5th) is represented by the state of confusion and being in potentially multiple states as once. This domain is often jokingly referred to by Chris Matts as the 5th quadrant, mostly meant as a poke at Dave. I’ve not explored this domain as much as the others, I would summarize as a state of confusion of puzzlement. Clearly this isn’t a place to stay long!

There’s more to the domains and other domains to explore, I wanted to keep things concise for readability. More on the Cynefin domains wiki

Check out one of Dave’s more recent talks on Cynefin.

Dave’s more recent take on ‘Rewilding Agile’ with his Complexity science lens is also quite interesting too.

Dave’s Cynefin language can be overwhelming the first few times you try and get your head around things. As such the following supporting articles might give you a softer landing.

Cynefin for Everyone!
Five years ago, around Christmas 2012, I wrote an article about Cynefin, the sensemaking framework. I focused it on…lizkeogh.com

Cynefin with Examples
Cynefin is a public domain (citation needed), complexity-centered framework for sense-making. There are 5 ontological…hiredthought.com

What other decision and sense making frameworks have you found to be useful on your travels?

Beware, these topics will lead you down a rabbit hole but are worth the exploration. I’ve been learning about them for a couple of years already and continue to be surprised when I find a new opportunity to use these frameworks.