Eric Christiansen on Being CEO of a Deming Company – LeanBlog Podcast #18

Here is Episode #18 of the LeanBlog Podcast. My guest today is Eric Christiansen, the President of a translation services company, OmniLingua (more can be found here on their philosophy as a company, being a self-described “Deming Company.”) I was interested in talking with Eric about what it means to be a “Deming Company” and about their implementation of “wiki” tools (ala Wikipedia) for managing their standard work and process documentation.

If you enjoy this podcast, I hope you'll check out the rest of the series by visiting the LeanBlog podcast main page.

Note: The second half of this episode features Mike Micklewright performing in character as Dr. Deming, offering his best read of what Deming might say today. These are Mike's interpretations, not verbatim Deming quotes.”

Show Notes and Approximate Time, Episode #18

• 1:30 Introducing Eric and his company
• 3:15 What does it mean to be a “Deming company?”
• 3:40 The Deming System of Profound Knowledge
• 4:00 The owner of OmniLingua had worked directly with Deming and appreciated the people aspects of his philosophy, how do you treat people with respect?
• 4:40 Has the annual review been abolished? Sales commissions were abolished, as well as production bonus plans. OmniLingua has a company-wide profit sharing plan instead.
• 5:15 More examples of the Deming philosophy in day-to-day life, including long-term sole-source supplier relationships
• 7:00 Is there still internal competition?
• 7:45 “Are we hiring salespeople who can't sell?” by not having commissions
• 8:40 How have lean methods evolved at OmniLingua?
• 10:15 Standard work within the company and the evolution into the use of “Wiki” technology for standard work
• 13:30 How they modified the process to allow some additional revision and ownership control (after an ISO audit)
• 15:00 How did it work when everybody had access to modify the standard work documentation?
• 17:00 How many people have access to the different standard work documents?
• 19:00 With a Word-document based standard work, people wanted to fancy them up, Wiki keeps people focused on the content
• 21:30 Deployment started last November (2005)

If you have feedback on the podcast, or any questions for me or my guests, you can email me at leanpodcast@gmail.com or you can call and leave a voicemail by calling the “Lean Line” at (817) 372-5682 or contact me via Skype id “mgraban”. Please give your location and your first name. Any comments (email or voicemail) might be used in follow ups to the podcast.

Click here for the main LeanBlog Podcast page with all previous episodes.

Podcast #18 — Eric Christensen on Running a Deming Company and Using Wiki for Standard Work at Omni Lingua

Recorded November 2006, published February 19, 2007

Intro

Mark Graban: Hi, this is Mark Graban from the Lean Blog. This is episode number 18 of the Lean Blog Podcast for February 19th, 2007. This is an interview I actually recorded last November with Eric Christensen, the president of a company called Omni Lingua. They are a translation services company based in Iowa.

So they're not a manufacturing company, as we tend to focus on here in the blog, but I hope you'll find this interesting for a couple of reasons. First off, we're going to talk about what it means for Omni Lingua being a self-described Deming company, which of course comes from the philosophy of W. Edwards Deming. We're also going to spend some time talking about how they manage standard work using a technology called wiki. And there are some links on the blog about what that means and some examples of that wiki technology.

Eric, it's a real pleasure to have you here on the podcast. I appreciate you joining us today.

Eric Christensen: Well, thank you, Mark. I'm excited to talk to you about the different things we have at Omni Lingua, and it's an opportunity to talk more about you and what you do.

Introducing Eric and Omni Lingua

Mark Graban: Okay. Well, thanks. I'm wondering if you could start off by introducing yourself and also introducing your company, what you do, where you're located, and maybe some of your personal background.

Eric Christensen: Okay. Well, my name's Eric Christensen. I'm the president of Omni Lingua, which role I've been in since January of 1995 — well, I've been with Omni Lingua since 1998. Before then I was a globalization software engineer for the WordPerfect products, with the WordPerfect-Novell-Corel family.

Omni Lingua is a translation services organization. What that means is we take material that has been created in one language and we translate it — or we take software and help it convert to many different languages. If you've ever opened your manuals for your refrigerator or your microwave and you can't find the English, that's the work we do.

Mark Graban: Okay.

Eric Christensen: And the languages, because of our model, can range from typical ones people see like French and Spanish and German, to some very obscure Indian languages, and things like that. So we go find the know-how around the world where it exists.

As far as Omni Lingua's background: it's been in existence since 1980. Our current owner bought it in 1994, because he wanted to work for a Deming company, and he figured the only way to work for a Deming company is if he had purchased it and ran it himself.

