When Harold Leavitt coined the phrase people, process, and technology in his 1964 paper, Applied Organization Changes in Industry, he never imagined how often it would be used in identifying the key components for business success. However, many companies focus on process and technology as the two primary components with not enough emphasis on the people component. An IBM study supports this premise stating that that business transformation initiatives ignore the people aspect of the change initiative.
Fast forward to 2019 and Drew Saur, CIO at The Palmer Family of Companies, which includes G&C Foods in Syracuse, NY; Palmer Food Services in Rochester, NY; and Palmer’s Direct To You Market in Rochester, NY. At the Palmer Family of Companies, Drew’s teams are using tools like artificial intelligence and machine learning to help these food companies achieve new levels of achievement in the digital age.
Although Drew’s professional résumé is heavy with technological accomplishments, his degree is in rhetorical theory, which is the classical, philosophical study of communication and persuasion. Wherever he works, his focus is on creating and strengthening the relationships between engineers and their customers by concentrating on aspects of empathy and trust. He is a regular guest lecturer at the Rochester Institute of Technology, where he speaks to software engineering seniors and graduate students about this topic.
Drew has a unique perspective on the people, process, technology formula and I had an opportunity to meet with Drew to discuss his philosophy and how he applies it to help people perform beyond their capabilities. Following is an excerpt from our conversation.
Phil Weinzimer: Drew, we often hear about the People, Process, Technology as integral components for successful transformation initiatives. I know you have an interesting perspective on this. Could you share your insights on the importance and linkage of each component?
Drew Saur: Well, this triad is as old as the hills, and any CIO worth his or her salt knows that it defines an order of operations. The bulk of my leadership history is as a CTO, and when I look back at the successes I had in those roles, it all comes down to an emphasis on people and their processes and pulling in the reins on technology until there is a very deep understanding of the first two things. As a CTO, your success depends upon superb requirements elicitation, and only through a deep understanding of people and their situations can you begin to identify appropriate and agreeable processes that technology can support.
Do you recall the days of OpenDoc and OLE in the mid-1990s? A lot of intellectual engineers thought it would make more sense to have data—distributed on individual PCs—that could be shared across those PCs as needed, rather than centralized. I remember thinking: how are everyday people supposed to perceive the relationships with the data they need? Yes, there are a handful of places where ActiveX is still useful for Microsoft Office power users, but most people don’t share data that way. Luckily, the Internet happened, and the idea of (generally) centralized data eclipsed those engineers’ dreams. Why? Because everyday people came first, and everyday people shouldn’t have the burden of thinking about data in intellectual ways.
In many companies, people still look at technologies—even generalized ones, like AI—and then try to envision ways to apply those technologies. I believe that will never be as effective as looking at business problems first and identifying processes that can be employed to make those problems less burdensome. We have to remember that all software does is make it easy to perform repetitive tasks (processes!). Some repetitive tasks can be combined to profound effect—e.g., robotics—but that is all they do. Technology is a means to an end, and not an end unto itself.
PW: What are the key attributes and best practices CIOs could use to measure the maturity of your People, Process, Technology model?
Identify all people: Ensure that you are considering the entire set of people who are affected by your problem and its possible solutions. It is easy to overlook people who have to deploy and support your solution, so never forget them!
Look at the whole person: Employing empathy, consider not just what you know, but what you might not know. Does the person hate their boss, possibly have depression, or have other personal issues that might prevent their complete immersion with you?
Trust as a goal: What do you need to do to develop a long-lasting, trusting relationships with the people who are asking you to solve their problems?
Think in business terms: Work with businesspeople to articulate their problems and processes as Agile User Stories, whether you are working in an Agile framework or not. Try your best to leave technology out of the stories. Think functional requirements, not technical requirements.
Think like a systems engineer: Look at your business as a system of systems, and study the great work of Richard Turner and Rose Opengart at NASA (https://www.nasa.gov/pdf/291037main_10.5.5_APPENDIX_MARSHALL.pdf) to drive cross-departmental understanding and compromise.
Measure: When you define or refine a process, how will you measure its success/ROI?
User experience: Will your chosen technologies provide a UX that honors the people being served by it? Are the solutions approachable by everyday people? Responsibly performed UX testing is required.
Flexibility: Do your chosen technologies provide a degree of flexibility that reflects the changing needs of the people served by it?
Obscure the complexity: Is the end product deceptively simple enough that it hides—where appropriate—underlying process complexities that would normally cause angst?
PW: What are the important next steps CIOs should take to improve the maturity of their IT organization’s People, Process, and Technology competency that lead to a more effective and efficient IT organization that enables business success?
DS: There following five key areas will help CIOs improve the maturity their IT organization’s people, process, and technology competency
1. Change the dialogue
Let people across your business—from top to bottom—know that you want to change the dialogue, and that we will not talk about technology, but that we will focus on people and process before everything else. This is a change and might take you months or even years to complete it. It cannot be rushed any faster than the people you are working with can handle.
2. Vendors can distract your focus
Stop the temptation to look at vendors when they approach you for business out of the blue. Tell your business colleagues, inside your department and out: We are presented with tempting technologies by vendors every day. New vendors add risk and complexity to our business. If a vendor poses a technical solution to a problem that we have not been working actively to address, we will ask ourselves, first: Why have we not been addressing it? And, second: What other opportunities do we have within our capabilities to try to address this issue before forging a relationship with a new vendor?
3. Focus on empathy, trust and emotional Intelligence
Ensure that all of your technology team members develop a deep understanding of these three things: empathy, trust, and emotional intelligence. The ability to empathize…to develop trusting relationships…and to know how to act in stressful situations is foundational to eliciting honest requirements from real people.
4. Think big picture
Require your teams to shed their engineering mindset when eliciting requirements. Software engineers have to stop “thinking in code” and IT people have to stop “thinking in hardware and software.” I encourage my teams to avoid the terms “users” and “end users” whenever possible. These terms imply a class divide. Arguably, our industry has adopted these terms to help us empathize with people who we are not. But I find that to be an incomplete thought. It’s a very condescending concept when you think about it. We are all people, and we share similar limitations. If we are solving problems, and we create an “us” versus “them” scenario, we are really not putting ourselves in the same bucket as our customers. Some people will say to this, well, if I create something that works for me as an engineer, it will not work well for a non-engineer. I say: don’t create something that works for you as an engineer. Create something that works for you as a non-engineer. If you cannot get in touch with your inner non-engineer, then I believe you have further personal development to do!
5. Establish a culture of “honoring the human condition”
This means that we should do everything possible to avoid projecting technology artifacts onto our customers. It should become the foundation for every decision your team considers.
One of my past engineering teams developed mobile applications for nurses. Nurses are special people…it takes guts to do what they do. They deal with humans at a primal level. They cannot be expected to be passionate about technology for the sake of technology. This team thought deeply about how nurses would feel when requiring tech support. “An error popped up on my screen!” “What did it say?” “I don’t know, some kind of error about connection to the server.” “Do you recall more information?” “No.”
To address the human condition, instead of a textual error message, the team presented a humorous and memorable image to the nurse. The nurse would call up and describe the image—with a laugh!—and our team knew exactly how to start investigating the issue. This is better for the nurse and the tech support person. That’s the simplest example of honoring the human condition I can think of.
I believe technology has made many things worse. What once were simple transactions are now as complicated as it once was to open a bank account. Yes, businesses have lots of data, but at what expense to customers? Recently, I bought several pairs of socks at a major department store. Each pair had to have a barcode sticker applied, which was scanned, ostensibly so that I could later return the item without a receipt.
During checkout, one of the pairs didn’t have a UPC code; chaos ensued. The clerk called a manager, who tried to look up the socks to get their price. We ultimately found the price using my cell phone. The whole transaction was restarted. New return barcodes had to be placed over each of the old return barcodes, scanned once again, and I finally took possession of my socks…20 minutes later.
I’m betting that you are thinking where you would buy your own socks online instead. But I’m also betting it’s a not a list of hundreds, or even tens, of places. It’s probably one or two. Good experiences should be commonplace; we have a very long way to go. Paying better attention to people will help us get there.
This article was originally published at CIO magazine.