Marie Kondo, the tidying expert and Netflix phenomenon, has people everywhere re-examining what in their lives sparks joy. If that doesn't describe your IT infrastructure, perhaps it's time to follow Kondo's KonMari method.
She asks participants to focus on the utility and joy of objects in order to remove possessions that aren't serving a purpose. For many people, the process and results of the KonMari method have been life-changing.
The Kondo craze got me wondering if this method of tidying up could also apply to IT. For example, what would your infrastructure look like using the KonMari method? How could you empower your IT team to define and reach their goals? What impact would that have on your business and IT spending?
While the idea of a tidy IT infrastructure is more abstract than a tidy home, you can apply Kondo's principles and philosophies to your organization for many of the same benefits: more space for the resources and tools you actually use, a unified and defined vision for the IT infrastructure you want, and a more enjoyable work life.
The benefits of a tidy infrastructure
When you hear "tidy," your brain might jump to images of sparse bookshelves, organized drawers, and sparkling countertops. As satisfying as clean racks and bundled cables might be, tidy infrastructure means being free of unnecessary or unused resources (or clutter), organized so that everything has a place, and automated so that it's easy to interact with.
It has the same descriptors as a tidy room—organized, labeled, uncluttered—but applied more abstractly to your codebase and data center.
Keeping your work tidy has many of the same benefits as keeping your house tidy. You’ll have more space—physical, emotional, on disk—for the resources you need to do your job. Are you still using Avery's user account to publish Docker images, even though that person left the company six months ago? Do you cross your fingers before each Jenkins run, hoping that the transient bug that's plagued your team for months doesn't show up? We've all been there.
Tidying your infrastructure isn’t about being perfect or doing one big clean and then forgetting about it. Tidiness is about investing in changing old, bad habits now that will pay dividends in the coming years, and creating practices around consistent tidying. Just as you wouldn’t leave a burrito wrapper on the counter, don't leave temp files lying around after your test suite runs.
This assessment and cleaning aren't going to be easy, or happen overnight. It's a process of considering where your infrastructure is and where you want it to be.
That kind of change takes investment. Tidying can get emotional. Clutter and possessions start to define your workspace. As IT teams, we tend to get comfortable in our workflows, even if they're inefficient or unstable. Tidying your infrastructure will do more than just lower your AWS bill; it will break your team out of that rut and build new, better practices.
Defining IT joy
The idea of sparking joy is a bit abstract, especially for IT teams that are pushed to find new ways to increase productivity and improve responsiveness, all while remaining compatible with existing internal applications. Unlike with Kondo's clients with their possessions, IT teams can't hold their Docker images and Terraform state files to their chests to see if they spark joy (though server huggers may disagree).
For many IT teams, joy may seem like a luxury, not a framework around which they are empowered to make business decisions.
But fear not! You can start by defining what joy means for your organization. Does your team have an old script that no longer serves a purpose? As Kondo would say: Thank it for its service, and let it go.
It's also okay if what sparks joy isn't necessarily beautiful, but instead, is just plain useful. Tools and code may be beautiful in the sense that they are usable, modular, and productive. I found joy in switching from grep to silversearcher, which runs faster and finds patterns more reliably.
Finding joy is about taking the time to assess what parts of your process and job don't bring joy, and why. Some things can't be changed, and there will always be an on-call rotation. But defining goals for your team, and thinking about the least and most pleasant parts of your work, can clarify what needs to change.
Visualize the destination
Followers of the KonMari method are urged to visualize their ideal lifestyle and make sure they have concrete goals for achieving that lifestyle. Apply this concept of working backwards from your end goal to your workflows and application delivery process.
Imagine that you're on an island with a piña colada in one hand and your laptop in the other. You see there’s a new CVE and patch out, but no need to panic: You've got automation that grabs the associated patch and automatically updates all affected systems. You take another sip of that piña colada, and use the umbrella to click "Build" on your Jenkins release pipeline.
All joking aside, having clear goals for your team is critical to success with anything, but it's especially important for your IT team. Knowing your destination is often team-specific and depends largely on the size of your organization.
Ask yourself what kind of teams you are working with and what technologies you are managing. Then gather your stakeholders (virtually or physically) and discuss ideas and goals for the organization.
Just the exercise of talking about where you want your processes to be will be helpful in getting everyone on the same page as you start to reassess the status quo.
Tidy up by category
Kondo advocates tidying up by category, not by location. Her categories may not translate directly to IT, although I could definitely stand to lose some conference T-shirts that I've acquired over the years. But there are spiritual equivalents in IT.
While Kondo suggests clearing clothes first because it’s low-hanging "clutter-fruit," in IT this correlates to one-off scripts living in your homedir. I have one now that stops services that conflict with running our acceptance test suite locally. Instead of one-off scripts, I should have (and have since writing this!) added that as part of a local pre-suite to the tests, along with a script to restart them once tests finish.
A good place to start? Automate the destruction of resources. For example, when a developer requests a virtual machine from our VCenter, it's set to automatically expire after 12 hours but can be modified by the developer to last longer if necessary.
This ensures that resources aren't used longer than needed and that you don't unexpectedly destroy resources that need to exist. This doesn't work for every case, but often establishing routine destruction with the ability to modify where necessary will result in cleanup of unused resources instead of waste.
Store items by frequency of use
Store items according to how often you use them. The idea in the home is that you should store the coffee maker you use every morning in a convenient place, while the fancy wine glasses you only use for parties can be stored in the top shelf above the refrigerator.
Similarly, examining what processes and tasks you perform frequently reveals opportunities to automate and make those tasks easy to perform.
For example, engineers across my organization frequently need a Linux, Windows, or OSX VM for a short amount of time. This might be for testing, development, or use as part of a multi-node configuration. Since this is common for a lot of people, we've built robust, fast automation around the workflow.
We create VM instances based on our library of images and make them available in the VMPooler, where anyone can request a pre-provisioned machine instantly. We even have a nice command-line tool for interacting with the Pooler API.
The VMs then expire after 12 hours, unless their lifetime is modified, since these are intended for one-off tasks and not for long-term use. As a result, engineers can test more easily (and therefore do more testing!), and we have saved approximately seven bazillion hours of developer time over the years.
Step toward a leaner infrastructure
The KonMari method isn't just about having as few things as possible or tossing out what's old. In the IT context, it's about taking the things that are meaningful to your IT team now, or could be meaningful to them in the future, and making them as functional and accessible as possible.
Define what your organization needs, and you will start having more purpose-driven conversations about resources, tools, and a leaner infrastructure.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
