Culture Add Over Culture Fit

You’ve probably heard of the culture-fit interview. Maybe participated in one. Organizations and teams rightly want to know not only does this person have the skills and aptitude for the job, but also “will this person work in our particular environment?” Prospective employees also want to know that. But by emphasizing culture fit — the assimilable qualities of the person — we may lose sight of an important benefit of bringing new people into our organizations: the person’s additive qualities — new ways of thinking and working, external experiences — that bring energy, creativity and improvement that we can’t simply bootstrap ourselves into from within.

Why Culture Fit Can Be Pernicious

First, don’t hear what I’m not saying — that seeking culture fit itself is unhealthy. Culture fit is absolutely an area of concern, and organizations and candidates should of course consider it in the mix of hiring and development attributes. However, we need a counterbalance, a corrective to it. That’s because culture fit is all too often a one-way concern: Will the person fit in with us? Lest we miss out on what our new hires have to offer, we need that to be bidirectional and mutual: What can we co-create that we couldn’t before?

The lure of culture fit can be particularly pernicious for organizations that pride themselves on their culture. And it makes sense: You don’t want to hire a person who is at odds with the group’s core values and principles. But the tribal nature of culture means a rejection to some degree of outsiders. No matter how much lip service we give to diversity and inclusion, we’re often satisfied with a superficial accomplishment: We’ve hired people who help us create a rainbow in corporate photos, but unfortunately that diversity is only demographic deep. The truly helpful impact is measured only insofar as we allow their ideas to penetrate the often impermeable boundaries of our culture after we’ve hired them.

For example, I once worked with a leadership team who had been in the organization for many years and typically managed their work through spreadsheets, which meant that the group tended to meander in their discussions and would jump from one priority to the next. When I joined their ranks and offered the idea of making the work more visible on a card wall, the group had a choice:

  • Reject the idea out of hand
  • Nod and passively acknowledge the idea but ultimately ignore it
  • Consider then either try or reject the idea

Only the third option demonstrates that a) the group was intellectually curious enough to discover new ways of working and b) viewed their new colleague as having something to contribute. Unfortunately, this group’s choice was to ignore it. Only long afterward did I realize that it wasn’t intentional or out of malice but merely because the group had become so ossified that they couldn’t even countenance what it might mean to work differently. Partly because they had been successful on their own, they had no mental model for improvement that originated somewhere else. It’s the opposite of the “prophet without honor in his hometown” problem; it’s more like “Can anything good come from outside of here?”

And that’s the danger of culture fit: Without intentional and disciplined practices that keep us open to the new members of our groups, we will atrophy in our existing ways of thinking and working.

Culture Fit without Culture Add

Many new hires struggle to find and stay in the flow channel, psychologist Mihaly Csikszentmihalyi’s concept for “being in the zone,” or full engagement in work. I believe that much of the reason new hires find themselves languishing outside of the flow channel is attributable to a lack of mutual integration and intentional concern for knowing (a person feeling unknown) and putting to good use the competencies of the people we’ve invited to come work alongside us (feeling unwanted).

By paying attention to culture-adding behaviors, we can design our organizational and team experiences to bring people back into the flow channel.

How to Emphasize Culture Add

So we need to balance two goals:

  • Help the new person to fit into the organization and
  • Help the organization to create space for the new person.

Some organizations offer “get to know you” activities during orientation, which is a helpful start. But we should go beyond learning about the person’s hobbies and family. What special qualities and skills does he or she have to bring to work to positively impact us? This is additive or supplemental thinking.

Heidi Helfand talks a lot about dynamic reteaming and how a single change — someone joining the team, someone leaving it — means that you have a new team. We need to take a moment to acknowledge that, rather than carrying on as if nothing happened. We have a new team member; what does that mean for us?

When I led the coaching practice at Asynchrony Labs, one of the questions we coaches would always ask each other about each candidate was “What can this person teach us?” That is, what new or different ideas or competencies might this potential teammate introduce to our group so that we might collectively improve ourselves? Though we wanted someone who would generally share our philosophical approach, we also didn’t want to remain as we were. We explicitly acknowledged that we had a hole in our group, and though we may not know exactly what it was, we pursued filling it from outside ourselves. It’s the perfect culture-add question, because it ensures by its nature that you’re honoring and intentionally expecting the new person’s unique contributions.

