Patterns emerge from practice

Over the past two weeks, Garen has been refactoring a bunch of Yetto's integration code. You see, all of our plugs were built as separate applications that run outside the main Yetto app. As we built them, we started to notice common elements between plugs, so Garen took that and put most of the commonalities into a template. To build a new plug now, we run a command and 80% of the code is already written. (And I hope he writes a blog post about this someday).

Ward Cunningham would say that "patterns emerge from practice." It held true for us, and our plugs' patterns became clear as we built more of them.

What any of this has to do with Support

"Patterns emerge from practice" is an alliterative way of saying that you probably don't know the right structure for what you're doing until you start doing it. You know what you're building and how you're building it, but the pieces that get repeated throughout your code likely won’t be identifiable until you start to see them repeating. If you think you know what they’ll be, I’m sorry: there's a good chance that either you're wrong or you missed something.

In other words: don't try to build a new framework for a new project. Let the shape of the project dictate what the framework should be. Solutions appear after hitting the same problems a few times.

Garen’s recent work got me thinking about how this manifests in the ways Support teams operate. There's this idea that we should build things that work, then build a framework based on what works, then use that framework for the next thing so it goes faster, has fewer errors, and doesn't occupy a bunch of headspace that could be used to write Steel Magnolias fanfic (or, y’know, doing more important work). That whole idea makes me wince a little. It hurts because I know that a lot of Support teams are doing this backwards and that it slows them down. And because I was one of those Support people and made that mistake more than once.

In Support, we often need to develop new processes and policies on the fly to account for new problems. We usually stop afterwards to look back at how we handled the situation and codify some sort of process so that if it happens again, everyone will know what to do. Take a data leak at a SaaS company: the first time it happens, you scramble to fix it and communicate the problem and the fix to everyone who needs to know. After that, you write down a process so that the next time there's a data leak, you know exactly what to do. (Hopefully you never have two of these, but I'm sure most of us have seen worse.) So far so good.

The place where I think most of us get this wrong, though, is when we try to implement our idealized process.

How we work

You spend a few days developing a workflow for your team to handle a specific type of problem that your customers run into. Often that involves work with another team, whether that's providing or collecting information from someone else, somewhere else. You run the process by the team, by all of the other teams involved, and everyone agrees that it's the best way to handle the problem.

Then you try to build the process into your tools and things start to fall apart. Maybe your help desk doesn't allow a certain automation that you need, or maybe the data that you need to make a decision is only available to people with access levels that most of your team don't have. You start to make compromises based on your available tools and info and before you know it, you've implemented a process that's about 60% as useful as you wanted. You ask around and find out that other Support teams at other companies had to make a lot of the same compromises for the same reasons because you're all using tools that were made for "support," the general work, but not your company's Support team and the specific issues you have.

What we imagine

I have a lot of opinions; you're reading them in this here blog, so that shouldn't surprise you. It's generally true that software carries the opinions of the people who make it. The problem here is not that nobody building support tools knows how customer support works, it's that nobody knows how your customer support works. The opinionated tools you use push you to work in ways that aren't always best for you, your product, or your customers.

Yetto is also opinionated software. Our opinion, though, is that you understand your team and your customers and your work better than anyone. Better than us, that's for sure. We want you to have tools that let you decide how to best support your customers. Your tools -- including your help desk -- need to be flexible enough to match your needs, not what we imagine those needs to be. And they can't be so generic as to be useless — how many apps have you tried that are just gussied up kanban boards?

When you build out a new process or workflow or automation, your help desk shouldn't be in your way. It should give you more options and more ways to view your work. Your tools should spur creativity, not frustration. Ultimately, you should be able to take a process that works for you and map it onto your help desk. That should make your life easier in the future, and it should free you up to make more difficult decisions rather than repeating the same decisions and the same actions over and over again.

-———

Over the last couple of months, we realized that we could extract even more, so Garen's been working on some cool behind-the-scenes upgrades that will make it easy and faster to build new plugs for all of you. Sign up for our newsletter below to get all the news and updates as they happen. Better yet, sign up for Yetto and see how it works for yourself!