Tag Archives: tools

Productivity Hack: Thinking in layers

I just finished reviewing a colleague’s latest project. It is absolutely beautiful. It’s a collection of very pretty looking documents and forms that you can use to keep track of your professional accomplishments and portfolio. The idea is that each person can use it to cultivate more agency in the professional development process — and it will definitely help people as individuals achieve that goal.

So why would it make my heart sink? Because it’s perfect for one person (or a handful of people) to more easily manage an individual (and isolated) process, but will make it difficult for us to gain visibility into the collection as a whole. It’s a personal management tool, not an organizational management tool. What it won’t help us do is:

  • Search across 10s or 100s of portfolios
  • Scale to 100s or 1000s of employees
  • Keep the content relevant and up to date

So when I see this gorgeous looking thing, I feel sad: so much work went into this, and although it’s going to help solve one problem, it is going to create a maintenance nightmare. In addition, now we’re locked into a single UI and any change will require a ton of effort (and manual changes in each employee’s worksheet). How could we have avoiding painting ourselves into this box?

Thinking in layers is a habit I’ve developed from decades of working in software. By thinking in layers, you can create more maintainable, systematic, and repeatable solutions for solving operations problems. If we had solved this problem in layers, here’s what the solution components would have looked like:

  • Data layer – store all the data in CSVs, with one observation per row and one variable per column
  • Processing layer – a way to create, read, update, and delete documents, records or fields & perform calculations
  • Presentation layer – a way to display the data and make what the user sees pretty

(One of the reasons I love R Markdown is that it gives you a way to easily combine the processing and the presentation in a way that still doesn’t break the layers. If you want to change what people see, you change that in one spot in your Rmd, then re-knit.)

The moral of the story is: you can’t build a scalable system without layers. Think in layers.

The Trouble with Tools

This post is a collaboration between Eric Sessoms at MyCustomerCloud & Nicole Radziwill.

Everyone knows what a tool is. We use tools all the time, every day. Hammers to drive nails… cars to drive to work… glasses to read a book. Tools help us do stuff. They make our jobs easier, our lives simpler, and our existence more orderly. But we have to remember that tools only exist to help us achieve our goals… we humans are the real brains behind the brawn of our tools! And we have to figure out what goals we’re trying to achieve – or else we could inadvertently use our tools and technologies to just stumble about without making any progress towards our goals!

In the words of the political scientist Langdon Winner [1], “What matters is not technology itself, but the social or economic system in which it is embedded.” It’s the context of what you’re trying to achieve that makes a tool work – or fail miserably!

In customer service, the choice of tools is particularly context dependent. Want to build trust with your customers? Consider the context in which your tools will be used. For example, there may be pros and cons of implementing an interactive voice response (IVR) system. People like efficiency, and your company will love the cost effectiveness of being able to route its contact center messages to the appropriate person. But I know I can react with vitriol if I’m forced to “Press 1” every time I want the sickly sweet fake customer service voice to move me to yet another menu. And I know I’m not alone. Furthermore, I want to be treated the same way whether I contact a company over the web, or via Facebook, or by phone.

Quality depends not only on the features, performance, reliability and aesthetics of your product or service, but also on your customer’s perception of you – and that includes their perception of your experience as a company, the reputation of your company and brand, the truth of your advertising, the prices you set, and their individual expectations of what you will provide. In addition, their expectations will depend on HOW they feel you should provide the product or service.

The tools you use to provide customer service will help shape your customer’s perceptions. Choose them wisely!

[1] Winner, L. (1986). The whale and the reactor: a search for limits in an age of high technology. Chicago, University of Chicago Press, 19-39. Retrieved from http://zaphod.mindlab.umd.edu/docSeminar/pdfs/Winner.pdf

What’s the Best Quality System?

In the September 2008 issue of Quality Progress, a group of collaborators and I published “Starting from Scratch” to help people figure out how to approach the often-nebulous problem of how to launch a new quality system. Making sense out of the acronym soup of quality systems can be daunting, even though you have to wade through much more than acronyms: ISO 9000, AS9100, Baldrige, Six Sigma, Lean, Lean Six Sigma, systems thinking, complexity theory, and so forth.

Ron Marafioti commented online and said that when he was reading our article he “became livid in realizing that an article on quality systems written with one author from Wisconsin-Stout failed to draw the distinction of tools vs. philosophy; in other words, short vs. long term. What this article did do for me is highlight the short term view that Baldrige (a philosophy) takes time and therefore is not attractive in a short-term economy, while the focus in this economy is busy in fighting fires and looking for opportunities to capitalize on short vs. long-term gains.”

I was surprised to hear this, because I’m pretty conscious of both the distinction between quality philosophies and tools, and I know very well that “there is no instant pudding.” So I re-read what we wrote, and sure enough, we didn’t call out something in the article that was made very explicit in our notes preparing for the article – oops! That is:

  • Philosophies provide a basis for your organization’s core values and quality policy (e.g. Baldrige, TQM, Deming’s 14 points)
  • Methodologies provide skeletons for problem solving, and are often aligned with quality goals such as reducing waste or variation (e.g. DMAIC, LSSQTT)
  • Tools support those methodologies and help you identify the additional detail you need to carry out data-driven problem solving (e.g. QFD for linking customer requirements to technical specifications; VSM for breaking down how parts of a process contribute to the value it ultimately delivers)

The mission of the “Quality Systems Development Roadmap” that we positioned in the article (and that’s hosted in its entirety at http://qualityandinnovation.com/qs726) was to help people figure out the difference between philosophies, methodologies and tools. Ideally, an organization becomes familiar with the value system espoused by one or more of the philosophies. Then, it consciously selects the methodologies and tools that support specific quality goals – and this can differ from process to process. By making the concept of starting a quality system actionable, we wanted to illustrate the interrelationships between the philosophies, methodologies, and tools on a more practical level.