Some other options for emphasizing culture add:

  • Marketplace of Skills activity 
  • Strengths Interview (from First, Break All the Rules), which is then shared with each of the new hire’s teams for the first year
  • Create opportunities for the new hire to teach his or her new team (or other group) something that he or she brings ; another option is to have each new person, as part of orientation or onboarding, actually have a spot in the agenda to share something about what he or she brings. This demonstrates the organization’s view not only that each new person is valued but that the organization has a need to learn and improve and that the new person in their midst is going to help.
  • Personal Best
  • The Ten Faces of Innovation activity
  • Follow him or her on Twitter, etc. What’s the Twitter-follower imbalance? That is, how many of your team does the new hire follow, and how many of the team follow him?
  • Give the new person point of privilege in retrospectives and other team meetings

Ultimately we need to be taking the disciplined steps each day to ensure that culture adding happens, because in our tribal ways, it’s unnatural. Build in a policy whereby someone from the organization — I call this role the onboarding concierge — helps the group to learn about the new hire to find out what the person loves, especially the stuff outside of the role you’ve hired him or her for. Even simple changes in how we talk about our approach can help, like how one company changed their approach from “culture fit” to “values fit.”

Herman Miller’s Ed Simon (as quoted in The Fifth Discipline) summarizes the challenge well:

Embracing change does not mean abandoning a core of values and precepts. We must balance our desire for continuity with our desire to be creative. We must learn how to not abandon that core, while simultaneously letting go of past ways of doing things… This requires a new paradigm, a new model of how organizations work — organizations that operate in a continual learning mode, creating change.

For further exploration:



Never commit early, unless you know why

Real-options thinking in knowledge-work has a catchy three-part mantra (made all the more memorable if you’ve ever met Chris Matts, Olav Maassen or Olaf Lewitz):
Options have value.
Options expire.
Never commit early, unless you know why.
If only someone had told the Los Angeles Dodgers, who this past weekend neglected that final bit of wisdom.

You don’t need to be a baseball fan to learn from their mistake, given a little background. In Major League Baseball, teams are allowed to shuttle players between their major-league club and their minor-league club (a kind of reserve team). The major-league club has a roster maximum, so in order to add a player (either returning from injury, coming from another club or up from the reserves), the club needs to subtract someone, usually by sending him to the reserves. When a player goes to the reserves, he must stay there for at least 10 days before the club can recall him to the first team.


Well, the Dodgers needed an extra pitcher last weekend, so they called up their top prospect Walker Buehler for one game, assuming that one of their regular players would return from injury soon afterward. Buehler played well and showed that he was worthy of another appearance. However, the club optioned (literally the term that they use in MLB) him back to the minors, but before they learned that the injured player they were counting on returning had suffered a setback. As a result, Buehler might have been in line for another start later this week, but he’ll now have to wait 10 days before he can return. Had they waited only hours later, the new information about their returning player would’ve been available to them.
Screen Shot 2018-04-30 at 1.35.56 PM.png
The Dodgers committed early, but they didn’t know why. Or rather, they likely didn’t think they were committing early because they assumed their plan would not change. You would think that professional-sports teams would have a better sense of the complex domain they’re working in, what with player injuries being a particular part of the game. Especially Rich Hill injuries (sorry, Dodger fans). One problem in committing without thinking is that the costs of premature commitment aren’t always visible until too late, which the Dodgers now painfully realize.


It’s easy to see the folly in the Dodgers’ oversight. Yet we do the same thing in our knowledge-work organizations, committing too early to projects, tying up people and resources that could be more valuably deployed elsewhere, or simply starting a bit of work before doing a bit of analysis to foresee upcoming dependencies. Deferring commitment is an organizational discipline, so it starts with practice. Most people that I’ve worked with over the years don’t naturally think this way, so starting simply can help. Asking the basic questions “Do we need to commit to this now, or can we wait?” and “What’s the cost or tradeoff if we wait on this?” can help build options-thinking. You might also use a practice like risk profiling to gain a better sense of your options — and when you might need to responsibly commit. Using metrics like delivery times and their percentile confidence intervals can inform commitment decisions. For instance, if a standard work item is completed 85% of the time in 10 days, and it’s a low-risk item, you might reasonably decide to defer commitment if you’re 25 days out. But without tracking delivery-time data, you’re going to be making guesses and relying on assumptions. Just like the Dodgers.

Kanban’s First Change-Management Principle and Chesterton’s Gate

At a recent Lean Kanban St. Louis meetup, I shared that, while the Manifesto for Agile Software Development has been amazingly enduring, it was silent on the issue of change management, which, in my experience, is the area that most commonly inhibits the ability for the Manifesto’s values and principles from taking root.

This is why I appreciate that the Kanban Method explicitly addresses change-management, and in particular, sets the tone with its first change-management principle:

