When Less Structure Creates More Capability
An IBM Story About Customer Experience, Continuity, and Organizational Capability
The Situation
When I worked as a Systems Engineer for IBM, our branch established a Customer Help Line to assist customers experiencing technical problems or needing answers to questions.
The process was straightforward. Each day, a different Systems Engineer was assigned to answer the phones. The responsibility rotated among the engineers, distributing the workload and allowing everyone to spend most of their time working with their assigned customers.
It was a reasonable arrangement from an internal scheduling perspective.
But there was a problem.
Customers frequently called with issues that could not be resolved during a single conversation. An engineer might suggest several diagnostic steps and ask the customer to call back with the results.
When the customer called the following day, a different Systems Engineer answered.
The customer had to explain the entire problem again.
The new engineer had to develop an understanding of the situation, determine what had already been attempted, and decide what to recommend next.
If the problem persisted another day, the process repeated.
The organization had established a process for answering calls, but not for maintaining continuity in resolving problems.
Recognizing the Problem
I noticed something else.
Most of the other Systems Engineers didn’t particularly enjoy answering the Help Line. They preferred the more structured work associated with their assigned customers, where they understood the environment and generally knew what to expect.
I was different.
I enjoyed the uncertainty.
I liked answering a phone without knowing what problem would be waiting on the other end. It was an opportunity to learn something, investigate an unfamiliar situation, and work toward a solution.
What others considered an interruption, I considered an interesting challenge.
That difference suggested an opportunity.
A Different Approach
I approached my manager with a proposal.
Rather than rotating the Help Line among the Systems Engineers, I would answer the calls Monday through Thursday.
I would continue working with my assigned customers during the evenings and on Fridays.
My manager asked whether that was really what I wanted to do.
I explained my reasoning.
First, I believed it would be more efficient for our customers. They would no longer need to repeatedly explain the same problem to someone unfamiliar with their previous conversations.
Second, the other Systems Engineers would be relieved of a responsibility they didn’t particularly enjoy.
And third, I genuinely liked the work.
The proposal didn’t require additional technology, new staff, or an elaborate restructuring of the branch.
It required recognizing that the existing arrangement wasn’t serving customers as effectively as it could and that people brought different strengths and preferences to their work.
What Changed
The change established a consistent point of contact for customers using the Help Line.
Instead of starting over with a different engineer each day, customers could continue the conversation with someone who already understood the problem, the steps taken, and the information still needed.
It also changed how the branch used its available expertise.
Rather than requiring every Systems Engineer to perform the same activity on a rotating schedule, the responsibility was aligned with someone who enjoyed the uncertainty and variety of the work.
The other engineers could concentrate on their assigned customers.
We did not conduct a formal study of the time saved or measure the improvement in customer satisfaction. This happened more than 50 years ago.
But the underlying process problem was clear, and the change directly addressed it.
We reduced the structure imposed on employees while improving continuity for customers.
What This Story Reveals About Organizational Capability
Organizations frequently introduce structure to establish consistency, distribute responsibilities, and make work manageable.
Those are legitimate objectives.
But structure can also create boundaries that interrupt the flow of information, fragment responsibility, and force people to repeatedly reconstruct knowledge that already exists somewhere in the organization.
In this case, the daily rotation was designed around staffing.
The customer’s problem didn’t follow the staffing schedule.
Every handoff created the possibility that context would be lost, previous work would be repeated, or a different interpretation would redirect the investigation.
The problem wasn’t a lack of technical expertise.
It was how that expertise was organized and connected to the customer.
There was another important consideration.
Capability is not simply having qualified people. It is organizing their knowledge, experience, judgment, and individual strengths so they can be applied effectively.
The other Systems Engineers were capable professionals. Their preference for more predictable assignments didn’t diminish their expertise.
My preference for uncertainty didn’t make me a better engineer.
It made me particularly well suited to that responsibility.
The organizational opportunity came from recognizing the difference.
Examining the Story Through SCALE™
SCALE™ examines how an organization recognizes change, connects information and expertise, develops awareness, learns, and executes while meaningful action remains possible.
Several elements are particularly visible in this experience.
Signal — Recognizing an Unnecessary Burden
The recurring customer explanations were the signal.
Customers repeatedly reconstructed problems because the organization’s internal staffing arrangement interrupted continuity.
The process was functioning as designed, but the experience revealed that the design itself deserved examination.
Connection — Preserving Context Across Interactions
The rotating schedule repeatedly broke the connection between the customer, the problem, and the engineer investigating it.
Assigning a consistent point of contact preserved that connection.
The change reduced the need to rebuild understanding with each conversation.
Awareness — Looking Beyond the Internal Schedule
The daily rotation made sense when viewed as a staffing responsibility.
It looked different when examined from the customer’s perspective.
Recognizing that difference required looking beyond whether the assigned engineer answered the phone.
The more important question was whether the arrangement helped the customer move toward resolution.
Learning — Recognizing Different Individual Strengths
The experience also revealed something about the engineers themselves.
Some preferred predictable assignments. I enjoyed the uncertainty of unfamiliar problems.
Recognizing those differences created an opportunity to use existing expertise more effectively.
It also provided continuity for developing an understanding of customer problems over multiple conversations.
Execute — Changing the Arrangement
The improvement required a management decision, not a technology investment.
I proposed the change, explained the expected benefits, and offered to assume the responsibility.
The manager had the authority to consider the proposal.
The opportunity was to act on an observed problem rather than continue a familiar arrangement simply because it was already established.
The Two Decision Windows
SCALE™ recognizes that organizations frequently operate within two different windows.
The Readiness Window
How much time does the organization need to recognize a problem, understand its implications, develop a response, and prepare to act?
In this case, the response required recognizing the repeated handoffs and identifying a different way to assign responsibility.
There was no need for a lengthy implementation effort.
The Opportunity Window
How long can the organization wait before the consequences of inaction become more difficult to address?
Every additional day of the existing arrangement meant customers with unresolved problems could encounter another handoff and another round of explanation.
There was no known deadline or single event that would close the opportunity window.
Instead, the cost of the arrangement accumulated through repeated customer interactions.
The absence of a visible crisis did not mean there was no reason to act.
The Larger Lesson
Organizations often assume that more structure produces more capability.
Sometimes it does.
But structure should serve the work, not become an obstacle to accomplishing it.
The IBM Help Line wasn’t failing because the Systems Engineers lacked technical knowledge.
It was constrained by an arrangement that fragmented continuity and treated people with different preferences as interchangeable resources.
The improvement came from recognizing what the process was actually doing, understanding the people involved, and changing how responsibility was assigned.
Less structure did not mean less accountability.
It meant replacing an unnecessary rotation with greater continuity of responsibility.
And that created an opportunity for the organization to become more capable without adding resources.
Questions for Leaders
- Where does your organization require customers or employees to repeatedly explain information that should already be available?
- Which processes distribute responsibility but unintentionally fragment accountability or continuity?
- Are you assigning work based primarily on availability and organizational structure, or are you also considering individual strengths?
- Where are repeated handoffs consuming time without adding value?
- What existing capability could become more effective simply by changing how work is assigned?
A Final Question
Where has your organization added structure that makes the work harder rather than making the organization more capable?
Part of the SCALE™ Stories & Applications collection.
SCALE™ — How an Organization Recognizes Change and Acts Before the Decision Window Closes.
Tom Staskiewicz | UPproach.ai