Tag Archives: continuous improvement

Dean Meyer’s “How Organizations Should Work” – an A+ Reference on Intentional Organizational Design

Posted on by Leave a comment

The organization that you design designs you back.

Similarly, the organization that you fail to intentionally design will also design you back. And you probably won’t like the pain it inflicts… whether that pain manifests as political battles, conflicts of interests, or just plain stonewalling or slow-walking. People tend to perform based on how well their goals and objectives are defined, how effectively their roles (and the relationships between their roles and other roles) are defined, and how rigorously the organization monitors and reinforces desired behaviors and outcomes.

Unfortunately, it’s rare to get all those pieces in place and functioning at the same time. But thanks to Dean Meyer’s new 2022 book, How Organizations Should Work, you’ll have a head start on lessons learned. Based on his multi-decade career in organizational design, he provides simple, tangible, and meaningful explanations that will help you learn how to intentionally design your organization.

I brought this book to Burning Man because I wanted to read it in a place where I could take my time, where I could allow my mind to expand and take in Dean’s lessons, where I could feel the inspiration all around me while figuring out how to bake more inspired organizational design into my own workplace. And I did start reading it there.

But this book is so packed with wisdom and insights that you’ll want to read it slowly. Plan adequate time for it. After getting through the first 80 pages or so at the event, I read one or two sections every weekend. It took me a full three months to get through cover to cover… and I’m someone who can read a whole book in one sitting. This one, though, will make you think, and you’ll need time to pause and reflect on each of the stories and narratives that Dean uses to make his points.

Here’s a small sample of the highlights (and there are more; you can find this book on Amazon for $37-40).

Book Summary (p. 465-494). The best way to develop a reading plan for this book is to start at the end. Dean provides a helpful synopsis of each chapter that you can use to figure out which sections are most relevant for your organization now. The book is structured so that you don’t have to read it from start to finish, but can pick the sections that are the highest priority for continuous improvement in your organization. Some sections (like Chapter 19, on managing workers in the field) may be less relevant to your needs than other sections (like Chapter 15, on aligning sales and marketing). I recommend starting with Chapters 1 through 6 (and if your time is limited, start with Chapters 5 & 6).

Chapter 5 – Market Organization & Chapter 6 – Empowerment (p. 33-57). These two chapters provide the best (and most concentrated) view of the main thesis of the book, which is that every organization should be structured as a market. Each functional area should have customers, and services they provide to those customers. Each functional area should be empowered to make decisions about how the business of that unit is conducted, and should also have the skills to do it (and to build trust within their business unit and between their business unit and others). Organizing according to a market allows people to specialize, makes it possible to monitor performance in a more modular way, and simplifies the cognitive complexity of an organization.

Appendix 4 – Culture: Examples of Behavioral Principles (p. 376-380). Dean notes that companies are great at defining their culture, but often not so great at explaining how people can embody that culture and monitor their behaviors to ensure that they are living it and reinforcing it. In this section, he provides specific examples of behaviors that can make goals like “maintain a high ethical standard” actionable. For example, you can say “we do not permit personal conflicts of interest”. You’ll have to test your processes against these behavioral expressions of culture, too: if you don’t permit personal conflicts of interest, you should identify areas where conflicts of interest might arise and anticipate ways to identify them, prevent them, or resolve them quickly.

There are so many things I like about this book, and it embodies so many principles of good organizational design in a light, conversational way. Although there are a lot of books I really like, I don’t typically gush over them… but this one meets my high standards. Coupled with Dean’s 2017 book, Principle-Based Organizational Structure (which has a less conversational and more academic style), these are the only two references I really need to remind me of the essentials for intentionally building healthy organizations that are aligned internally and externally.

Alignment is the best way to reduce friction between people, and accelerate real progress towards tangible goals.

Agile Should Not Make You Feel Bad

Posted on by Leave a comment

Agility can be great (even though for many neurodivergent people, it’s the opposite of great). But when teams go through the motions to be “Agile” they often end up overcomplicating the work, adding stress to interactions, and achieving less agility.

If your agile processes are “working”, then over the next iteration (typically 1-4 weeks):

