Your Business Thrives When Everything Flows

WHERE IT STARTED

​

I joined a large national insurance services company in the 1990s as an executive assistant supporting the senior leadership of the Information Technology department.

​

The IT department primarily focused on coding and programming at the time. A large team of programmers developed internal software for departments that needed functionality beyond the systems already available to them. Technology use throughout the company was expanding quickly, but the company had not developed centralized user support alongside it.

​

My role had nothing to do with technical support. I simply happened to be very comfortable with Microsoft Office at a time when businesses were becoming increasingly dependent on desktop software and employees had very different levels of experience using it. People in the local office learned that I could usually answer their questions, so they started calling me when they needed help.

​

Those calls gradually expanded beyond Microsoft Office. Employees sometimes had hardware questions or problems and couldn't reach the person responsible for that area, so they began calling me instead. I answered what I could and found someone who could help when I didn't know the answer.

​

There was no formal process behind any of this. I remember writing messages and questions on notepads and following up with people as I found the information they needed. I simply began handling technical support at my desk alongside the executive support work I had actually been hired to do.

​

Eventually, enough people were coming to me for help that I went to my boss and explained what was happening. Employees had created an informal support path without anyone intentionally designing one. They knew where they could get an answer, so they kept using it.

​

It took some time, but the company eventually decided to formalize what had developed organically. The company promoted me, gave me a small budget and moved me into the large area where the programmers worked. My desk sat near the front so employees could easily find me.

​

That became the beginning of the company's first Help Desk.

​

No one handed me an established model or a fully developed plan for what the Help Desk should eventually become. We built it around the needs that surfaced through the work.

​

In many ways, that became the pattern for everything that followed.

​

BUILDING THE HELP DESK

​

The Help Desk started with very little infrastructure. I had a small budget, a desk near the front of the programming area and the experience I had already gained from helping employees informally. At first, I continued using handwritten notes to keep track of questions, problems and information I needed to find.

​

The work itself began showing us what the Help Desk needed. We could answer some questions immediately. Others required information from someone with more technical knowledge. We needed to route hardware problems to the people responsible for equipment, while more complicated software issues sometimes needed the attention of a programmer. The Help Desk gradually became the central point for gathering enough information to understand what someone needed and getting that information to the right person.

​

The team grew as the workload increased. Another employee joined me fairly early, bringing several years of experience with the company and valuable institutional knowledge. We later added someone with a stronger understanding of coding and programming requirements. He could work through more complex software requests, gather the information the programmers needed and route those issues appropriately.

​

Handwritten notes were no longer enough once the volume of requests increased. The programmers developed an internal Help Desk application that gave us a more reliable way to manage the work. We could record incoming requests, track open and closed issues, escalate problems when necessary and manage requests related to hardware orders.

​

The tracking system gave the Help Desk structure that hadn't existed when I was handling support informally at my desk. It also created a clearer connection between employees who needed assistance and the technical specialists who could provide it. Employees no longer needed to determine which person in IT should handle a particular problem before asking for help. The Help Desk became the place to start, and we could determine where the request needed to go from there.

​

We didn't build the Help Desk from a finished plan. We added people, processes and tools as the work became more complex and we began to see the limitations of what we were already doing. Each addition solved a need we could see because we were already doing the work.

​

SCALING THE SUPPORT STRUCTURE

​

The Help Desk initially supported employees in the local office, but the need for technical support extended well beyond one location. The company had more than 800 users across multiple offices, and the IT department was already working with departments throughout the organization on software development and other technology needs.

​

At the same time, the demands on the rest of the IT department were increasing. More hardware meant more equipment orders, installations and technical problems. The company added technicians to support the hardware side of the department, while the programmers were increasingly busy developing internal applications requested by departments that needed more functionality.

​

Leadership eventually decided to expand the Help Desk into a centralized support point for users throughout the company. Another employee joined the team to help manage the additional volume, and the Help Desk began fielding questions and problems from offices across the country.

​

The expansion made coordination increasingly important. We handled the questions we could resolve directly and gathered the information needed when another member of IT had to become involved. We could route hardware issues to the appropriate technician. We could escalate more complex software problems to someone with deeper technical knowledge. The Help Desk gave users one place to begin without requiring them to know who within IT was responsible for a particular system or problem.

​