Mark Graban: We'll definitely talk about that. Where's the company based out of?

Eric Christensen: Omni Lingua's headquarters is in Iowa, and we do have another office site in New York City.

What It Means to Be a Deming Company

Mark Graban: You talk about being a Deming company, and that was just one of the reasons why I wanted to talk today. I was wondering if you could describe what it means to you and Omni Lingua to be a quote-unquote Deming company, and how that ties into maybe some of the management approaches or practices you have, and how that ties into lean and continuous improvement practices as well.

Eric Christensen: Okay. What we mean by Deming company is really trying to base our organization, especially our management model, on Deming's System of Profound Knowledge.

The frustration our owner had before he bought Omni Lingua was that most people, when they would do Deming, as they say, really got into the control charts and statistical process control. But he understood — as he worked personally with Dr. Deming and studied him — that there's a big aspect to Deming's philosophy that deals with people, the psychology of people. It also deals with learning and knowledge. He felt those aspects were missing.

So as he took over Omni Lingua and brought this philosophy, he started implementing these ideas on how you treat people with respect. How do you motivate a staff, to bring out their intrinsic motivation — whereas most of the management models out there, a lot of it's extrinsic motivation, either through threats or enticements.

No Annual Reviews, No Sales Commissions

Mark Graban: So, just one detail I wanted to ask. Have you abolished the annual review, for example, within the company?

Eric Christensen: Yes. Yeah, we don't have annual reviews. The first thing he got rid of was sales commissions. Our sales staff is all on salary. He also got rid of the production bonus plan. Our company shares in a company-wide profit sharing. That's the same amount for everybody in the organization. It's really set up as a team effort. If we're successful, we share. If we're not successful, we all suffer.

Mark Graban: Can you give a couple of other examples of, maybe in day-to-day practice, how the Deming approach is applied?

Eric Christensen: Well, it's hard to pick out. One key area: we use suppliers, and we really have been moving towards Deming's philosophy of a single-source supplier. That's hard work, as Dr. Deming talks about, because you really have to create organizations that are working closely together, who have the same philosophy driving them.

We spent a number of years looking out in the marketplace to find suppliers, in Europe and in Asia, that would have similar philosophies. So as we built these single-source suppliers, what that means is we don't bid out work and competing things. We set up long-standing pricing structures. That means my staff doesn't have to spend a lot of time trying to figure out negotiations or who to use. They know exactly who to go to, how much we're going to spend with them, and they can just get the work done.

On our client services side, really, our focus we always take as long-term. That's hard to do, because a lot of times people just want to say yes all the time to clients. Sometimes you may need to tell a client no, because it's not good for them long-term. Or maybe something for our organization as well — that may be a threat to us. We really try to empower our service staff. Because they don't have the commissions or the incentives or the annual rankings to worry about, they can really deal with client issues and be open and honest with them in trying to solve those and make things better.

Mark Graban: Does that help employees being more open and honest with each other, with maybe some of that internal competition taken away?

Eric Christensen: I mean, there's still plenty of internal competition, I think, from the nature of the work. You have service staff and production staff kind of always competing. But it does take that element away. If you have a salesperson who's bringing in a large opportunity and they may not fit that client, and we want to bring another staff member to take it over — well, the threat of losing money is gone. It's more just talking about what makes sense for this client.

Mark Graban: So it might take away some of the dysfunctional competition that some companies might see with incentives.

Eric Christensen: Right. And as we hire our sales staff, that's always one of the things that we get pushed back on: “Are we hiring sales guys who can't sell?” Because they want to have salaries. So that's part of our hiring process. We need to find people who are motivated to do the selling aspects. And what we have found is, we find experienced salespeople who are tired of having to boost their sales 2% every single month, or meet quotas, or who have their compensation plans tweaked all the time.

The guys we have are very motivated, they're very experienced, and they want to do the selling. They want to do the relationship building. Now they don't have to worry about meeting these little games. They know their money's okay. They're going to get their salary, and they're free to work. It's amazing what they can do with that.

The Move Into Lean, From the Deming Base

Mark Graban: Let's shift into our discussion. Our primary topic today was going to be the use of a tool called wiki for standard work. Before going into that, I was wondering if you could talk a little bit about how lean methods have evolved within the company. Was that an offshoot from the Deming philosophy, or did you branch into specific lean or Toyota Production System type tools?