Start with what you do now, understanding current processes, as actually practiced, and respecting existing roles, responsibilities and job titles.

In their book Essential Kanban Condensed, David Anderson and Andy Carmichael explain it this way:

…the current processes, along with their obvious deficiencies, contain wisdom and resilience that even those working with them may not fully appreciate.

This is the challenge that people brought into organizations as “change agents” or “agile coaches” face — I know, because I’ve been one and, to my and my client’s disservice, not heeded this advice. And in fairness, it’s difficult: The ambit — get results, immediately — is often at cross-purposes with this principle.

It reminds me of an earlier bit of wisdom from the writer G.K. Chesterton:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

This metaphor has become known as “Chesterton’s Fence.” To be sure, it takes time to understand the reason for the fence, and, to be sure, in many organizations, time has obviated the need for the fence. But lest we strip away something that provides resilience, or simply create ill will by disrespecting another’s work, we’ll do well to first understand the reason for the fences — “the more intelligent type of reformer.”

Service-Delivery Review: The Missing Agile Feedback Loop?

I’ve been working for many years with software-delivery teams and organizations, most of which use the standard agile feedback loops. Though the product demo, team retrospective and automated tests provide valuable awareness of health and fitness, I have seen teams and their stakeholders struggle to find a reliable construct for an important area of feedback: the fitness of their service delivery. I’m increasingly seeing that the service-delivery review provides the forum for this feedback.

What’s the problem?

Software delivery (and knowledge work in general) consists of two components, one obvious — product — and one not so obvious — service delivery.  I’ve often used the restaurant metaphor to describe this: When you dine out, you as the customer care about the food and drink (product) but also how the meal is delivered to you (service delivery). That “customer” standpoint is one dimension of the quality of these components — we might call it an external view. The other is the internal view — that of the restaurant staff. They, too, care about the product and service delivery, but from a different view: Is the food fresh, kept in proper containers, cooked at the right temperatures, and do the staff work well together, complement each other’s skills, treat each other respectfully (allowing for perhaps the occasional angry outburst from the chef, excusable on account of “artist’s temperament”!). So we have essentially two pairs of dimensions: Component (Product and Service Delivery) and Viewpoint (External and Internal).
In software delivery, we have a few feedback loops to answer three of four of these questions and have more-colloquial terminology for that internal-external dimension (“build the thing right” and “build the right thing”):
The problem is that we typically don’t have a dedicated feedback loop for properly understanding how fit for purpose our service-delivery is. And that’s often equally the most vital concern for our customers — sometimes even more important than the fitness of the product, depending on whether that’s the concern of a delivery team or someone else. (One executive sponsor that I worked with noted that he would rather attend a service-delivery review than a demo.) We may touch on things like the team’s velocity in the course of a demo, but we lack a lightweight structure for having a constructive conversation about this customer concern with the customer. (The team may discuss in a retrospective ways to go faster, but without the customer, they can’t have a collaborative discussion about speed and tradeoffs, nor about the customer’s true expectations and needs.)

A Possible Solution

The kanban cadences include something called a Service-Delivery Review. I’ve been incorporating this to help answer teams’ inability to have the conversation around their service-delivery fitness, and it appears to be providing what they need in some contexts.
David Anderson, writing in 2014, described the review as:
Usually a weekly (but not always) focused discussion between a superior and a subordinate about demand, observed system capability and fitness for purpose Comparison of capability against fitness criteria metrics and target conditions, such as lead time SLA with 60 day, 85% on-time target Discussion & agreement on actions to be taken to improve capability
The way that I define it is based on that definition with minor tweaks:
A regular (usually weekly) quantitatively-oriented discussion between a customer and delivery team about the fitness for purpose of its service delivery.
In the review, teams discuss any and all of the following (sometimes using a service-delivery review canvas):
  • Delivery times (aka Cycle/Lead/Time-In-Process) of recently completed work and tail length in delivery-time distribution
  • Blocker-clustering results and possible remediations
  • Risks and mitigations
  • Aging of work-in-progress
  • Work-type mix/distribution (e.g., % allocation to work types)
  • Service-level expectations of each work item type
  • Value demand ratio (ratio of value-added work to failure-demand work)
  • Flow efficiency trend
These are not performance areas that teams typically discuss in existing feedback loops, like retrospectives and demos, but they’re quite powerful and important to having a common understanding of what’s important to most customers — and, in my experience, some of the most unnecessarily painful misunderstandings. Moreover, because they are both quantitative and generally fitness-oriented, they help teams and customers build trust together and proactively manage toward greater fitness.