⬜ You have a clear understanding, as a team, of the value you’re working to demonstrate. (Note that this is not a promise or a commitment, but a shared purpose, direction and intention.)

⬜ You have a clear understanding, as individuals, of the actions that will generate that value. You know what to work on (and think about) when you’re not in meetings or with clients.

⬜ You don’t feel alone – you have teammates to communicate with and collaborate with, and resources you can use, as you move forward to advance project objectives.

⬜ You are working at a comfortable, sustainable pace.

⬜ Your team is improving every week – you continually do things a little differently to help improve quality, productivity, collaboration, or other outcomes.

None of these things require meetings (or “ceremonies”) – just communication and inclusion. We should always be asking ourselves and our team members: what’s the easiest, smoothest, least intrusive way of building this shared understanding and maintaining it every day?

When teams work with agility:

⬜ Everyone understands the overall goal and the next increment of value to demonstrate.

⬜ Everyone has clear things to do to contribute to that value.

⬜ Each person (and the team as a whole) works at a sustainable pace.

⬜ Nobody feels alone. There’s a group of collaborators to share the work with.

⬜ The client or project champion has visibility into the work and is happy with progress.

⬜ There’s an opportunity to rest, reflect, and adjust every week or two.

⬜ It’s not ridiculously hard to adjust to changes in scope, tools, or personnel. 

But I regularly see “agile” teams flailing… unhappy… in constant panic mode, with stress that just won’t end. They are very busy and always seem to be scrambling to show their client or project champion some kind of value… with the feeling that they have to defend their existence. They have a nagging sense of confusion and impostor syndrome may be creeping in. They can tell you exactly what tasks are on their JIRA boards, but they can’t tell you why those tickets exist or how their task is contributing to overall project value. They have lost sight of the forest (value) because they have planted so many trees (tickets).

For these teams, the Scrum process and Agile ceremonies may be adding layers of stress and bureaucracy rather than helping the team work sustainably to consistently drive value. They are “doing Agile ” but have actually made themselves less agile… less able to flow and adapt and respond to changes in scope, tools, or participants.

Agile methods first emerged in response to the slow, painful, unsatisfying, unhappy practice of software development. It was really depressing to spend months building software, only to have customers and users complain how bad it was when they got it (especially when you developed exactly what they specified). It felt isolating to have to figure out how to deliver a piece of the software without any input from other engineers, and it was distressing when others were blocking your work and you had to convince them to listen to you. The whole endeavor was inefficient, and people were often tense and stressed. 

The realizations in red (in the 90s) led to the Agile Manifesto items (2001) in blue

We’re applying processes and tools without really examining why we need them

So let’s prioritize…

Individuals and interactions over processes and tools

  • Why this is part of the Agile Manifesto: Since the beginning of time, development teams tend to get hung up on the details of using tools (e.g. MS Project, JIRA, kanban boards) rather than why the tools are there in the first place: to make sure people are getting the information and context they need – on a regular, routine basis – to make continuous progress on the team’s overall deliverables.
  • What we should do in 2022: Focus on information sharing, context building, and working arrangements that help people get work done. This applies to interactions within the team as well as interactions with the client.

We’re doing a lot of work that doesn’t actually contribute to our goal

So let’s prioritize…

Working software [ie. tangible stuff that’s valuable] over comprehensive documentation

  • Why this is part of the Agile Manifesto: Software development in the 1990s was documentation-heavy. I even remember, in 2018, throwing away a few hundred pounds of paper (in about 20 4” binders) containing requirements and design documents for a really big software project that we did between 2002 and 2004. Often, development teams wouldn’t even produce software that matched the documentation because we’d learn about what was feasible and what was not as we were doing it. Everyone tended to deliver software that the business needed a year or two ago. We didn’t learn together and co-create the software. 
  • What we should do in 2022: We provide value in the form of information, shared understanding, and working software (which may be in the form of quality controls) – that’s it. Anything we produce that doesn’t directly contribute to making these things happen shouldn’t be done. 

We’re unable to deliver something we don’t know how to define or describe yet

So let’s prioritize…

