I hope that you and I together can find some humor in the size of the list of things that many human beings consider necessary. After all, it’s not our fault; these many things were deemed necessities long before you or I were born. We even have a word that we use to describe this world of necessities, in contrast to the world of wild animals we’ve been reflecting on together:
Civilized.
How do you feel about being civilized?
From your very seat, it might seem that there are three answers to this question:
a) “What are you talking about? I do not live anywhere near your first world!”;
b) “I am glad to be!”; or
c) “I resent this complicated life and wish to live a simpler one.”
Many of you will fit into the latter two categories. If so, I think that there is another position you can consider:
d) “I understand that this crazy world I was born into was crafted without my input, and I can live within it while looking for opportunities to appreciate its follies with a sense of humor.”
You do believe life is filled with follies, don’t you?
Please take a leap with me: Let us consider our work — no matter how proud we are of our accomplishments, no matter how highly developed or professional we may be — to be one of those follies.
If you work, or have worked, you may tell me that thinking of work as folly is itself folly. But: I am not asking you to stop working. Your work is one of your predetermined necessities; a true folly would be to attempt to change this. But what I am asking you to do, at least for as long as you are with me on this written journey, is to think about it as something that is artificial.
Now may be a very good time for you to reflect on your previous musings as a wild animal.
This is the fifth and final part of a thought exercise that leads to the introduction of The Progressive CIO’s tenth foundational value, whose formal introduction will occur in my next post. Little did I know what a tease this all would be when I promised to unveil value number ten back in December of 2024. What follows was incredibly difficult to write; I’ve been working on it for a year. The 8-bit computing detour I recently took, thanks to John Gruber (1, 2, 3), provided precisely the distraction I needed to get the rest of it all to snap into place.
This fifth part happens to stand on its own, but I suspect you will enjoy it even more if you read it in the context of its predecessors, starting with Part I.
A hearty thank-you to Charles for his constant support and always-inspiring insights, to Karl for his contributions to this piece’s final refinement, and to both of them for confirming that what was once only in my head actually makes sense in this form.
Let’s explore the notion that the bulk of what we call “work” today — the work that involves the formality of commerce, companies, positions, titles, interviews — is artificial. That is, it’s not part of the natural order of things; it’s an artifice, something made by humanity itself, an artifact of human development.
Other animals work, but how is their work different from ours? Through our limited vision, the work that non-human animals do distills down to finding and retrieving sustenance, avoiding harm, and reproducing. Let’s look at the daily work of a deer:
Early morning:
Grazes on grass, leaves, or shrubs
Senses for danger while chewing thoughtfully
Mid-morning:
Wanders to a shadier spot
Stares into the distance, wondering things unknown to us
Afternoon:
Lies down in tall grass, digesting food
Occasionally flicks an ear at a fly
Evening:
Grazes some more
Cautiously visits a water source
Night:
Sleeps lightly, ears twitching at most every sound, moving around now and then to feed in the safety of the dark
The life of a deer — and many other animals we can think of — resembles the life of a retiree more than the life of a worker.
There are other creatures — many species of ants and bees come to mind — who, by all appearances, have a distinct and full-time work culture that does not at all resemble a retiree’s life. It’s curious that human work life more or less mimics the work life of creatures we often consider lower forms of life.
Is the life of a worker a requirement of the human condition? There are human societies whose lives more closely resemble those of deer, so the answer cannot be a simple “yes.” Many major religions, however, believe that work is an essential duty of the human experience (e.g., the Calvinist work ethic, or Laborem Exercens in the Roman Catholic church). With a great deal of work philosophy rooted in religion, this is no simple issue. There have been many others who have offered counterpoint to that notion; here are a few good starting points if you are interested:
Henry David Thoreau, “Life Without Principle”
Bertrand Russell, “In Praise of Idleness and Other Essays”
Bob Black, “The Abolition of Work and Other Essays” (There’s also a thought-provoking video where he shares his perspective.)
David Graeber, “Bullshit Jobs: A Theory”
I happen to enjoy thinking like this very much, but I am not here to try to convince you to drink from this cup. What I think is more reasonable is to acknowledge that many of us have decided to work — or feel we must work — and it’s helpful to identify what’s important and not-so-important about that work. Through work-as-we-know it, we sacrifice certain aspects of life to gain something in return. If I could distill what we think we have obtained through this sacrifice, it might be:
A feeling of stability or predictability
A feeling of progress in our control over nature, increasing our comfort and safety
Status
Yet:
As for stability and predictability: when we compare ourselves to deer, how do we appear to be doing?
As for our control over nature and our comfort and safety: aren’t we still subject to nature and disease, as well as the dangers of violence, automobile accidents, and many other similar things?
As for status: arguably all other animals have status hierarchies — are ours all that different, or are their particulars just more familiar to us through experience, exposure, and habit?
If you could be born as anything other than a human, you would not have commerce, or job interviews, or currency systems, or all the trappings of the work world as we know it today. You would simply live, as simply as one could. Your life would be quite a bit like the life of a retiree, for your whole life. Of course, you would have no medicine, no television, or many other things. You would eat simple things, shelter yourself, and largely live — until you don’t. I’d wager that many people would say this sounds unproductive, and that might fall at odds with those for whom work is a key part of their belief system, religious or otherwise.
But is that truly unproductive? If I were to propose that “productive” means something resulting from our actions that can be used to bring benefits to ourselves or others, deer are productive, aren’t they? Would it be terrible if our productivity were limited to benefiting ourselves and our families and nearest neighbors? Things were certainly more like this in the pre-industrial era. Ponder pre-industrial farming: we tend to think of working from home as a new concept, but working from an office is a far newer concept. In other words, somewhere between the pre-industrial era and today, there was a significant change in our human notion of productivity. That should help us see that what we have today is a result and not a requirement. This is why I think it’s helpful for us to consider our work — as we know it today — as something artificial.
All who work share one experience: a divide between what is considered work, and what is not. We are programmed to believe that the height of work — productive work — is time spent working directly with some artifacts, developing solutions to problems.
For a moment, I’d like you to create two lists: one that contains examples of things you do or encounter at work that you consider productive, and another that contains examples of things you do or encounter at work that you consider unproductive.
I thought it might make sense to ask this question to ChatGPT, which is at its best when summarizing things that are statistically ordinary. Here’s the response I got:
Sure! Stepping into the shoes of an average office worker—let’s say someone in a mid-level role at a typical company—here’s how I might think about productivity on a daily basis:
Productive things I do or encounter at work:
Knocking out a clear to-do list
Finishing a presentation ahead of a deadline
Solving a problem for a client or teammate
Having a focused, decision-making meeting
Getting uninterrupted time to work on a project
Learning a new skill that helps me work faster or better
Collaborating with someone and making real progress
Automating a repetitive task that used to eat up time
Unproductive things I do or encounter at work:
Sitting through meetings that don’t lead to action
Answering endless reply-all email chains
Re-explaining the same process over and over
Waiting on approvals that stall my progress
Searching for information in a cluttered system
Fixing someone else’s sloppy or rushed work
Responding to Slack messages that derail my focus every 5 minutes
Doing work that gets scrapped or ignored
Let’s take a look at a few curious statements I’ve heard many times throughout my life, as I am sure you have as well:
“I was busy with my work, but then she came in to ask me a question.”
Why is it that people distinguish their inward work from the notion of being interrupted by others? Isn’t that just as much work as anything else we do? Is this supposed to mean that answering questions isn’t part of our work?
“I had to stop my work so that I could attend a meeting.”
Why is it that meetings are set apart from inward work as if one is inherently more important than the other? People hate meetings that are “unfocused.” But the work we do at our desks can be just as unfocused. Is our hatred for meetings really just a hatred of accommodating others’ present needs that are different than our own?
“Let’s stop talking, and get to work.”
Why is it that hallway and “water cooler” conversations are considered a waste of time? Is connecting with humans on a human level truly a waste of time?
Now, let’s look at our assumptions from a different viewpoint:
Has every great thing you’ve ever done started life on a to-do list?
Have all the best moments of your presentations been planned in advance?
Have you ever found value in a meeting that didn’t have a plan or agenda?
Would you say that interruptions are universally bad? What value do they bring for the interruptor?
Have you found that fast work is generally better work?
Have you ever learned anything from repeating a task multiple times?
Have you ever seen a benefit come from re-explaining — or even re-asking — things?
Have you ever found value in the fact that you’ve had to wait for an approval on something?
Have you ever found unexpected benefits from going down ratholes when doing research?
Have you ever learned anything valuable when you’ve had to fix the work of others? Has the other person found value from it?
Have you ever found value from producing work that you’ve had to scrap?
If your answers to any — or like me, all — of these questions fall at odds with prescriptive productivity, then what on earth drives us so hard to avoid and even actively resist these things? I think the answer is: expectations (meaning: premeditated resentments, a.k.a. “goals” or “deadlines”) your employer — and its customers — have that make it feel like a luxury to look at the world in such an inverted way. But if this inverted world helps us produce something better for those customers, then what’s wrong with that?
If your answer is, “My bosses don’t view it this way,” then you’ve just identified the root cause. Good bosses understand that people are more important than mere work. If productivity means something resulting from our actions that can be used to bring benefits to ourselves or others, then how can it be any other way?
Because there aren’t as many good bosses as we all need.
Is that natural? Well, it’s certainly real.
Given the state of things – that work-as-many-of-us-experience-it is FUBAR…er…artificial…a useful approach is to think if it a little more like a board game: less seriously.
If you compare work to a board game, you might find many similarities: each has a set of rules (that I suggest are identically artificial) and players (who I suggest are identically natural) and stated goals. The only difference — unless you are a professional board game player — is in financial compensation. But why do we make money on one and not the other? Because the one that makes money is the one that isn’t merely “fun” or “easy.” If it were those things, we wouldn’t get paid. Work is very much like a game that happens to be hard enough to make people pay us to play it. What makes it hard is that some aspect of it has to have enough value so that customers pay for it.
Other than that, there is no difference between work and a board game.
None.
You may think I am making light of the most serious occupations, such as surgery. Surgery is a wonderful achievement. Despite its status as something valuable and profound, though, it cannot be considered a peer necessity of things like food and respiration. Surgery is an artificial luxury, a privilege to receive, and certainly not natural. It did not even exist as a successful practice for humans until fairly recently, and it’s not something other animals provide for themselves at all. But it is not the vocation that I am suggesting might do well to be taken less seriously. It is the workplace scaffolding around the vocation: the titles, the politics, the lawsuits, the insurance and all the tortured levels of commerce that contributes to the occupation’s status as something more of a game than the elegant dignity of the vocation itself.
Perhaps right now you are beginning to see why I think work as we know it is artificial.
Why does this matter?
When we can absorb the fact that work-as-we-know it does not, by any laws of nature, have to look like it does today, we stand to gain perspective on how and when we allocate our energies to it.
If we live like earlier versions of ourselves, we lose advancement and privilege, but we gain simplicity and time to behold the world around and within us that is natural.
The notion of work-as-we-know it is a choice made by human beings in the distant past. It might appear that we have only two personal approaches to that choice:
Hop on for the ride and live like those around you, doing exactly what they do, lemming-like.
Run screaming from the work world and try to live more like a wild animal, “off the grid.”
But there is at least one — interesting — third choice:
Hop on for the ride, with an ability to laugh about the silliness that exists within.
We take things that do not have to exist as rote, and we spend a lot — of time, effort, and resources — on those things. We take our work selves too seriously — our person selves, not seriously enough.
Thanks to Charles, Karl, Daniel, Frank, Reggie and Lori for all their input on this post along its journey. Please don’t miss the five-part thought exercise that leads to this piece.
Many decades ago when I was a boy, I found myself caught in a rip current on the Atlantic shore of Fire Island, in Robert Moses National Park.
Invisible hands softly took hold of my legs and dragged my body under. I resisted with panic energy, gaining enough control to catch a breath, only to be pulled under again. I shimmied in every productive way I could to escape the grasp. Another breath, another pull on my body, each time deeper into the churning salty olive murk. After a few cycles of this terrifying experience, a lifeguard caught hold of me and swam me to shore.
This was back at a time when we didn’t call people heroes for doing their jobs. The lifeguard accompanied my frazzled frame up the sand to reunite me with my father, who had dozed, sunning himself. As he reconnected us, I am sure there was nothing much more than a “thank you” and “you’re welcome” exchanged (I vaguely remember the word “undertow” used as part of the explanation, but we know today to use the term rip current), and all three of us went on with the day.
When recollecting this event, I find myself smiling about the lack of drama and sympathy that would accompany something like this today. More critically, though, I learned sometime afterward that my instinctual response almost killed me. Those who are better-educated than I was back then know this: when encountering a rip current, if you are a skilled and strong swimmer, you can swim parallel to shore to escape it. But if you are more of a wader, like I was, a “flip, float, follow” strategy will save your life: flip on your back, float, and follow wherever the water takes you. Even though you may wind up further away for a bit, you won’t drown, and you will save your precious energy until someone with skill can rescue you.
Float.
Always remember to float rather than fight.
Things that nearly kill us have a way of shaping our most primal principles.
•
As a leader, whenever I hear people use words like “concerned” or “worried” in regard to things at work, I like to pause the conversation and note: those words should be best saved for people rather than things. We should be concerned or worried if a coworker or a customer has cancer, or if their loved one is in the hospital. We should be worried when someone is summoned to the emergency room to meet a loved one who was in a car accident.
But if a report is late or a deliverable is overdue, unless someone’s life, health or livelihood is at stake, “concerned” and “worried” should not be in our vocabulary. (If only your livelihood is at stake, but your customers livelihoods are not, that may be an sign of work-as-artifice.)
Before today, there were nine foundational values of The Progressive CIO:
Exhibit vulnerability so that others feel more comfortable exploring their fears and weaknesses with you.
Exhibit humility to remind others that we are all small creatures in a large universe.
Spend as much time empathizing with those you serve so you can better understand them.
Continually refine your skills with patience; good things take time, especially when it comes to developing people.
Show compassion by actively stepping out of your own comfort zone to help others when they are down.
Be truly curious; ask questions about everything, with the mind of a child.
Endeavor to make only the commitments that you can keep; then keep them.
You will struggle often, but develop a willingness to do the things that you know you need to do, even if you are uncomfortable doing them.
Love is the most important thing in our lives. While co-workers might not love one another, we must do our best to honor the love that each of us has, and help one another tend to that love.
We should be vigilant about taking anything negative at work so seriously that it comes at the expense of any of the above. I call this buoyancy, and it is the tenth and final value in our arsenal.
Float.
Always remember to float rather than fight.
Buoyancy at Work
Here’s one of my favorite quotes, however dated in its “maleness”:
The man who is worthy of being a leader of men will never complain about the stupidity of his helpers, the ingratitude of mankind nor the inappreciation of the public. These are all a part of the great game of life. To meet them and overcome them and not to go down before them in disgust, discouragement or defeat—that is the final proof of power.
—William J. H. Boetcker
This is a man who understood the “game” part of life.
Here’s something I’ve seen many times throughout my career: a bunch of folks on our team have been stewing on a topic, and then eventually someone comes to me to, well, share this information in the hope I will commiserate. I say something to the effect of: “Why are you making such a big deal of this? Why does it really matter? Don’t waste your energy.” Or something like that.
That might seem dismissive, as if I don’t care (I might not, but that’s not always the case). I respect everyone’s need to have their unique feelings, yet I am incredibly sensitive to energy waste. Most of the time, I find complaining indulgent. I admit that I like to do it myself from time to time; it can feel good, and sometimes it helps us work through our fears. But I have found, more often than not, that once vocalizing our complaints has finished helping us work through those fears, excess complaining doesn’t accomplish much more than catharsis. The energy we have available to us at any given moment is limited. Doesn’t it make more sense to use that energy for things that can bring about positive change?
I hope that, after traveling this far together, you and I agree that work is not the point of life. If we do, then why do we allow our emotions about work to consume so much of our energy? Work winds up being important to most of us simply because it is the means through which we fund the rest of our lives. We understandably want to be sure that something that takes us away from the rest of our lives is not a drag. Our energy is well-spent figuring out a way to make work not a drag; stewing and complaining are not pathways to that.
This is why, when we teach leadership, we talk so much about emotional intelligence. Buoyancy is, to me, the most powerful distillate of the sap of the emotional intelligence tree. It reminds us to laugh at ourselves. It reminds us that people matter more than things. It reminds us that much of work is silly artifice, created without our input or control. It reminds us to be light of heart and to remember our shared humanity. Through buoyancy, we let go, to get to what really matters.
In that sense, buoyancy plus willingness equals agility. Which is to say: agility is when we combine an ability to flow and let go with an ability to work with our fear to try something new.
Float.
Always remember to float rather than fight.
Simply Put
There is a simple elegance to buoyancy:
Learn to let things go, lest they drag you under.
Try to have a sense of humor, and lighten your heart. It’s not always possible or appropriate, but with practice, you will be surprised at how often this becomes possible if you remember how much of our work is artificial.
Keep perspective. People matter more than things and work.
Ask yourself: what other values (Vulnerability • Humility • Empathy • Love • Patience • Compassion • Curiosity • Commitment • Willingness) can rescue you from the riptide?
Yes, the nine other foundational values we discuss here are tools to employ when your buoyancy needs a boost. But you cannot access the other nine values if you’re sinking. Buoyancy comes first.
There’s not a word I would change today. I’m still not mesmerized by generative AI. I still believe it helps with many perfunctory tasks — increasingly so. The world has quickly come to see how much of our existing work is perfunctory. We are at least a little worried about that, yet we still should not be, because there is so much truly original work that lies ahead, and there is still much human work to do.
Earlier this year, I was fortunate to meet Dr. Pramod Khargonekar, Distinguished Professor of Electrical Engineering and Computer Science at UC Irvine. He presented at RIT on the topic of “Advancing AI Innovation and Education through University-Industry Collaboration” and cited a paper from Erik Brynjolfsson called “The Turing Trap: The Promise & Peril of Human-Like Artificial Intelligence.” Dr. Pramod shared this profound diagram from Brynjolfsson’s paper:
That light green area prompted a lot of well-educated minds to behold in wonderment and nod in agreement. As with all technologies, AI stands to help us more than it stands to replace us. I couldn’t have said it better in ChatGPT Challenges Us to Focus on Better Things. Are We Up for It? if I tried.
It seems to me that the profession I serve is a poster child for the implications of generative AI. What you might not suspect, however, is that it epitomizes our misunderstandings about the current state of many professions.
As I write this in August of 2025, we are nearly three years into the popular era of generative AI. A large percentage of students and professionals are using these tools daily to write, or help write, software. Given a reasonably good prompt, the 2025 wave of LLMs produce reasonably good software for many things. This has caused a wave of concern about the future of the software engineering profession.
But software engineering isn’t merely about code…any more than civil engineering is merely about concrete, asphalt, soil, or water…any more than mechanical engineering is merely about materials, motion, or force…any more than electrical engineering is merely about diodes, capacitors, resistors, or transistors.
It seems like the right time in our journey together to recall a key moment from the 1997 essay, The Road Less Traveled: A Baccalaureate Degree in Software Engineering by two of the founders of RIT’s first-in-the-nation undergraduate program in Software Engineering, Michael J. Lutz and J. Fernando Naveda:
As industry demand for qualified software engineers continued to grow, it became increasingly apparent to us and to others that the goals of software engineering and computer science, while similar, are distinct. Computer science’s fundamental concern is with the development and analysis of algorithms and data structures, or with applied research into a small set of traditional areas: languages and compilers, graphics, operating systems, databases, networking, etc. In all these instances, the focus is on the fundamental principles, rather than on the systematic application of the principles to industrial and commercial problems. The split is similar to that between physics and traditional engineering: physicists, even applied physicists, are primarily interested in understanding phenomena. Engineers are interested in capitalizing on this knowledge to design new, useful artifacts for the benefit of clients.
Does AI help or hinder a software engineer’s effort “to design new, useful artifacts for the benefit of clients”?
Let’s reflect:
Civil engineers have been using building information modeling (BIM) and parametric modeling for since at least the 2000s.
Mechanical engineers have been using topology optimization software since at least the 1990s.
Electrical engineers have been using automated printed circuit board layout software since at least the 1990s.
The usual rationalization for continued human relevance in the face of new technologies adopted by engineering fields is that human judgment is required to review the output of these tools. Industry leaders offer that software advancements allow engineers to do what we do best: push frontiers in innovation and creativity without having to spend non-value-added energy trudging through rote tasks that computers can do more quickly and reliably.
But that’s the boring and easy defense.
The reality is that all professional fields serve human beings, and human beings have a few interesting behaviors that computers do not:
Let’s take a look at the “themes” of the Software Engineering program as articulated in The Road Less Traveled:
Professionalism. Graduates of the program must acquire the skills, habits, and abilities that characterize professional engineering practice and that define professional quality work. Included in this category are: written and oral communication, adherence to specific standards, responsibility for professional growth, and ethical professional behavior.
Team-based development. While team-based development is at the heart of modern software engineering practice, we realized it was impossible to teach team work simply by lecturing in class. Instead, students must be given ample opportunity to practice team skills in many different settings. Team issues are part of every class, and most require at least one project done by teams.
Software design. A primary engineering concern is design: Using one’s expertise to create a system that meets the needs of a customer. Several of our courses focus on design methods, design tradeoffs, common architectural patterns, and methods for design analysis and evaluation. We are careful to emphasize many design qualities, including testability, modifiability, reusability, and maintainability.
Software evolution and maintenance. Given the enormous cost of development, software systems are rarely developed from scratch. More common is the need to modify existing systems. To drive this lesson home, many of the projects, especially in upper-division classes, will require students to modify and enhance existing systems.
Complexity management. Modern software systems are complex, often as a direct result of the flexibility inherent in the software. We intend to expose the students to issues of complexity, and the various principles and techniques that have emerged in response to the need to control complexity.
Standards. Software engineers, like any other engineer, must conform to standards for both process and products. Our courses are designed to introduce the students to relevant standards, whether these are legally mandated, defined by industry groups, or simply de facto standards enforced by convention.
Process issues. We reinforce the concept that, software development is most likely to succeed when undertaken in the context of a defined controlled, and managed process. This notion is reinforced throughout the course sequence.
Well-designed things have a way of becoming more evident in their thoughtfulness over time, and these themes are no exception. It is difficult to imagine how their importance in the software engineering profession will be diminished by AI.
Team-based development also shows no sign of being less relevant; team dynamics are at the heart of all work, regardless of field.
Software design is where fear meets generative AI, but in the sense that the purpose of software design is to “meet the needs of a customer,” it must be stated that one cannot outsource those needs to AI any more than you can outsource eating, breathing, or sleeping. The need to help teams of people articulate their functional requirements might be more important today than it ever has been. Great functional requirements transcend technical implementations; as the paradigm goes, the requirements are more important than the code. The best functional requirements are invaluable as prompts for generative AI tools to deliver their best results. What percentage of your organization’s systems have living, breathing complete functional specifications? What percentage of your organization’s user stories have clear, verifiable “so that” clauses, let alone complete conditions of acceptance? Even if you believe your own organization’s answers are “100%” (I will humor you), would you admit this is not likely to be true for others?
Software evolution and maintenance is one of those areas where we should hope generative AI can help. The LLMs of 2025 are already quite good at helping software engineers rework existing code, and future LLMs are sure to be even better. But one dimension of software engineering remains unthreatened by AI: the implications of process trade-offs in enterprise systems. Seemingly simple changes — something as small as the format of a field, or a change in processing logic — ripple throughout enterprise systems. Larger changes produce tidal waves. Only those being served by the software can determine what the subjectively “least worst” (a term I must credit to Reggie Aceto, one of my many fine employees over the years) choice may be for the systems’ constituents. AI cannot solve human compromise, because decisions can never be “correct” — if a decision is implicitly correct, then there would be no decision to make.
Which brings us to complexity management. I’m glad that Lutz and Naveda use the phrase “often as a direct result of the flexibility inherent in the software.” This should remind us that software engineering is a form of leadership. While software relieves humans from one anxiety — the paralysis that comes from having to think of everything in advance — it creates a consequential anxiety that benefits from genuine human leadership. I dare an AI scientist to find a computational substitute for that; we should welcome tools that offer even a glimpse of assistance with the journey.
Standards, which are part of the sometimes-irrational and always-imperfect output of the human condition, will continue to provide challenges that, in fact, could benefit from AI assistance.
Process issues evolve in tandem with human change, and must accommodate human anxiety and imperfection.
We’d best think of generative AI the way we would any other tool: something to use when it makes sense. Do you avoid using the hammer in your toolbox? Or do you use it for every task? What about a search engine? If you had an employee at work who needed to learn a feature in a new piece of software or who needed to find the name of the CEO of a business partner and refused to use a search engine, what would you do? If they did this a few times, you’d be irritated. If they did it routinely, you might, as my boss Kip Palmer likes to say, share them with other employers.
Technology changes the face of every manner of hobby and profession, but almost every time we think we’ve solved one problem, we’ve opened the door to a whole new set of them. Consider the lessons of Walter Ong’s Orality and Literacy: there as a time when writing did not exist. Writing brought fear of losing the power of our memory, but it changed the way we express ourselves; created all manner of tools for expression, from pens to printing presses to the screens of today; created the need to store and distribute this written expression; and changed the way we learn forever. Technologies beget other technologies; if we didn’t have writing, we wouldn’t have generative AI.
New human problems are in endless supply. Tools don’t solve them on their own. We’d do well to remember the lesson of The Turing Trap: there’s an awful lot more for us to do, even if we hadn’t thought it possible. While it sometimes seems like humanity is doomed with every new advancement, humanity itself is the audience, and the need for us to focus on the manner in which we engage one another is at no risk of being diminished. The ten foundational values of The Progressive CIO remain the heart of all work to come.
Special thanks to RIT Professor Scott Hawker for inviting me to his classrooms many years ago. He and I had a vision for this research a while back, and he is deserving of a lot of credit for the approach we took in what you are about to read.
Have you ever witnessed:
An engineer’s condescension about a customer’s lack of knowledge?
An engineer’s desire to prioritize quick solutions without affording the customer an objective discovery session, so that the engineer could get right down to solving?
An engineer’s presumption of technical expertise on the part of a customer?
A customer’s desire to be an armchair engineer for any number of reasons?
A customer’s reticence to deeply engage with the engineer due to any or all of the above?
Me, too.
When I hire people — especially software engineers — I like to be able to get a sense for how they handle situations like these. Like many managers, I’ve cultivated an arsenal of interview questions to help me rapidly sense the people skills I seek, and which I tend to feel are in insufficient supply. After years of interviewing, my collection of go-to questions has narrowed considerably, and one question stands out above all others.
I began guest lecturing at RIT in 2013, and Professor Scott Hawker and I discussed the idea of a presentation to students of his class in Software Requirements and Architecture Engineering (a 400 level class) that involved a “cold open.”
At the top of the class, before I even introduced myself, I shared that singular interview question on the screen before them:
I handed a half-sheet of yellow paper to each student and gave them a few minutes to jot their answers. From September 2013 through November 2017, I collected 261 students’ answers across 16 individual classes (fifteen RIT classes and one class at my alma mater, Binghamton University; thanks not just to Scott Hawker but to Mehdi Mirakhorli and Bob Kuehl as well). During each class, I browsed through the students’ answers and shared, aloud, some of the more interesting ones to create conversation before introducing myself and the topic of the day, which is the very same topic I will share shortly with you.
Nine Response Categories
This particular question was designed to help me identify a way in which candidates might approach a software problem-solving exercise. Subjectively, there are good and bad answers to this question when considered in light of a dimension I call “Safety,” which I describe as the risk to a professional’s ability to properly elicit a problem from someone while developing or maintaining a good relationship.
Over years of doing this, I’ve discerned nine distinct categories of answers, presented here in the order of their frequency in my university guest lecture series. The table below summarizes these nine response types, along with the “Safety” designation that denotes my subjective feeling about the given answers in regard to the potential consequences of each approach. To illustrate each category, I’ve presented a typical “Medical” example and an equivalent “Software Engineering” example (a businessperson asking a software engineer to add a new field to an existing screen in an enterprise application):
Classification
Description
Safety
Medical Example
Software Engineering Example
Engage, Specific (36.40%)
Student does not make assumptions or start treatment; asks good questions; assesses symptoms.
Desirable
“I’d love to help you out. Tell me a little more about how you are feeling.”
“I’d love to help you out. Tell me a little more about what’s going on.”
Engage, Generic (16.48%)
Student proposes something to the effect of “Will determine whether or not you are having a heart attack” without specifics (inquiry, testing, etc.).
Acceptable
Will take one of many potential actions (perhaps dialogue, but also perhaps procedures, etc.) to determine whether or not you are having a heart attack.
Will take one of many potential actions (perhaps dialogue, but also perhaps procedures, etc.) to determine whether or not adding a field is the appropriate solution.
Trust (16.09%)
Student starts to explore reported issues (symptoms) without asking questions.
Workable
Check your heart rate.
Asks where the field should be located and how it should behave.
Solve (15.33%)
Student initiates “solving” the problem without asking questions.
Unacceptable
Administer aspirin.
Says OK, leaves, and adds the field.
Challenge/Dismiss (6.13%)
Student asks questions, but phrased in an at-least-somewhat-confrontational way…or dismisses the situation altogether.
Workable
“Why do you think that?”
“Why do you need that field?”
Couch (4.60%)
Student offers multiple answers in an attempt to safely satisfy any one of multiple conditions.
Workable
(Could be any other type(s) of approach listed here.)
(Could be any other type(s) of approach listed here.)
Avoid (2.30%)
Student avoids specifics; does not propose a specific path of action.
Unacceptable
Ignores the patient and moves on to other topics.
Ignores the businessperson and moves on to other topics.
Humor/Other (1.53%)
Student offers a humorous or other answer that does not fit elsewhere. Students will be students!
Unacceptable
“If you were having a heart attack, I’m pretty sure you would have died on the way!”
“If you needed that field, it would be there already!”
Calm/Reassure (1.15%)
Student proposes an interim calming step before any diagnosis dialogue.
Acceptable
Sits the patient down and applies other calming techniques before attempting anything else.
Asks the businessperson to go for a walk or a cup of coffee before engaging in further conversation.
We care about the nature of these responses because we want engineers to foster high-quality relationships with their customers where those customers not only enjoy and trust working with the engineers, but most especially seek the engineers’ help as a result of that dynamic.
Let’s take a deeper look at the nine response types:
Engage, Specific (36.40%)
Engage, Specific is a preferred style that presents the lowest risk to the patient, and to the doctor-patient relationship:
The patient arrives with a diagnosis of a specific condition that could, in fact, be incorrect. In that sense, the patient is coming in hope of a solution to that specific problem.
The doctor understands that the patient could be incorrect, and understands that there is risk in honoring the patient outright.
Although the doctor understands this risk, he or she does not belittle the patient in any way, or use language that amplifies the status differences of the two in the relationship.
The doctor asks good questions that do not assume that the patient is right or wrong, but that help the doctor assess what could be going on.
Engage: Specific stands out because of the tone of the dialog. Its goal is to create comfort while reducing the risk of a response that could cause emotional or physical harm.
Actual examples:
“Asks what your symptoms are.”
“The doctor is going to ask you to try and relax the best you can. Then the doctor will ask a series of questions to either you or who you are with to try and diagnose the problem.”
Engage, Generic (16.48%)
“Engage, Generic” is also a low-risk approach, but not quite as preferred. The first two bullets in Engage, Specific apply here. However, here are the differences:
The doctor understands the risk in honoring the patient’s self-diagnosis, but the respondent describes the doctor’s behavior in a positive yet generic way. We are unable to discern from the answer whether or not the exchange with the patient will be of a respectful tone and nature.
Because there is no clarity on a specific approach, there is a possibility that the respondent does not fully appreciate the value of high-quality dialog.
We believe this presents an opportunity to better condition these professionals with the Engage: Specific format.
Actual examples:
“The doctor will probably try to determine whether or not I am really having a heart attack.”
“See if it’s really a heart attack and not something else.”
Trust (16.09%)
Trust is a workable approach, although with more potential risk than Engage: Generic:
The doctor gives some credence to the patient, and rather than exploring all of the possibilities of the situation, begins to narrow down solutions to those relating to the proposed problem.
The doctor’s trust of the patient is likely to have some form of positive impact on this delicate moment in the doctor-patient relationship.
Presumably, if the ensuing activities discount the possibility of a heart attack, the doctor will explore other possibilities.
We cannot immediately tell whether or not the doctor is being objective. However, a sensible doctor knows that a heart attack requires quick response, and suspending immediate objectivity to trust the patient’s self-diagnosis might only result in a short series of tests to eliminate the possibility so that the doctor can explore other options in a more leisurely manner.
Risks to this approach may be worth exploring further in future iterations on this project. In the case of a patient with a headache who insists he or she has a brain tumor, a quick Trust reaction is less useful, and might provide different insight into the thought processes of students or job candidates.
Actual examples:
“Check your heart rate.”
“The doctor will likely hook you up to a number of machines to determine if you are, in fact, having a heart attack.”
“Send you to the emergency room.”
Solve (15.33%)
The Solve style is most problematic, because it could lead to the application of inappropriate treatment that puts the patient’s life at risk.
Actual examples: – “Pump you with meds.” – “Give you aspirin.”
Challenge/Dismiss (6.13%)
The Challenge/Dismiss style is not a preferred approach, because:
It might betray a lack of trust in the individual being served.
It might be confrontational in its presentation.
It does not convey compassion or understanding.
Actual examples:
“Why do you think that?”
“Ask the patient why he thinks that he is having a heart attack.”
“What makes you think that?”
“Explain that you don’t have to worry and that you aren’t having a heart attack.”
Couch (4.60%)
The Couch style is problematic because it’s a “shotgun” approach offering multiple “hopefully” correct answers that could individually be ascribed to the other categories. It is focused on an attempt to get an answer “right” rather than owning any particular approach. It could be a sign of a lack of self-confidence, which isn’t a bad thing unto itself, but it it may be an indication that further coaching and development is needed.
Actual examples:
“Take you to the bed. Take vitals. Use a defibrillator if necessary.”
“Run tests, ask questions, give medication.”
”Check his body and give meds.”
Avoid (2.30%)
Avoid is similar to Couch but involves a single answer that is generic enough to be right without being useful.
Actual examples:
“Assess the situation and react accordingly.”
“The doctor will doctor the patient.”
Humor/Other (1.53%)
Humor/Other is something that is perhaps an artifact of presenting this to college students, who take delight in offering pithy and funny responses to academic questions. Luckily, I’ve never encountered these answers in an interview setting. This also includes other responses that don’t fit into the other eight categories.
Actual examples:
“Please sign in at the front desk.”
“Why didn’t you call 911? Have a seat in the waiting room.”
Calm/Reassure (1.15%)
In Calm/Reassure, the student proposes an interim calming step before any diagnosis dialogue. This is entirely fine, and may be the first step in almost any reasonable approach, but it is somewhat incomplete and is, therefore, somewhat less desirable than the two Engage styles.
Actual examples:
“Have you take a seat or lay down and calm you down.”
“Have you sit down.”
What Do the Numbers Tell Us?
A little more than half (54.03%) of the students responded with an approach that is, more or less, immediately consistent with a healthy doctor-patient relationship, and that would contribute to a favorable interview (Engage, Specific; Engage, Generic; Calm/Reassure).
Just over a quarter (26.82%) offer an approach that might work but would require further development and coaching (Trust; Challenge/Dismiss; Couch).
About one in five (19.16%) responded in ways that add more mystery to their ability, and would pose a challenge to hire with the sort of certainty I prefer when interviewing (Solve; Avoid; Humor/Other).
If these students were my hiring pool, they’d be a pretty good one; anecdotally, my actual interviews over the years failed to achieve such a favorable statistical distribution. I have to remember that these were all students from premier universities.
Opportunities
I believe that this exercise proved useful in highlighting the notion that nearly 46% of students have opportunities for improvement in their approaches. Let’s take a look at the less “Safe” response types for opportunities to correct these behaviors. To add a little texture and extend the medical metaphor (for which I seem to have a fondness), I’ve changed the patient’s problem in this series.
Trust
“Doc, I have a brain tumor.”
“Let’s explore some options. We could do chemo. Or there is surgery, but I wouldn’t recommend that until we’ve tried chemo, but it’s your choice…”
I’m sure you and I have seen many examples of people on the receiving end of a problem diagnosis. From my own perspective, I think most of us, at our most animal, are wired to solve problems as a survival tactic. There’s a lot of good in that. The problem really lies in the how.How do we solve the problem? Trusting the self-diagnosis might be a step. It’s certainly easier than responding in any other way, when any other way risks conveying distrust. It seems fairly certain to me that the Trust response is offered because the person knows the Solve response is too much, too soon. But those who tend toward TrustandSolve have one thing in common: they both feel uncomfortable challenging the self-diagnosis. That’s what makes them both a better response than Challenge/Dismiss, but it’s also where the opportunity lies.
When you are driving, what is the opposite of pressing the accelerator?
Hint: It’s not pressing the brake.
It’s taking your foot off the accelerator.
Likewise, the alternative to trust is not to distrust. It’s to suspend the trust and redirect the conversation. That sounds like this:
“Doc, I have a brain tumor.”
“Oh! I’d like to help with that! Tell me a little more about what’s going on?”
Again, the key here is to develop an understanding that the opposite of trust is to set the trust aside for a moment, rather than to discard it altogether. When we can develop that comfort, we get to Engage, Specific.
Couch
“Doc, I have a brain tumor.”
“Let’s check you out and give you some medicine.”
I believe the Couch response is a product of the classroom or interview setting. As an interview answer, however, it leaves a lot to be desired. That said, it is an indication that the practitioner wants to do the right thing…it’s just that they are not sure what that right thing is. In my experience, folks who fall into this camp learn what they need through more discussion, and from exposure to the pluses and minuses of the eight other behaviors we’re discussing here. It will take some practice and time, but these folks’ good intentions will get them there more reliably than those who tend toward Challenge/Dismiss.
Challenge/Dismiss
“Doc, I have a brain tumor.”
“Don’t worry. You don’t have a brain tumor.”
Or:
“Doc, I have a brain tumor.”
“Why do you think that?”
Nothing feels more dismissive or disrespectful than Challenge/Dismiss. At least the Solvers and Trusters seem to agree on this point.
So what’s behind this response style? Overconfidence? Carelessness? A mix? Unlike Solve and Trust, the fundamentals behind this approach seem thornier to address.
Nobody likes to feel like they are being dismissed or to be put on the defensive. The opportunity here is to ask the practitioner: Can you think of a time when you had a genuine concern that someone dismissed or challenged? How did that make you feel? Is that similar to some of the choices you’ve made in your professional work? If not, why not?
Solve
“Doc, I have a brain tumor.”
“Well, let’s get you into the operating room.”
Solve is one of the two response types I witnessed throughout my early career that inspired the interview question (the other being Challenge/Dismiss).
Both Challenge/Dismiss and Solve create risk. Challenge/Dismiss presents risk to the relationship between the doctor and patient. Solve, however, presents direct risk to the patient, and in that sense it’s the big one to watch out for. Solve is Trust with immediate execution, and it is loaded with risk. The fact that 1 in every 6.5 bright young participants tended toward this response presents a real opportunity.
Since I’ve characterized Solve as an extension of Trust, it’s fair to say that the underlying emotional foundations are similar. Solvers don’t want to convey distrust. But, for some reason, they also feel like skipping past most any discussion to just get things done.
It’s possible they aren’t well-schooled in having exploratory conversations, or that they are simply uncomfortable — introvert-like — with having much conversation at all. But it’s safe to assume that their intent isn’t to cause harm. That’s where the opportunity lies.
In my experience, sharing the doctor-patient analogy has proven to be a useful illustration of the risks of the Solve response. Once that’s realized, the next step is to explore the Trust part of the relationship — the opposite of trust is not distrust — and coach the individual through what that looks like.
Humor/Other
“Doc, I have a brain tumor.”
“If I had a dime for every time someone with a headache said that…”
As with Couch, I believe this response is a product of the classroom setting. However, I’m less certain that the student wants to do the right thing, let alone that they know what the right thing looks like.
That said, I think the opportunity is to put the practitioner into several situations to see what they actually do in situ, and to correct course accordingly.
Avoid
“Doc, I have a brain tumor.”
“I can take care of that for you.”
Even I will admit it was difficult to author that example. It’s hard to think of how this sort of behavior might occur in the real world. As with Couch and Humor/Other, I suspect it’s more an artifact of a classroom or interview setting. Certainly, from an interview perspective, it’s an undesirable answer. I think the opportunity at work or in the classroom is to put the practitioner into several situations to see what they actually do in situ, and to correct course accordingly.
The Power of the Question
This little question has helped me define a way of thinking about interpersonal problem-solving behaviors not just in interviews, but sometimes right in the middle of a less-than-ideal workplace situation.
We know that 46% of students who participated in my exercise had great opportunity to improve their manner of client engagement, and I’ve outlined some pathways toward that improvement. But as I’ve noted before, software engineering — and anything that looks like it — is a form of leadership, and one thing remains true above all else: these leaders have to understand why it’s in their best interest to develop their leadership skills.
At the heart of this entire dynamic is a key concept of rhetorical theory: the relationship between logos, pathos and ethos. In my own words:
Logos: The appeal to logical thinking.
Pathos: the ability to sympathize or empathize…to understand others.
Ethos: respect for beliefs, and the establishment of trust.
In their academic work, engineers become highly skilled in logos. But they are not typically conditioned to devote time to become great sympathizers or empathizers, and they are likewise not typically schooled in ways to nurture trust.
Here’s the part of my guest lecture that followed the “heart attack” exercise:
What do engineers do?
We apply science to solve problems.
How do we know what problems to solve?
People are supposed to explain their problems to us.
But do they?
(Here, a great amount of discussion ensues.)
What is a good requirement?
I like to reference Wikipedia for this, but one key characteristic sticks out…a good requirement is traceable:
The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.
Is there a way to test business need?
If we merely ask, “Does this requirement meet your need,” what kind of answer do we expect?
Ponder this for a minute…
You can’t ask. You have to know.
The way to know is to be part of the conversation!
The conversation…
…is a dialogue.
It involves listening.
Listening != hearing.
Hearing = reception of sound.
Listening = processing of information.
We listen in order to understand.
When we listen, we ask questions to make sure we understand. We reiterate. We get confirmation.
One of the best ways to understand is to imagine yourself in the other person’s shoes.
When done right, this is uncomfortable.
This is how we get to pathos.
Good requirements…
…should lead to good software.
But what is good software?
It is software that gets used to solve the problem it was designed to solve.
When people’s problems are solved, they are usually happy.
When your good requirements make people happy, they see that the time spent with you was worth their while.
They come to respect your methods and to trust you.
This is how we get to ethos.
This cycle of empathy and trust (with a proper dose of logic!) is what makes for a successful relationship between a software engineer and a customer…a relationship where engineers feel happy because they know that all of their hard work has meant something.
Now my questions for you, dear reader, are:
How do we find place in a young engineer’s life to develop these skills?
How do we find place in a working engineer’s life to nurture these skills?
![[Logo]](https://theprogressivecio.com/wp-content/uploads/2020/07/ProgCIO-1024x1024.png)