Service-delivery reviews are relatively easy to do, and in my experience provide a high return on time invested. The prerequisites to having them are to:

  1. Know your services
  2. Discover or establish service-delivery expectations

Janice Linden-Reed very helpfully outlined in her Kanban Cadences presentation the practical aspects of the meeting, including participants, questions to ask and inputs and outputs, which is a fine place to start with the practice.

Afterward #1: In some places I’ve been, so-called “metrics-based retrospectives” have been a sort of precursor to the service-delivery review, as they include a more data-driven approach to team management. Those are a good start but ultimately don’t provide the same benefit as a service-delivery review because they typically don’t include the stakeholder who can properly close the feedback loop — the customer.

Afterward #2: Andy Carmichael encourages organizations to measure agility by fitness for purpose, among other things, rather than practice adoption. The service-delivery review is a feedback loop that explicitly looks at this, and one that I’ve found is filling a gap in what teams and their customers need.

Afterward #3: I should note that you don’t have to be in the business of software delivery to use a service-delivery review. If you, your team, your group or your organization provides a service of any kind (see Kanban Lens and Service-Orientation), you probably want a way to learn about how well you’re delivering that service. I find that the Service-Delivery Review is a useful feedback loop for that purpose.

[Edited June 12, 2017] Afterward #4 (!):  Mike Burrows helpfully and kindly shared his take on the service-delivery review, which he details in his new book, Agendashift: clean conversations, coherent collaboration, continuous transformation:

Service Delivery Review: This meeting provides regular opportunities to step back from the delivery process and evaluate it thoroughly from multiple perspectives, typically:
• The customer – directly, via user research, customer support, and so on
• The organisation – via a departmental manager, say
• The product – from the product manager, for example
• The technical platform – eg from technical support
• The delivery process – eg from the technical lead and/or delivery manager
• The delivery pipeline – eg from the product manager and/or delivery manager

I include more qualitative stuff than you seem to do, reporting on conversations with the helpdesk, summarising user research, etc

Book Review: Actionable Agile Metrics for Predictability

Screen Shot 2015-04-29 at 6.46.56 PMDaniel Vacanti’s new book, Actionable Agile Metrics for Predictability, is a welcome addition to the growing canon of thoughtful, experience-based writing on how to improve service delivery. It joins David Anderson’s (Kanban: Successful Evolutionary Change for Your Technology Business) and Mike Burrows’s (Kanban from the Inside) books in my list of must-reads on the kanban method, complementing those works with deeper insight into how to use metrics to improve flow.

Daniel’s message about orienting metrics to promote predictable delivery and flow — which he defines as “the movement and delivery of customer value through a process” — is primarily grounded in his experience helping Siemens HS. He includes the case study (which has been published previously and is valuable reading in itself) at the end of the book, so he keeps the rest of the book free from too many customer references, though he’s drawing on the pragmatic experience.

As someone who for several years has been helping teams and organizations improve using the metrics Daniel talks about, I learned a tremendous amount. One of the reasons is that Daniel is particularly keen to clarify language, which I appreciate not only as a former English major (nor as a pedant!), but because it helps us carefully communicate these ideas to teams and management, some of whom may be using these metrics in suboptimal ways or, worse, perverting them so as to give them a bad name and undermine their value. Some examples: The nuanced difference between control charts and scatterplots and clear definitions on Little’s Law (and violations thereof), especially as related to projections and cumulative flow diagrams. I certainly gained a lot of new ideas, and Daniel’s explanations are so thorough that I suspect even novice coaches, managers, team leaders and team members won’t be overwhelmed.

As for weaknesses, I felt that the chapter on the Monte Carlo method lacked the same kind of depth as the other chapters. And I came away wishing that Daniel had included some diagrams showing projections using percentiles from scatterplot data. But those are minor plaints for a book that constantly had me jotting notes in my “things to try” list.

Overall, I loved how Daniel pulled together (no pun intended), for the purpose of flow, several metrics and tools that have often been independently implemented and used and whose purpose— in my experience — was not completely understood. The book unifies these and helps the reader see the bigger picture of why to use them in a way I had not seen before. If you’re interested in putting concepts and tools like Little’s Law, cumulative flow diagrams, delivery-time scatterplots and pull policies into action, this book is for you.

Other observations:

  • The book has a very helpful and clarifying discussion of classes of service, namely the difference between using CoS to commit to work (useful) and using it to prioritize committed work (hazardous for predictability).
  • It also had a particularly strong treatment of cumulative flow diagrams.
  • Daniel does a lot of myth debunking, which I appreciate. Examples: work items need to be of the same size, kanban doesn’t have commitments.
  • The tone is firm and confident — you definitely know where Daniel stands on any issue — without being strident.