Customer collaboration over contract negotiation

  • Why this is part of the Agile Manifesto: Because deciding what you’re on the hook to deliver at the beginning of a project – and exactly what the deliverables are going to look like – is dangerous. You and the customer rarely have enough understanding of the problem (or of each other) to get it right. 
  • What we should do in 2022: Establish shared accountability. (Note: this is rare. How many times has a customer been on your team and just as accountable to the project champion for the end result as you are?) A workaround is to set expectations with the client that we are discovering the shared understanding together, and we will get as close to the desired deliverables as we can, given the fact that we are embarking on a process of learning together.

We’re unable to commit to a plan when we might learn that our plan isn’t feasible

So let’s prioritize…

Responding to change over following a plan

  • Why this is part of the Agile Manifesto: As you learn about what’s possible, what’s not possible, and what the client actually values… plans will change. Instead of establishing a timeline that won’t end up working out (and that will cause you a lot of stress when you start deviating from), just start with the understanding that your Gantt Chart and your intermediary milestones will probably not be achieved when you think they will – or maybe even at all.
  • What we should do in 2022: Always keep the final goal in mind, but revisit and adjust the plan as you learn more every week. Iterate! 

The Discovery Channel Test

Posted on by Leave a comment

Presentations can be boring. Talking about your work can be boring (to other people). When you’re sitting in a talk or a session that you find boring (and you can’t figure out WIIFM – what’s in it for me)… you learn less.

Although we shouldn’t have to use clickbait techniques to satisfy societally decreasing attention spans, it is easier to learn and retain information when it’s interesting. So I encourage all of you to apply the “Discovery Channel Test” to every presentation, talk, or session you contribute to or lead.

The reason I call it the “Discovery Channel Test” is that there used to be a program called City Confidential that was on all the time. Even though City Confidential was a show about murder mysteries, the first half of the one-hour show was about the city or region where the crime occurred. They talked about when the town was first settled, and key families who made the town what it is today. You heard about stories of intrigue, and challenges the town was facing today. They made the story about the town itself so captivating that EVERY SINGLE TIME I was caught off guard when they ended the first half-hour segment with “You’d never believe a murder could happen here.” Through the hundreds of times I watched this show, I was always shocked when this point came. “Oh, yeah… this is where that murder mystery happened, and we’re about to find out about it.”

Any production crew that can spend a half hour off-topic, keep me interested, and give me a dopamine burst right before the main point of the show… has achieved something great. And you, too, can achieve this same greatness when you’re talking about your tech stack or a new architectural initiative or that project you did last year that improved customer sat. Make it interesting by applying….

The Discovery Channel Test (* = could also be called The Good Podcast Test)

Rule 1: Use an emotional hook up front. Why should any of the people in your audience not leave after the first five minutes? Don’t make them guess! Tell them specifically why this topic might be interesting, or surprise them with an initial feeling of novelty or unexpectedness. Jonathan Lipnicki’s character in Jerry Maguire (1996) was great at this, with his “did you know?” questions. The dopamine surge you create with an emotional hook will keep them engaged for long enough to get hooked on your story.

Rule 2: Find the wow nugget(s). This is one of the things the Discovery Channel has always been really good at: getting me interested in things that I didn’t think were interesting to me. Remember that your projects and initiatives, no matter how cool they are to you, will be boring to other people unless you TRY to make them interesting. I try to tell my high schooler that even in the most boring classes you should be able to find some nugget, some angle, some insight that helps you see the subject matter in a way that grabs you. Find that angle for your audience, and then spoon feed it to them.

Rule 3: Use examples, screen shots, visuals, diagrams. If your presentations are full of slides with words, people will start yawning immediately and may or may not actually hear those words. You can also reduce ambiguity with examples and screen shots. For example, saying “we used Python for this project” is far less compelling than showing the tree structure of the code (or a simplified diagram) and annotating it with what each piece did to get the overall job done. Saying “we used Confluence” is less compelling than saying “we set up a confluence site at [this location] and agreed to put [this kind of information in there]” because if someone has a need for [that information] – at least they know a first place they can look for it.