Eric Christensen: Really with us, we don't say we're a lean organization, by any means, and that's why we use the term Deming. But within the framework of that Deming philosophy, we're always out there researching and learning and looking at models and methods to use.

One of the things that attracted us — an area we work heavily in is the automotive industry — so we pay attention to what's going on there. We've read some of the books by Taiichi Ohno, some of his books. We've also read Jeffrey Liker's The Toyota Way book as well.

It really opened our eyes to some methods we could use for the production aspects of our work, which may seem strange for a lot of people, because we're a service organization. But when we looked at the way we have to process material for our clients, a lot of it can follow manufacturing methods. That's an area where we've really learned from Ohno. Some of the other books we've read, Jim Womack's book — that's just given us some ideas about how to do process improvements, organization, you name it. It's just another tool in our toolbox, is how we view it.

Standard Work in a Service Business

Mark Graban: Maybe if you can talk about the importance of standard work in the context of your production process, and how that evolved. What kind of standard work you have, and the evolution into the application of the wiki technology. If you can tell us how that evolved, and how the wiki technology is applied to standard work.

Eric Christensen: Okay. A lot of our work in the service arena, as you can imagine, deals with people-to-people interactions. But there is that component, as I mentioned before, that really gets down to how do you convert materials. Since 1998, our organization has really focused on taking the knowledge of how to convert material out of people's heads. A lot of times that know-how lives in project managers. We've really been working on ways to bring that information, to bring the processes, out of their minds and to codify it.

What this allows us to do is to grow our revenues without having to add more and more staff, which is a typical project management model. If you bring in another large-scale client, you have to add more project managers. And we've been able to not do that as we've increased our system know-how and through the documentation we use.

Mark Graban: So there's a certain productivity aspect that's come from standardizing some of the work methods.

Eric Christensen: Right. When I joined Omni Lingua in 1998, I had before then purchased translations. Now I was going to be a provider of translation services. The thing that shocked me was that if we had a project manager go out of town, that client's work would have to stop, because nobody else really had a feel for how that work would happen. And that's not a good service — to have to tell your client, “Well, you can order from us on these dates between these times.”

So that was one of the drivers behind standardization — again, to take this know-how out of people and put it into our system.

Why Wiki

We've historically used network space. It was easy for us, it was cheap for us, and we just write Word docs and put them out there. But the questions we started having, especially as we really started moving into the systematization of knowledge, were that Word docs get to be painful to update, and to define, and to catalog. One of our developers had been searching around, and he thought, well, maybe wiki would be a good way to do it.

It's a pretty easy interface. You don't have to spend much time training people. We could set up some standards. It's accessible. A lot of times we can work from our homes or we're overseas on travel assignments, and we can access it via the web. It just seemed like it offered the flexibility, yet some of the structure that we wanted for a standard documentation set.

So we piloted it last November, November 2005. Uh, with the basic deployment.

About that time, though, we got audited by a medical device company who's a stringent ISO 9000 shop. And it turned out to be really good for us. We're not an ISO company. We don't have interest in that certification process. But they gave us some good pointers about responsibility assignments, and kind of the ISO view of how you do version control and paper trails, and all that aspect to it.

Based on some of the feedback from this auditor, we modified the wiki system that we use to allow us to do these clear-cut responsibility assignments, have the appropriate process owner sign off, retain control — yet at the same time allow the flexibility to remain, to allow the people who are actually running processes day in and day out to modify documentation as they needed, and propose those changes.

Who Can Edit What: A Hybrid Model

Mark Graban: For listeners who aren't as familiar with a wiki system — you know, Wikipedia, probably the best-known example of that — is it true that you started off with basically all of the users being able to make edits? That's typically a core component of the wiki approach, that anyone who has access to that document can make changes.

It makes me wonder how you get feedback from other people. Typically you think of changing a standard work document as: one person has an idea for an improvement, maybe you run a pilot, you run that idea past others, and the group, or a supervisor, or everyone involved has some sort of consensus over whether the document should be updated or not. Was it a real free-for-all at first with the wiki, of having a lot of changes back and forth? How did you manage that?

Eric Christensen: It wasn't too much of a free-for-all. I think, because in our system for the longest time, we really preach — this comes from Deming again — about responsibility. We have process owners, and they have responsibility. So they were the main drivers of our documentation in the wiki.

We do have other staff members who participated, and it wasn't really much of a free-for-all, because they were already working that way, and had been for years, inside the Word documents. It was more of a matter of, when we had the ISO audit, making our clients feel comfortable that somebody's in control. That you don't have that ability to go into a free-for-all mode. And it also fit our philosophy — that really, those who have the responsibility for the process, in the end, should control the documentation.