Centralizing support also gave the different parts of the IT department a more consistent connection to the people using the company's technology. Instead of every user trying to locate a programmer, technician or other technical resource independently, the Help Desk could identify what was needed and involve the appropriate person.

​

What had started as employees in one office calling me because they knew I could help had become a support structure serving more than 800 users nationally. The scale had changed significantly, but the basic purpose remained the same: understand what someone needed, get the right information to the right place and help move the issue toward resolution.

​

THE NEXT PROBLEM EMERGED

​

The programmers were also becoming busier as the Help Desk expanded. Departments throughout the company needed functionality that their existing systems couldn't provide, so the programming team was developing internal applications to support different types of work. Those applications continued to change as departments used them, identified additional needs and requested modifications.

​

The development work created another need. Employees had to understand how to use the programs the programmers were building for them.

​

The programmers knew the technical side of the applications better than anyone, but they were already managing development work and ongoing changes. The people using the programs needed information that explained what the software did and how to use it in their day-to-day work. Documentation became a natural extension of the support already happening through the Help Desk.

​

I began taking on that work. I had always enjoyed writing, had strong business writing skills and was comfortable using Microsoft Office to organize and present information. The part I had to learn was the software itself.

​

I worked closely with the programmers to understand the applications well enough to document them. That required more than recording technical instructions. I needed to understand what the program was designed to do, how employees would interact with it and what they needed to know to use it effectively.

​

The documentation created another connection between the programmers and the employees using their work. I could now translate technical knowledge that had largely existed within the programming team into information that departments could use.

​

It also changed the nature of my role again. I had started by answering questions, then helped build a structure for managing and routing those questions. Documentation moved the work one step further. We could now give people information they could use before they needed to ask for help.

​

That shift eventually led to another question: how could we get that knowledge into the hands of employees throughout the company without trying to train more than 800 people individually?

​

FROM DOCUMENTATION TO TRAIN-THE-TRAINER

​

Documentation gave employees a resource they could refer to, but the company still needed a practical way to introduce new programs and changes to people across multiple departments and locations. Training every employee individually would have created another bottleneck, particularly as the number of users and internally developed programs continued to grow.

​

That led to Train-the-Trainer.

​

I didn't volunteer for this part. Someone else volunteered me, and I was skeptical. I had become comfortable answering questions, working with the programmers and writing documentation, but I didn't enjoy public speaking. Standing in front of a group and teaching wasn't something I would have chosen for myself at the time.

​

The program started informally. I worked with individual department leads or managers based on the software their teams were using. Because I had already worked closely with the programmers to create the documentation, I understood the applications well enough to explain how they worked and answer many of the questions that came up.

​

Those individual interactions eventually developed into more formal training classes. Department leads and managers from the local office attended in person, while participants from other offices joined by teleconference. I walked them through the applications and provided the documentation they would need afterward.

​

They took that knowledge back to their departments and trained their own employees.

​

That structure allowed the company to distribute knowledge without creating another centralized dependency. The Help Desk didn't have to personally train more than 800 users, and the programmers didn't have to step away from development every time someone needed to learn how to use an application. Department leaders gained enough knowledge and supporting documentation to help their own teams.

​

The experience also changed something for me personally. Once the classes began, I realized I already knew many of the people attending them. I wasn't speaking to a room full of strangers. I was explaining something I understood to people I had already worked with, which made training feel much more natural than I had expected.

​

As I became more comfortable, I also became more confident and direct. That wasn't always easy for me. I was still early in my career and cared a great deal about being liked. I had to learn that being clear, capable and willing to take responsibility wouldn't always make everyone comfortable with me.

​

Train-the-Trainer helped me begin separating those things. I could care about the people I worked with without measuring my effectiveness by whether everyone liked me.

​

What began as a way to make software knowledge easier to distribute became an important part of my own development as well. I learned that I didn't have to be comfortable with public speaking to teach effectively. I needed to understand what I was teaching, understand what people needed from me and communicate it clearly.

​

CLOSING THE FEEDBACK LOOP

​

Train-the-Trainer gave department leads and managers the information and documentation they needed to train their own employees, but training wasn't the end of the process. Once employees began using the programs in their day-to-day work, new questions and problems naturally surfaced.

Those questions and problems came back through the Help Desk.

​

The Help Desk team could resolve some using what we already knew about the programs. Others required more technical knowledge or exposed an issue that needed a programmer's attention. In those situations, we gathered the information needed to understand the problem and brought the appropriate programmer back into the process.