Rule 4: Spoon feed the closing thoughts. At the very end, remind people what you want them to remember when they leave. Remind people why that’s interesting, and how it might benefit them in the future. Make it concrete and tangible. For example, can you give them reference material, or an infographic, or a checklist that they can use in the future? Don’t assume that people will get something out of your presentation just by attending… spoon feed what you WANT them to get out of it.

“Documentation” is a Dirty Word

Posted on by Leave a comment

I just skimmed through another 20 page planning document, written in old-school “requirements specification”-ese with a hefty dose of ambiguity. You know, things like “the Project Manager shall…” and “the technical team will respond to bugs.”

There’s a lot of good content in there. It’s not easy to get at, though… for each page I want to understand, I can expect to spend between ten minutes and an hour deciphering what’s going on. (That’s half a week of work, and I have a lot of other work to do this week. Is it even worth it?)

Also, this document is boring… and there’s a lot of filler (like “package X is useful, flexible, and open source” – OK, that’s great, and factually correct, but not very informative).

The whole document could have been condensed into 4 or 5 slides of diagrams plus annotations. If that had happened, I’d be looking at a 10 to 30 minute commitment overall to get my brain into this particular company’s context… and then I’d be able to make some useful contributions. (As it stands, I’m weighing whether it’s worth my time to go spelunking in that 20-pager at all. Probably not.)

Unfortunately:

  • The bulk of technical documentation that I read is unintelligible or lacks sufficient meaning. I have three decades of exposure to this stuff, so if I can’t understand it, I feel super sorry for the early career people (who might think they can’t understand it because they don’t know enough).
  • Nearly all of the technical documents I see are uninteresting. And tech is interesting.

99 times out of 100, technical documentation is dull and dysfunctional. While it’s supposed to help people and teams establish a shared understanding of a system or a process or a concept, it just ends up looking really impressive and convincing you that the authors know a lot more about this than you do. It doesn’t help you much, if at all.

And as a CTO, CIO, or VP of Engineering, I don’t want to pay for crappy documentation. This particular document probably cost me between $32K-50K, and that’s just the tip of the iceberg… because it doesn’t account for the incremental costs of the people who will attempt to decipher it – which could be 10-100x more over the lifetime of that document. Although the person or team that wrote the 20-pager probably knows what’s going on (at least a little bit), the artifact itself is going to cost other people time and take them away from more value-adding tasks.

The sheer volume of information we’re required to wade through to gain understanding – without the assurance that it will lead us in the right direction, or even in any direction at all – is probably what’s led to the disease of devaluing documentation. 

A lot of managers think documentation isn’t value-adding, and shouldn’t be done, because… in most cases, people do it so badly that it wasn’t worth the investment in the first place.

Dear tech workers: can we fix this, please? I know it will take a whole generation to effect meaningful change, but… I’m ready to roll up my sleeves.

Make Strategic Alignment Actionable with Baldrige

Posted on by Leave a comment

It can be difficult to focus on strategy when your organization has to comply with standards and regulations. Tracking and auditing can be tedious! If you’re a medical device manufacturer, you may need to maintain ISO 13485 compliance to participate in the supply chain. At the same time, you’ve got to meet all the requirements of 21 CFR 820. You’ve also got to remember other regulations that govern production and postmarket. (To read more about the challenges, check out Wienholt’s 2016 post.) There’s a lot to keep track of!

But strategy is important. Alignment is even more important! And in my opinion, the easiest way to improve alignment and get “Big Q” quality is to use the Baldrige Excellence Framework. It was developed by the Baldrige Performance Excellence Program, and is administered by NIST.

In Is Good, Good Enough for You? Taking the Next Step After ISO 9001:2015, former Baldrige Program Executive Director Harry Hertz outlines similarities and differences between ISO 9001:2015 and Baldrige. After examining complements, Harry shows how Baldrige helps organizations grow beyond the conformance mindset:

I have not shared all the commonalities of or differences between ISO 9001:2015 and the Baldrige Excellence Framework. Instead, I have tried to show the organizational possibilities of building on conformity assessment to establish a holistic approach for achieving excellence in every dimension of organizational performance today, with a look to the strategic imperatives and opportunities for the future. Baldrige helps an organization take this journey with a focus on process (55% of the scoring rubric) and results (45% of the rubric), recognizing that great processes are only valuable if they yield the complete set of results that lead to organizational sustainability… I encourage organizations that have not gone beyond conformity to take the next step in securing your future.

Read More Here! –>

The Achilles Heel of Customer Journey Mapping

Posted on by Leave a comment

Journeying through western Wyoming in August 2011. Image Credit: me.

Achilles was that guy in Greek mythology whose mother, when he was born, wanted to protect him soooo much that she held him by the heel and dipped him in the power-giving waters of the River Styx — making him bullet proof (and much more; no bullets then), except at the heel, because for some reason she didn’t think about just dunking him a few inches deeper. Maybe she didn’t want to get her hand wet? Who knows. (In the research literature this is called perverse unintended consequences — it happens in business too. You try to make an improvement or protect against a particular hazard and oops, you made it worse.)

Customer Journey Maps (CJM)

I’ve been reading a lot about the Customer Journey Maps (CJM) technique used in marketing (see Folstad & Kvale (2018) for a fantastic and comprehensive review). It formalizes the very good suggestion that when you’re trying to figure out how to engage with prospects, you should put yourself in their shoes. Empathize with them. Figure out what they need, and when they need it. Then, identify how your company can not only meet them there — but connect with them in a compelling way.

CJM also goes beyond conceptual modeling. For example, Harbich et al (2017) uses Markov models to predict the most likely path and timing of a customer’s journey. Bernard & Andritsos (2018) mine actual customer journeys from sales force automation systems and use them in a Monte Carlo like way to uncover patterns. There’s even a patent on one method for mining journey data.

Benefits of Journey Maps

Annette Franz says that “done right, maps help companies in many ways, including to…

  • Understand experiences.
  • Design [new] experiences.
  • Implement and activate new experiences.
  • Communicate and share experiences.
  • Align the organization… get executive commitment for the customer experience (CX) strategy, get organizational adoption of the customer-centric focus, provide a line of sight to the customer for employees, and help employees understand how they impact the experience.”

But like Achilles, Customer Journey Mapping has a vulnerable spot that can wipe out all its potential benefits. (Fortunately, success lies in the way your organization wields the tool… so there’s a remedy.)

The Achilles Heel of CJM

Here’s the problem: creating a journey map does indeed ensure that you focus on the customer, but does not ensure that you’re focusing on that customer’s experience. Diagnosing Voice of the Customer (VoC) is hard [long explanation; shorter explanation], and there are tons of ways to do it! Through journey mapping, you may accidentally be focusing on your company’s experience of that customer throughout the stages of the journey. 

Diagnosing the Symptoms

How can you tell? Here’s a non-exhaustive list of ways to diagnose the symptoms, based on recent research and observing companies who do this since about 2009 (please add in the comments if you’ve observed any other ones):

  • Do you ever hear “How can we move the customer from [this stage] to [the next stage]?”
  • … or “How do we get more customers to join us [at this stage of the journey]?”
  • … or maybe “How can we get customers to [take this action] [at this stage of the journey]?”
  • Does your customer journey address differences in customer personas, or do you have a one-size-fits-all map? Rosenbaum et al (2016) says “We contend that most customer journey maps are critically flawed. They assume all customers of a particular organization experience the same organizational touchpoints and view these touchpoints as equally important.”
  • Do you systematically gather, analyze, and interpret data about what your current customers are experiencing, or do you just kind of guess or rely on your “experience”? (Hint: subconscious biases are always in play, and you’ll never know they’re there because they are subconscious).
  • Do you systematically gather, analyze, and interpret data about what your prospects would benefit from experiencing with/through you, or do you just kind of guess or rely on your “experience”?
  • Do you focus on ease of use over utility? (Just like perfect is the enemy of perfectly OK, easy can be the enemy of possible if you’re not careful. This often shows up in the journey mapping process.)

Like I mentioned earlier, this is definitely not a comprehensive list.

The Solution