So the modification we had to make to the wiki was, we basically took collection editors, and we made those the only people who can modify the actual documentation within the collection editors, which is our standard documentation sets. The actual process owners. But we do have an area that everybody else, including myself, if I want to make a proposed change to a process, I can copy a page from a collection into what we call our sandbox. I can make the modifications that I want to with it. I can sit down then with the team, I can sit down with the process owner, we can test it, we can check it out, we can see if it works. If it doesn't work, as you mentioned, build that consensus, which is so important. Then once consensus has been achieved, the process owner can take that page and move it into the collection, and it's done.

So that's the hybrid approach that we've taken so far.

How Many People Use It

Mark Graban: For a certain set of documentation, how many users, or how many different people working off of that standard process, do you typically have?

Eric Christensen: It really varies. We're in the middle of a big production change, which is going to open it up to our total staff — we have 40 people. So we'll have up to 40 people accessing certain process documents and following those. Other ones, it may be a combination of three or four people.

Some of this documentation set as well goes out to our suppliers, so they can see here are the processes that we're following. Then they can look at it and provide us feedback if our process is causing them pain. They can say, “Well, maybe you can change your process, and do this and this and that, and that will help us. So we don't have as much pain from your process.”

Mark Graban: With the wiki technology, one of the advantages would be working with people in virtual teams or different locations, and sort of facilitating some of that process. With professionals often in different parts of a business — the consulting organization I'm a part of, we have consultants and peers of mine all over the U.S. and over in Europe. One of the reasons, from a personal standpoint, wanting to learn about the wiki approach is wondering, how could we as a professional services organization apply that to some of the standard methods that we try to use as consultants?

Eric Christensen: Well, and the beauty of it too is, because it resides in a web server, sometimes if you're out on the road you can access the internet. Versus accessing a network space, you can see things, you can easily modify it.

We just found as well, because it really simplifies the document creation process — the issues we always ran into using Word or other documentation programs were that people tend to want to make these things all dressed up and fancy. They're using all sorts of different styles and fonts. Really with this approach, we can really limit the kind of tool set we want to be used. It keeps it simple and basic, easy to read, and keeps people focused on the content, which is an important aspect — not the actual document look and feel.

Hosting, Security, and Getting the Structure Right

Mark Graban: Do you have any general advice for people that might be looking to apply the wiki technology, as far as resources or software platforms to look at? And then maybe the other question, along with that, would be about security. You mentioned the internet. Can you have this hosted on internal servers that would be behind VPN or firewall access for people?

Eric Christensen: Right. For us, because we're a Microsoft .NET shop, we found an open-source application that works with .NET. I know of others that are using Linux versions and things. They all seem to be basically the same functionality to it.

The biggest hurdle we really had to overcome was how to take our network infrastructure — because there's a certain way you'll organize your material on a network — and how to organize that material using the wiki, and what strengths the wiki could bring. That was really our biggest challenge. How to create our collection editors, and how to — if you have documentation, for instance, that goes many levels deep, how do you want that to behave within your wiki system?

So spend the time planning that. When we first deployed, we were just playing with the technology. We just thought, well, we'll just take our network structure and slap it into the wiki format. Didn't quite work that well. So we spent some time going back and deciding how do we want the documentation to work. The beauty of wiki is the ease to link to documentation and information. You really need to get out of that mode of hierarchical structure as far as network and storage locations — to accessing information. That's really the power of wiki. It's easy to link to know-how and information.

A Couple of PDCA Cycles

Mark Graban: It sounds like, in true Deming style, you went through a couple of PDCA cycles of learning how to apply that technology for what you needed it for.

Eric Christensen: Yeah, that's right. Like I said, we started deployment last November in a testbed format. We went through a couple of different iterations over the spring of this year before we finally solidified, I think, in July or early August. We finally got a feel for how it works and what we want to do with it. So kind of September was our kickoff date, as we're now really using this as our documentation standard system.

Close

Mark Graban: Well, good. I appreciate you joining us today, Eric. I think it's a really unique cutting-edge application of the technology for standard work, and I appreciate you sharing your experiences with that, and a little bit of insight into what it's like to really try to live as a Deming company. It's really interesting stuff, so I appreciate it.

Eric Christensen: Oh, you're welcome, Mark. Glad to talk with you and share our experiences.