What is Autonomy Support?

I wrote a few weeks ago about the advocacy program, our distributed peer-to-peer continuous-improvement program. One of the important components of the program is autonomy support. But what is that? As Daniel Pink notes in his book Drive:

Researchers found greater job satisfaction among employees whose bosses offered “autonomy support.” These bosses saw issues from the employee’s point of view, gave meaningful feedback and information, provided ample choice over what to do and how to do it, and encouraged employees to take on new projects.

In the advocacy program, autonomy-support meetings are an optional opportunity for employees to meet with executive management to give feedback on how the executive leaders can help the employee realize career goals in the organization. The meeting can be scheduled by the employee’s advocate, who also can be part of the meeting, acting as an intermediary or ambassador for the employee to the manager(s). Multiple managers may be part of the meeting, depending on which ones the advocate and employee feel are vital and able to help.

The dynamic should be one in which the traditional organizational structure is flipped upside-down:

Autonomy-support meetings

Therefore, rather than the traditional dynamic of the employee “working for” the manager, in the autonomy-support meeting the servant-leader — in this case, the role of executive leader — should have the mindset of “working for” the employee.

A good starting point for the discussion is the “autonomy-support feedback for executive leaders” section of the employee’s review. Basically, it’s whatever the employee needs executive leaders to do in order to do his or her job better or reach goals. This might be a request for a different project or role switch, more time to explore a particular skill or technology or simply clearer vision or expectations set. Premised on the executive leader’s commitments to the employee, the employee has the right to ask for the executive leader for support in various career-development goals, including timelines for when those things would occur.

Questions that the executive leader might want to ask:

  • How can I help you realize your goals in the next year?
  • By when would you like me to achieve these things for you?
  • In what areas have I failed to help you in the past, and how can I improve?
  • What kind of things would help you feel more engaged?
  • How can I help smooth your path toward mastery of certain skills?
  • What does success look like for you, and how can I help you succeed?

The peer-to-peer feedback-improvement cycle in action

I recently posted about the new peer-to-peer continuous-improvement program that we’re doing at Asynchrony. One of the key aspects of the program is its emphasis on feedback. Direct feedback is often difficult to deal with because people aren’t accustomed to it (especially if it’s critical), so we encourage face-to-face discussions in safe environments. Here’s a real conversation (names changed) that occurred over instant messaging between an employee (“Will”) and his advocate (“Jessica”), posted with their permission. Will has just provided his advocate with his self-review (a one-page overview of recent accomplishments, future goals and ways to improve) and has been collecting feedback from some of his personal stakeholders, which he has shared with Jessica.


What did you think of my self-review?


I think it was very in depth and really liked the explanation of why you did what you did but Pete raised a good question as to how you like to feel like the smartest person in the room… I think we should maybe address that in goals for 2014… Please advise


That’s something I’d like us to talk through. I think its good feedback but its also foreign to me. It feels like telling a razor to be less sharp so the other razors don’t feel bad. I was brought up and live in an environment where all the razors are helping each other be as sharp as they can.


We definitely need to work on being humble then… lol


I’m GREAT at being humble. 🙂


There is another saying, if you are the smartest person in the room… Maybe you should exit stage left…


I never claim to be the smartest person in the room.


Sometimes we don’t have have to say things to make that impression.


Yep. This is something we should talk about over a beer. Are you free after work today or some day this week?


Tomorrow night?


Sounds good

The two peers invited the colleague who provided feedback (“Pete”) to chat in person, and they had a very productive discussion to clarify the feedback and collaborate on ways to improve.

This is how we designed the advocacy program to work: People obtain feedback, the advocate holds him or her accountable and the two discuss improvement face-to-face. You’ll notice that the advocate doesn’t possess any specialized skills in career development or domain-specific expertise; she merely acts to reinforce the accountability loop by deftly supporting Will and at the same time not simply coddling him in the name of “advocacy.” Politely asking a colleague — especially one who has given you explicit permission — how he or she plans to address important issues is something everyone can do.

All three people in the scenario above were honest and respectful with each other: the employee honestly wants to improve, the third person has given honest, respectful feedback and the advocate honestly and respectfully responds when the person for whom he is advocating. Contrast this with the less-than-respectful way that anonymous peer reviews can come off and the sometimes-perverse incentives that people have for being interested in feedback in the first place (as a means to the end of making a case for a raise), and you see that this is a very different dynamic from how many organizations operate.