​

That created a connection between the people developing the software and the people using it. Programmers could focus primarily on development and more complex technical issues without becoming the first point of contact for every user question. Employees had a consistent place to ask for help without needing to know who had originally built a particular program or which person in IT could solve the problem.

​

The documentation and training also gave department leads and managers a more active role in supporting their own teams. They could answer many questions directly, while the Help Desk remained available when they needed additional support or encountered something they couldn't resolve.

​

Information now moved in both directions. Programmers and the Help Desk could provide information about the software to department leaders, who could share it with their employees. Questions, problems and feedback from employees could move back through the Help Desk and reach the programmers when necessary.

​

The different pieces had developed at different times and in response to different needs, but they now worked together. The Help Desk provided a central point of support. Documentation made technical information easier to use and share. Train-the-Trainer distributed that knowledge throughout the organization. The escalation process brought more complex issues back to the people with the expertise to address them.

​

What started as a way to answer individual questions had become a system for moving information and support between the people building the company's technology and the people relying on it to do their work.

​

WHAT CHANGED

​

Over time, the technology environment began to settle into a different stage. The programmers spent less time continually developing new applications and more time maintaining and modifying the programs that were already in use. Departments had much of the functionality they needed, and their employees had gained experience using the systems that supported their work.

​

The departments also became more self-sufficient. Leads and managers had received training and documentation they could use with their teams, while employees had an established support structure when questions or problems exceeded what the department could handle. The Help Desk could still route more complex issues to the appropriate technical resource when necessary.

​

As the company's needs changed, the Help Desk changed with them. The team gradually spent less time interacting directly with users, and the work became more focused on reviewing reports and providing more generalized information. Eventually, the company relocated us away from the programming area where we had originally built the Help Desk.

​

That change was significant because the Help Desk had developed during a period when the company was rapidly expanding its use of technology. Employees needed somewhere to take questions. Programmers needed a way to receive more complex issues without becoming the first point of contact for every user. New applications needed documentation, and employees throughout the organization needed a practical way to learn how to use them.

​

Those needs had shaped the Help Desk as it grew. They also changed as the technology became more established.

​

I left the company around the time the Help Desk was entering this next stage, so I can't speak to how the function continued to evolve after my departure. What I could see before I left was an organization that no longer needed exactly the same support structure we had needed when the Help Desk began.

The system had changed because the work had changed.

​

That may be the most important outcome of the experience. Building a useful system doesn't mean preserving it in the same form indefinitely. The structure has to continue serving the work, and the work will not always need what it needed at the beginning.

​

WHAT THIS EXPERIENCE TAUGHT ME

​

I didn't have a framework for understanding any of this at the time. I wasn't intentionally studying how information moved through an organization or thinking about the relationship between technology, people and operations. I was doing the work in front of me and paying attention to what it needed next.

​

Looking back, I can see how much of the way I understand businesses today was already beginning to take shape.

​

The Help Desk started because people created their own path to get the support they needed. No one had to tell me that something wasn't working perfectly. I could see it in the calls coming to my desk. What looked like a collection of individual questions was actually a pattern, and the pattern pointed to a larger need.

Building the Help Desk taught me to pay attention to those patterns.

​

It also taught me that a useful system doesn't have to begin as a sophisticated system. We started with handwritten notes because that was enough for the work we were doing at the time. More people, clearer roles and better tracking became necessary as the volume and complexity increased. The structure developed alongside the work instead of being designed around what we imagined the work might eventually become.

​

Documentation and Train-the-Trainer taught me something different. Information has very little value inside a business if the people who need it can't understand, access or use it. The programmers understood the software because they had built it. Employees understood the work they needed the software to help them accomplish. The documentation, training and Help Desk helped connect those two kinds of knowledge.

​

I also learned that solving one problem often reveals the next one. Giving employees somewhere to ask questions helped, but growing demand required better tracking and more people. Building internal software created valuable functionality, but employees needed documentation to use it. Documentation provided information, but the company still needed a practical way to distribute that knowledge across hundreds of users. Training distributed it, and real-world use generated new questions that needed a way back to the technical team.

​

Each solution changed what became possible next.

​

The experience changed me, too. I moved from supporting executives to building and leading a function I hadn't expected to create. I learned unfamiliar software well enough to explain it to other people. I taught department leaders and managers even though I had never considered myself comfortable with public speaking. I became more confident in my knowledge, my judgment and my ability to communicate directly.