What’s the solution? ASK. Ask your customer what they need. Find out about their pain points. Ask them what would make it easier for them to do their job. Finally, ask them if you’re getting it right! And even though I said “customer” — I do mean you should ask more than one of them, because needs and interests vary from person to person and industry to industry. Just interacting with one customer isn’t going to cut it.

Ask early, ask often! (As people learn and evolve, their needs change.)

Improving the Method

How can we improve the quality of customer journey mapping? Share your insights and lessons learned! CJM is a promising technique for helping organizations align around empathetic value propositions, but just like agile methods, it’s got to be applied strategically and deliberately… and then checked on a continuous basis to make sure the map is in tune with reality.

Improve Writing Quality with Speaking & Storyboarding

Posted on by One comment

For a decade, I supervised undergrads and grad students as they were completing writing projects: term papers, semester projects, and of course — capstone projects and thesis work. Today, I’m responsible for editing the work of (and mentoring) junior colleagues. The main lesson I’ve learned over this time is: writing is really hard for most people. So I’m here to help you.

Me, Reviewing Someone Else’s Work

If I had a dollar for every time this scenario happened, I’d… well, you get my point:

ME (reading their “final draft”): [Voice in Head] Huh? Wow, that sentence is long. OK, start it again. I don’t understand what they’re saying. What are they trying to say? This doesn’t make any sense. It could mean… no, that’s not it. Maybe they mean… nope, that can’t be it.

ME: So this sentence here, the one that says “Start by commutating and telling the story of what the purpose of the company’s quality management software is, the implementation plans and the impact to the current state of quality roles and responsibilities for everyone involved.”

THEM (laughing): Oh! Commutating isn’t a word. I meant communicating.

ME: Have you tried reading this sentence out loud?

THEM (still laughing, trying to read it): Yeah, that doesn’t really make sense.

ME: What were you trying to say?

THEM: I was trying to say “Start by explaining how quality management software will impact everyone’s roles and responsibilities.”

ME: Well, why don’t you say that?

THEM: You mean I can just say that? Don’t I need to make it sound good?

ME: You did just make it sound good when you said what you were trying to say.

What Just Happened?

By trying to “make it sound good” — it’s more likely that you’ll mess it up. People think speaking and writing are two different practices, but when you write, it’s really important that when you speak it out loud, it sounds like you’re a human talking to another human. If you wouldn’t say what you wrote to someone in your target audience in exactly the way that you wrote it, then you need to revise it to something you would say.

Why? Because people read text using the voice in their heads. It’s a speaking voice! So give it good, easy, flowing sentences to speak to itself with.

What Can You Do?

Here are two ways you can start improving your writing today:

  1. Read your writing out loud (preferably to someone else who’s not familiar with your topic, or a collaborator). If it doesn’t sound right, it’s not right.
  2. Use a storyboard. (What does that mean?)

There are many storyboard templates available online, but the storyboard attached to this post is geared towards developing the skills needed for technical writing. (That is, writing where it’s important to support your statements with citations that can be validated.) Not only does citing sources add credibility, but it also gives your reader more material to read if they want to go deeper.

Storyboarding

The process is simple: start by outlining your main message. That means:

  1. Figure out meaningful section headers that are meaningful on their own.
  2. Within each section, write a complete phrase or sentence to describe the main point of each paragraph or small group of paragraphs
  3. For each phrase or sentence that forms your story, cut and paste material from your references that supports your point, and list the citation (I prefer APA style) so you don’t forget it.
  4. Read the list of section headers and main points out loud. If this story, spoken, hangs together and is logical and complete — there’s a good chance your fully written story will as well.

Not all elements of your story need citations, but many of them will.

Next Steps

When the storyboard is complete, what should you do next? Sometimes, I hand it to a collaborator to flesh it out. Other times, I’ll put it aside for a few days or weeks, and then pick it up later when my mind is fresh. Whatever approach you use, this will help you organize your thoughts and citations, and help you form a story line that’s complete and understandable. Hope this helps get you started!

STORYBOARD (BLANK)

STORYBOARD (PARTIALLY FILLED IN)

« Older Entries