Episode 33 — Keep It Simple and Practical When Complexity Starts Taking Over
In this episode, we turn to a principle that sounds almost obvious until you see how often organizations drift away from it without noticing. New learners sometimes hear keep it simple and practical and assume it just means use fewer words, build fewer features, or avoid hard thinking, but that would miss the real power of the idea. The principle matters because services become difficult in a very specific way over time. They do not usually collapse because one person tried too hard to make them confusing. They become heavy because each new rule, extra handoff, special case, and protective layer seems reasonable on its own, until the combined result is a service that feels harder to understand, harder to support, and harder to improve. For the certification and for real service work, this principle helps you recognize that value is not increased by complexity alone. In many cases, value is protected when people are disciplined enough to reduce what is unnecessary and make what remains easier to follow, easier to trust, and easier to carry through the full service experience.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
Complexity is not always a sign of bad work, and that point matters because beginners can easily swing too far in the other direction. Services are often complex because the world they operate in is complex. People have different needs, regulations may exist, technologies may depend on one another, and organizations may have to balance risk, cost, speed, accessibility, and reliability all at once. So the goal is not to pretend a real service can be made perfectly simple in every respect. The problem begins when complexity stops reflecting real necessity and starts reflecting accumulated habit, caution without clarity, duplication, weak ownership, or the fear of removing anything because someone once thought it might matter. At that stage, the service begins consuming more effort than the value justifies. Users feel it as confusion, support teams feel it as repeated questions, and leaders feel it as slower change and weaker confidence. Keeping things simple and practical is therefore not anti-complexity in a childish sense. It is a disciplined way of asking whether the complexity still serves the outcome or whether it has begun serving itself.
One reason this principle is so important is that organizations do not usually announce that they are becoming too complicated. Complexity grows quietly, often through well meaning decisions. A team adds an extra approval because one past issue created anxiety. Another team adds a second reminder because some users missed the first one. A supplier introduces another layer of coordination, and no one removes an older layer that is no longer needed. Support staff create workarounds that help in the short term, and those workarounds slowly become part of the unofficial service model even though they were never designed to last. Over time, the service begins to look like a series of patches rather than a coherent journey. Everyone can explain why each piece exists, yet very few people can explain why the whole thing still makes sense from beginning to end. This is where the principle becomes valuable. It encourages the organization to notice when a service has become crowded with local solutions that no longer add up to a practical overall experience.
To keep something simple and practical does not mean stripping it down until it becomes weak, shallow, or careless. Simplicity in Information Technology Infrastructure Library (I T I L) is not the same as oversimplification. Practicality is not the same as rushing past nuance or pretending tradeoffs do not exist. A service can be simple in the sense that people understand what matters, what comes next, who owns what, and how value is created, while still being sophisticated beneath the surface. A digital service may have a great deal of technical depth, supplier coordination, and regulatory responsibility behind it, yet still feel clear and usable for the person at the center of the journey. That is what this principle is aiming at. It asks organizations to reduce unnecessary burden, clarify what is essential, and resist the temptation to add more process, more messaging, more exceptions, or more structure than the situation actually needs. It is a call for disciplined clarity, not for shallow design.
Imagine a community college that has spent several years improving its digital student portal for registration, financial aid, class schedules, and deadline reminders. Each change was made for a reason, and most of those reasons sounded sensible at the time. One department wanted more status messages so students would know what was happening. Another wanted more mandatory confirmations so fewer tasks would be missed. Advisors requested additional notices for students on probation, while records staff added special steps for certain schedule changes. Financial aid teams wanted separate alerts for required documents, and technical teams added extra routing rules to handle different student categories. None of these choices were irrational in isolation, yet students now describe the portal as stressful and cluttered. They receive too many messages, cannot tell which steps truly matter, and often contact support even when the portal technically contains the answer. The service did not become weak because people stopped caring. It became complicated because many caring decisions accumulated faster than anyone simplified the whole experience.
When complexity starts taking over, the user experience is often the first place the damage becomes visible. A person trying to complete a task usually does not want more process, more screens, or more explanation than necessary. What they need is enough clarity to move forward with confidence. In the student portal case, the problem may not be that students refuse to read instructions. The deeper problem may be that the service is forcing them to interpret too many instructions, too many signals, and too many exceptions at the same time. When people are already stressed, extra complexity does not feel helpful. It feels like uncertainty wearing official language. Users may begin missing steps not because the service lacks information, but because it contains too much poorly prioritized information. This is one of the central lessons of the principle. Services become more practical when they reduce unnecessary interpretation. A user should not have to decode the organization’s internal complexity just to understand the next meaningful action in a process that matters to them.
Support and frontline teams feel the effects of growing complexity just as strongly, even if the problem is often described as a staffing issue at first. In reality, many repeated support burdens come from services that have become too hard to explain cleanly. When a student portal generates multiple overlapping reminders, special case rules, and inconsistent next-step messages, support staff are forced to become translators of a service that should have been clearer in the first place. They start memorizing exceptions, creating local shortcuts, and carrying knowledge that exists mainly because the service design has become harder than it needs to be. That hidden labor is expensive. It consumes time, increases training needs, and makes performance depend too heavily on which individual happens to answer the request. The organization may think the service is functioning because support keeps saving the day, but that is often a sign that complexity is already taking over. A practical service reduces the need for constant rescue. It allows support teams to handle real issues, not endlessly compensate for preventable confusion.
Technology is also deeply affected when complexity grows unchecked, because technical environments become harder to change, harder to test, and harder to trust when too many special paths accumulate. A system with many extra rules, custom exceptions, overlapping workflows, and unclear ownership may still function for a while, but each future change becomes riskier because no one is fully sure what hidden dependency might break next. In the college portal example, adding a new feature could become difficult not because the feature itself is particularly hard, but because the surrounding environment has become tangled with conditions, message triggers, approval paths, and integration points that nobody wants to touch. Complexity of this kind slows improvement even when the organization says it wants agility. It also weakens resilience, because recovery becomes harder when the service can only be understood through scattered local knowledge. Keeping things simple and practical protects technical environments by preserving clarity around how the service works, which makes future change more manageable and less frightening.
When this principle is applied seriously, the first shift is not usually technical. It is mental. The organization steps back and asks what the service is truly supposed to help the user accomplish, and then asks whether each layer of activity still supports that outcome. This is where focusing on value becomes essential. A team may believe an additional step improves control, but if it adds confusion without reducing meaningful risk, it may not be helping the service at all. Another team may believe extra messages improve awareness, yet if users no longer know which message matters most, value may be falling rather than rising. Keeping it simple and practical means challenging the idea that every existing element deserves permanent life. It encourages people to see removal, consolidation, and clarification as legitimate forms of improvement rather than as risky absences. In many organizations, adding feels safer than subtracting because addition looks active and protective. This principle reminds you that subtraction is often where clarity and usefulness begin.
A more practical service usually has a smaller number of clearer paths rather than a large number of overlapping ones. It uses language people can actually follow instead of reflecting internal departmental distinctions that do not help the person using the service. It keeps ownership understandable so that work does not disappear into handoffs nobody can explain. It avoids building special cases into the main experience unless those cases truly matter often enough to justify the added weight. In the student portal story, keeping it simple and practical might mean combining several similar notifications into one clearer message, aligning terminology across departments, removing repeated confirmations that add little real benefit, and making the next action more obvious at key points in the journey. None of those changes sound dramatic, which is part of the lesson. Services often improve not through spectacular redesign alone, but through disciplined reduction of what is unnecessary. Practical clarity is powerful precisely because it feels smaller and quieter than complexity, while often creating much stronger value.
This principle also works best when connected to the others around it instead of being treated as a stand-alone slogan. Starting where you are matters because simplification requires understanding the current state before cutting or changing anything. Progressing iteratively with feedback matters because organizations rarely discover the most effective simplification in one perfect motion. Collaborating and promoting visibility matter because complexity is often experienced differently across teams, and hidden pain points remain hidden when groups do not compare what they know. Thinking and working holistically matters because a service can be simplified in one local area while becoming more confusing in another if the full journey is ignored. Even optimizing and automating depend on this principle, because automation makes poor complexity move faster if the underlying flow has not first been clarified. This is why simplification is not a shortcut. It is a mature discipline that often requires careful observation and better cross-team judgment than simply adding another layer and hoping the added structure will solve the problem.
A second scenario makes the idea easier to hear in a different setting. Imagine a neighborhood health clinic that offers online appointment booking, digital forms, reminder messages, and follow-up care instructions. Over time, new concerns have led to more confirmations, more message types, more exception handling, and more patient categories with slightly different communication paths. Staff want to prevent missed appointments, clinicians want instructions to be accurate, administrative teams want fewer repeated phone calls, and leaders want risk handled responsibly. Yet patients now report that the service feels harder to follow than before. They receive too many notices, cannot always tell which one contains the real next step, and sometimes complete forms twice because the process appears to ask for the same thing in different ways. Support staff spend increasing amounts of time explaining what the service meant to say. In that environment, simplicity is not laziness. It is a way of restoring trust. A more practical service would make the path clearer, the messages fewer and more meaningful, and the ownership of patient communication much easier to understand.
There is also an important tradeoff hidden in this principle, because organizations sometimes believe extra complexity is automatically safer. In some cases, detail and control really are necessary. A health clinic cannot ignore privacy, legal obligations, or patient safety just because simplicity sounds attractive. A college cannot remove important review steps if those steps protect fairness or compliance in meaningful ways. The principle does not ask you to pretend those realities do not exist. What it asks is whether the way those realities are handled is as clear and light as it can reasonably be. Overcomplexity can create its own form of risk by increasing misunderstanding, weakening ownership, slowing response, and making the service harder to operate correctly under pressure. In other words, a service can become more dangerous because it is too complicated, not just because it is too simple. That is why good judgment matters here. The goal is appropriate simplicity, where the service remains responsible and dependable without forcing people to carry more process than the outcome truly requires.
For a beginner, one of the most useful habits is to notice when the explanation of a service begins sounding harder than the value it is trying to create. If a simple user goal requires too many exceptions, too many messages, too many approvals, or too much support translation, complexity may already be taking over. If staff cannot easily explain the path from request to outcome without relying on personal workarounds, complexity may already be taking over. If every new change feels frightening because no one fully understands the existing structure anymore, complexity may already be taking over. These are not advanced technical signals. They are practical signs that the service is carrying more weight than it should. Keeping things simple and practical means treating those signs seriously. It means recognizing that clarity is not cosmetic. It is part of what allows a service to remain usable, supportable, adaptable, and trustworthy over time.
By the end of this discussion, the principle should feel much sharper than it did at the start. Keeping it simple and practical does not mean avoiding hard problems or flattening real complexity into childish answers. It means refusing to let unnecessary complexity crowd out value, clarity, and responsible action. It asks organizations to notice when added structure has become a burden, when local fixes have become a tangled whole, and when users and staff are doing too much interpretation just to move through an ordinary service journey. In modern digital products and services, complexity often arrives quietly and defends itself with good intentions. That is why this principle matters so much. It gives people permission to remove, align, clarify, and simplify in service of real outcomes. When you understand it that way, you begin to see simplicity not as a lack of sophistication, but as one of the clearest signs that an organization understands what truly matters and has the discipline to protect it.