​

I didn't know then that these experiences would become part of a much larger understanding of how businesses work. I simply learned to notice where people were struggling, where information wasn't reaching the right place and where the existing structure could no longer support what the work required.

​

I still look for those things today.

​

THE FLOW ANALYSIS

​

Looking at this experience through the seven Flows I use today, Operational Flow and Information Flow were the strongest influences throughout the work. Neither operated independently. The Help Desk needed an operational structure to manage incoming requests, assign responsibility and escalate problems, but that structure could only work if the right information moved through it.

​

The earliest version of the Help Desk demonstrated that relationship in its simplest form. Employees needed information or technical support and found an informal way to get it. Handwritten notes were enough to manage those requests while the volume remained small. As demand increased, the same approach could no longer reliably support the work. More people joined the team, we defined responsibilities more clearly and an internal tracking system gave us a better way to capture and manage requests.

​

Operational Flow ↔ Information Flow

​

The operational structure determined how information moved. The information coming through the Help Desk also showed us where the structure needed to change.

​

That relationship became more important as the Help Desk expanded nationally. Employees needed one recognizable place to begin, while the Help Desk needed enough information to determine what we could resolve directly and what needed to reach a hardware technician, programmer or another technical resource. Centralizing the entry point simplified the experience for users without requiring the same person to handle every technical issue.

​

Fulfillment Flow became increasingly important as the company developed more of its own software. Creating an application provided functionality, but employees still had to understand how to use it in their work. Documentation translated technical knowledge into usable information. Train-the-Trainer distributed that knowledge through department leads and managers, and the Help Desk remained available when questions or problems exceeded what departments could resolve themselves.

​

Operational Flow ↔ Information Flow → Fulfillment Flow

​

The relationship among those three Flows created a continuous cycle. Programmers developed the programs, and I documented them. Department leaders learned how to use them and trained their employees. Employees used the programs in their actual work. Questions and problems returned through the Help Desk, and we could route more complex issues back to the programmers.

​

Strategic Flow supported the system at several important points. Leadership made the decision to formalize the Help Desk after the informal support pattern became visible. Leadership later expanded the function beyond the local office and provided additional staff as the number of users increased. Those decisions allowed a practical solution that had developed locally to become part of the company's broader IT support structure.

​

Customer Flow was also present, although the customers in this case were internal. Employees and departments relied on IT to provide technology that supported their work. The Help Desk gave them a clearer way to access support, while documentation and training gave departments more ability to answer questions themselves. Employees no longer had to know which individual within IT might have the answer.

​

Financial Flow appeared in limited ways through the initial Help Desk budget and the handling of hardware orders, but I don't have enough information from that period to evaluate its broader influence or any financial outcomes. Marketing Flow did not play a meaningful role in this work.

​

That distinction matters. The seven Flows are not a checklist that requires every Flow to appear equally in every business problem. Their value comes from identifying which parts of a business are influencing what is happening and understanding how those parts affect one another.

​

In this case, an Operational Flow need first became visible through Information Flow. Building the operational structure improved how information moved. Better information supported Fulfillment Flow by helping employees use the technology the programmers were developing for them. Strategic decisions allowed the structure to scale, while the resulting support system improved the experience of the internal customers relying on it.

​

None of those changes happened all at once.

​

The system developed because each stage of the work provided information about what was needed next. That is the pattern I can see clearly now: the business was continually showing us where the next connection needed to be made.

​

THE PATTERN I SEE NOW

​

I didn't set out to build a Help Desk when I took that executive assistant position. The need became visible because people kept coming to me for help, and I paid attention to what was happening.

​

That pattern repeated throughout the experience. More requests created the need for better tracking and additional people. More internal software created the need for documentation. Documentation led to training. Training created a way to distribute knowledge, while the Help Desk gave questions and problems a path back to the people who could address them.

​

None of those pieces existed independently. Each one affected what happened somewhere else.

​

I can see that much more clearly now than I could while I was doing the work. At the time, I was responding to what was in front of me and building what seemed necessary next. Years of experiences like this eventually taught me to look beyond an individual problem and pay attention to the connections around it.

​

A question landing on the wrong desk can look insignificant. Sometimes it is.

 

Sometimes enough of those questions are telling you something about the business.