Let’s say you’re a blacksmith who makes cast iron skillets. You make one shape of skillet but you make it really well, so you open a small shop in town where you can make and sell them. When customers come in, you stop what you’re doing (presumably making more skillets) to attend to them. You like talking to folks who like your skillets. You build some relationships with people in town, and start getting repeat customers who own restaurants nearby.
Word gets around. Business picks up. And the interruptions slow you down. So you hire someone to handle customers at the front of the shop while you make skillets behind them. You can still see the customers and talk to them occasionally, but you can also focus on your work. You’re making more money and everyone is happy.
The person who handles the sales, though, is getting busier and busier. They’re selling skillets all day but they’re also handling returns, questions, and complaints, so you hire a second person to take on the post-sales work. Anyone who needs a refund or a repair goes to the new person’s counter to have their situation handled by someone with time to focus on them.
You’re busy making skillets so you don’t have time to follow up with every customer, but you talk to your employees every day to see how things are going. Sales are up, returns trickle in, you get a handful of pans to repair every week, and things are going well. The sales person tells you what’s going well and the support person tells you what isn’t, but not in detail. Just enough to make sure things are running smoothly. Revenue’s up, so it’s fine.
But the detail’s important. People return skillets for different reasons (not big enough, too deep, too heavy, not heavy enough). A lot of them do have the same reason, though; the handles get too hot, which makes them hard to use. Something in the design needs a tweak, but you never hear it.
I think you get the point, and none of you are making skillets. You’re probably making software, but your Support team is in a similar situation. They’re getting loads of product feedback but you aren’t hearing it with the kind of detail you got when you were talking to customers directly (assuming you did at some point). All this customer feedback is in your helpdesk with a couple dozen (or a couple hundred) tags. Or maybe Support creates Jira or Linear or GitHub issues for the Engineering and Product teams, but it’s never clear how those relate to the current product roadmap or the company’s strategic priorities. So the feedback gets shuffled to the back of the queue to deal with later, if ever.
The problem seems obvious when it’s three people in a small shop. Why aren’t you, the blacksmith making the skillets, talking to customers or getting better feedback on your product? The customers are right there. Why isn’t your employee giving you information in ways that can help you decide what to change or improve or how to expand your product line? It looks easy, but even three people in a room can be so heads-down that they stop sharing useful info, and when that expands to a couple hundred people you don’t always realize how disconnected you’ve become from the customer. When the little blacksmith shop becomes a plant with smiths and designers and product managers and engineers and quality assurance directors, it’s not clear who should be getting what feedback in the first place, let alone how.
A true story: There was a Support team of about 10 people who would get lots of product feedback from customers. Sometimes it was explicit feature requests, but often it was a customer problem that could be solved with some change to the product. There wasn’t a bug, but there was a difference between the customer’s expectation and their experience. This team would save all those nuggets of informative feedback and in markdown files organized by month. There the feedback would sit, waiting for Product. Forever.
This sounds terrible to you, maybe. Or familiar, because let me assure you that lots of teams are doing something similar right now. Or they’re doing even less, because many Support teams are tasked with talking to customers and not with solving product problems.
Once you see it, you can’t unsee it. Support teams are part of the product development cycle, but they’re usually completely disconnected from that cycle. Product teams aren’t getting useful information from Support and are therefore missing key feedback that should be informing product decisions.
We’re just turning off a feedback loop that already exists. How do we turn it back on? You’ve probably heard people talking about “Support getting a seat at the table” and this is what we mean. Talking up the “value” of the team isn’t going to earn us more than some kudos and a pizza party. What we want is to be part of the process that continually improves what we offer customers.
Some larger companies have Voice of the Customer programs (VoC) built around the idea that customer feedback should be filtered and funneled back to Product teams. This is great! It’s also strange that it has to be a specific program with a specific owner instead of a core part of the Support team’s role. Waiting until you’re big enough (in headcount or customer count or revenue) to implement a VoC program means you’re wasting information. It should be a given that Support is responsible for taking feedback, data, and customer stories back to the Product team.
Lots of companies are trying? But more are getting it wrong than right.
The worst is when Support teams put a bunch of work into packaging up their data and sending it to Product, and it’s ignored.
Your Skillet Support Representative spends all week talking to customers and handling returns and handing off repairs and answering questions about the best way to fry eggs. At the end of the week, they write up a five page report about everything they’ve seen and heard and hand it to you. You skim it, see some notes about butter vs. oil that don’t actually help you make skillets, toss it aside and get back to what you were doing. Your rep feels crappy. Customers keep burning their hands on skillet handles. It’s a lot of work, and it’s not helpful to anyone.
In many companies, Support eventually stops packaging up feedback and tells Product they can search the tickets if they want and that’s that. Everyone goes back to their siloes. Their angry little siloes.
Other Support teams put together weekly, monthly, and quarterly reports with reams of customer data, quotes from real tickets, and lists of work that Support thinks should be prioritized. Then they get mad when the Product and Engineering teams glance at it and put it to the side… but usually haven’t asked why it didn’t help. Did it come at the wrong time? Was it all irrelevant to what the other teams are focusing on right now?
You don’t know if you don’t ask, so what if Support asked Product what it wants? You’d be amazed how easy that is to answer and how infrequently Support teams ask. Product teams already have a strategy and a way of managing what they’re working on. Throwing information that doesn’t relate doesn’t clarify anything, so they ignore it. So ask. Ask what they want to know more about, how they want to see that information, and what kind of data helps them right now.
Where do you start these conversations? Here:
That Support team that was putting all its customer feedback in unread markdown files eventually sat down with some Product Managers and talked about what kind of information was useful to them. Not just “product feedback” but “feedback about features A, B, and C from customers in cohorts X, Y, and Z.” Support couldn’t have guessed exactly which parts of the product were most important to the other teams at that moment, and they wouldn’t have known how Product was thinking about customer cohorts. Until, of course, they asked. It wasn’t a complete and perfect solution, and there was still some friction between teams, as there always will be at large and growing companies. But it was a start, and every month the Product Managers would come back with feedback for Support on how to iterate on their data to make it even more valuable.
Support teams want a seat at the table. We want other teams to listen to us. We have valuable insight. But sitting at the table requires us to speak the language other teams are using, and to focus on the topics that other teams are talking about.
Sometimes you’ll bring in a new topic. “Hey, I know we’re focused on features A, B, and C right now, but we had a spike in questions about feature D the past few weeks. There might be something there worth exploring.” Sometimes that’ll raise more questions and pique the interest of other teams. Sometimes it won’t and those other teams will think it’s a distraction and THAT IS OKAY. The role of Support is to feed customer information back into the company. The organization as a whole will determine what is useful and valuable and actionable.
Sounds easy? Well. It’s not. But it’s simple. It’s just talking.
Go. Right now. Go talk to your Product Managers and figure out what would help the product. Make sure your feedback from customers gets translated into something that improves the product and company. You all work as one big team, and thinking of Product and Support and Engineering and Design as isolated organizations that don’t know how to talk to each other is holding everyone back. Everyone’s gotta pull up a chair.
]]>This isn’t a post about the lessons I’ve learned or why failure is actually success. It’s not even about what I’m doing next or how much time I’m taking off to reflect.
There are a lot of LinkedIn posts and blogs and TikToks and YouTube videos of founders talking about the journey, whether it’s successful or not. There’s always some advice, maybe some talk about the emotional tolls, and often a spin about how even when it’s terrible it’s great.
Maybe all of that’s true, maybe it’s subjective. Maybe it all depends.
Doesn’t matter. I will simply say that the past three years of working on Yetto have been some of the most fulfilling and rewarding of my professional career. It has been great. And it’s been great because of all the people I’ve had the opportunity to work with and meet and talk to and hang out with.
I’m not listing people to thank, because I’d inevitably leave someone off and then I’d feel bad that they feel bad. So I’ll just thank some categories and you, dear reader, can slot yourself into whichever one you feel is most appropriate.
Thanks to our friends and families for putting up with us. And to our investors for believing in us and our ideas. And to everyone who had a hand in building stuff with us - designers, developers, illustrators, editors, marketers. And, of course, to the customers who came on this little ride for as long as they could.
Above all, though: thank you, support community. The friends we have there have been our best supporters (obviously), advisors, promoters, and partners. We couldn’t have done any of this without you. I can’t imagine a better group of people to surround myself with.
To answer at least some questions, I don’t know what I’m doing next. Not yet. For now, I’m going to be spending time with my support community and building some tools for them and myself and anyone who needs something.
If you’re in ElevateCX or Support Driven and want to chat, you can always message me there. Anyone else has to email. Them’s the rules.
See you in the queue.
]]>I don’t want to keep talking about AI. It’s everywhere and everyone has an opinion. But I have some strong feelings about support metrics and this is starting to cross a line.
A lot of companies are now measuring the rate of AI implementation in their organizations. With mid-year performance review season upon us, lots of those companies are using AI usage rates as individual performance metrics.
Please picture me grimacing as I wrote that.
Can you imagine? Using the amount of time spent using a tool as a gauge of how well a person is doing their job? When their job title is not “Tool User”?
You don’t have to imagine it, because you’ve seen it or know someone who has been graded that way. Or your performance metrics now include “AI usage” as a factor. Or you’re using that metric to review your people.
Look, I can understand using AI implementation as a company-wide, or even team-wide, metric… for some things. When the CEO or CFO or team lead wants to see if they’re getting their money’s worth out of a software investment they made, it’s good to see whether the team is using that software. Low usage numbers usually mean that the software isn’t that useful, or it’s a niche tool.
But at an individual level, why does that matter? It tells me that some of these teams don’t know what success actually looks like, so they’re looking for proxies. That’s fine, we all do that. It’s hard to know whether you’ve delighted your customers; there’s no objective Delight Scale to measure against, so we’re all looking for the next-best thing.
In Support, we’re no strangers to using proxies for success metrics. Customer satisfaction scores and net promoter scores are the closest things we get to “customer happiness” ratings, and even those are deeply flawed. We have to be careful about what insights we’re taking away from our proxy data, though. Some proxies are more proximate than others.
Take first reply times: We assume they’re a good indicator of how well the team is doing, or how well each support agent is doing. But if you tell the team that they’re judged on first reply times, they’ll find ways to make first reply times go down, and those ways may not actually support customers. They may even be at the expense of the things you should care about, like customer satisfaction or issues resolved.
Knowing that, why are we looking at AI implementation as a personal success metric in Customer Support? What do we assume when we make it a proxy for the things that we care about? It assumes, for one, that using AI tools correlates perfectly with customer satisfaction. Are we all comfortable with that? Really?
I’m picking on AI implementation because it seems absurd to use it as a factor in performance reviews for support teams, but I want you to scrutinize all your team’s metrics. Which ones are measuring things you care about? Which ones are proxies? And which ones are proxies of proxies that aren’t telling you anything at all?
I don’t have the answers for you. Those are an exercise left for the reader, as they say. So think about it.
]]>Every so often, the customer support community resonates with a specific conversation. For a while, everyone was talking about whether or not Support is a “cost center” and what that means and whether that’s good or bad. Recently, the conversation shifted to the value of Support.
I’ve been asked this question a couple of times over the past few weeks, usually phrased the same way:
How do we show the value of Support?
You may be shocked to hear that I have some thoughts. They boil down to: (1) define your terms and (2) know your audience.
There are lots of ways to talk about value. Is it the importance of a team to the operation of the business? How much the customer relies on Support for successful and continued use of the product? Those are important and valuable, but we all toil in the yoke of capitalism, where “value” means dollars (or whatever your local currency is).
Okay, so we’re trying to calculate the financial impact of the Customer Support on the business. We have options there too, but the general feeling among support professionals is that Support both reduces churn and encourages upgrades and/or repeat purchases, making the team at least partially responsible for some amount of revenue. We’ll just do some math!
Or will we? Calculating a specific revenue impact is difficult for two reasons.
First, there’s no straight line between a customer support interaction and a decision to churn or not churn, or to upgrade or not upgrade. Positive post-sales interactions (whether with Support or another team) can foster positive feelings that can lead to renewals and upgrades. But not always, and not all at once. Is Support responsible for 100% of renewals from customers who have interacted with them? I doubt it, and I don’t think anyone else believes that, either.
Second, customers can and do churn despite positive post-sales interactions. Maybe the product didn’t meet their needs. Maybe the software wasn’t being maintained to the customer’s satisfaction, even though the support and success teams have done everything they can to make the customer happy. Should the Support team be penalized for churn they can’t control? I don’t think so, and I think most people would agree that putting the blame entirely on the post-sales teams does little more than shift blame around the company.
Given that, putting a hard number on revenue impact is guesswork at best. Some companies are trying to make it more concrete by using their Support teams as upsell channels. That makes the support > revenue line clearer, but at the expense of turning Support into a Sales team. It’s hard to see this as anything but a reframing of the “Is Support a cost center?” conversation. We haven’t made progress there if we only look at Support’s “value” as a number on a balance sheet.
Let’s take a step back and ask: why are we doing this anyway? Why do we want to quantify the value of Support? Who do we hope will see that value?
To be “data-driven” I asked a few people why they wanted to quantify Support’s value. The answers were a little muddled; there are multiple reasons, and everyone I talked to listed more than one, but most clustered around:
Each of those uses a different definition of “value.” In the first case, we’re talking about the financial impact of the team - difficult to quantify but logical as a goal. If you’re providing more financial value to the company, you should be given more financial support for your work.
In the second, value is measured in product and customer knowledge. The Support team has more direct context on how the customers use the product than Product and Engineering, and that information is useful for product decisions like what to build, when to deliver it, and how to present it to customers. That ultimately shows up as revenue, but not directly and not immediately (as usual).
The third goes a step further and feels the most urgent. Some companies have shown that they are willing to replace Support teams with software, either in whole or in part. The Support community has rightfully predicted that it would be a disaster, but it hasn’t stopped executives from ditching their Support teams for bots. This leaves Support leaders scrambling to prove that keeping a human support team is in the company’s best interest, which we usually do with a mix of revenue data, product usage data, customer interaction data, and support-derived product insights to prove that just having a Support team is good for the business.
Quit? Take over the company? Start your own company?
Yes! But short of that, understand what kind of value you need to demonstrate to accomplish your goals, and then get that information in front of the right people.
First, decide what value you’re talking about. Are you meeting with the CFO to discuss next year’s budget allocations? Bring churn and renewal calculations. Showing that putting more money into the Support team drives revenue for the business will help you justify hiring more staff, expanding into new regions, and buying more software licenses.
Are you trying to get Support more involved in product conversations and decisions? Revenue numbers aren’t useful here; it’s time for customer data and qualitative insights. Show that you have information other teams lack and that your team’s data compliments the Product and Engineering teams’ data, and you’re more likely to be asked to pull up a seat.
Are you trying to convince the CEO that the human Support pros are worth having at all? That’s a tougher challenge, but we now have data on what happens to companies that let their Support teams go, and the data is not in the companies’ favor. It’s almost impossible to A/B test the Support vs. No Support scenarios, but we can use these recent stories to show that having a Support team is important to customers.
That sounds hopeful, but there’s still bad news: it might not work. Executives who don’t understand or respect (value) the contributions of the Support team aren’t interested in the team’s input (value) in other parts of the business. And if they already don’t want our input, they aren’t interested in our estimates of what we contribute to the bottom line. Your audience might not exist at your current company.
I’m not suggesting that these are lost causes or that we should quit and walk into the woods. (Yet. I will probably suggest that in a future blog post, and fully support anyone who’s already walking.) I am suggesting that we stop looking for metrics and hard numbers to “prove our value” when the people we’re talking to didn’t use metrics or hard numbers to decide that our contributions aren’t important. The best outcome might be getting the resources you need, but it might just be that you stop banging your head against a C-suite wall and spend that time zeroing out the queue. At least then you get rid of the headache.
Justifying support budgets, support involvement, and support existence are each important, but they’re different. When you start to get that itch to prove your value to your company, pause and ask: why? What kind of value do you want to show? To whom? What do you want them to do about it?
Without understanding your motivation and your needs, you’ll waste a lot of time. You’ll gather data that doesn’t make your case, you’ll talk to people about things they don’t care about, and you’ll end up right where you started but more frustrated and with a bigger backlog in the queue because you haven’t been looking at that.
We’re busy. Support is a valuable part of every business, whether you quantify that in dollars, ideas, or customer happiness. Don’t waste your time trying to convince people who aren’t listening with data they don’t care about.
]]>Leading a team during turmoil is impossible to prepare for; that’s part of what makes it turmoil. Every situation is a little different. Sometimes a lot different. There’s no playbook for managing a team during a global pandemic or a constitutional crisis and a lot of managers had to figure it out fast.
The unexpected could be anything from a political revolution to an economic collapse to a natural disaster. Maybe your company is facing a big legal challenge, or your office burned down. (Too dramatic? Turmoil is dramatic.) You can’t really prepare a team or a team leader for any of these. The best you can do is have clearly articulated ground rules for your organization based in your (hopefully already clearly articulated) values.
Many folks who have been on a team during chaos (cough 2020 cough) will tell you that their company or their direct manager handled it poorly. I’d wager that most people don’t think management did a particularly good job when things got hard. I hope that assumption doesn’t apply to you, but chances are high that more than a few of the people reading this have some bad memories. Of worrying about losing your job during a slow job market. Of trying to figure out how to balance work and caretaking. Of having to keep ticking off your OKRs while your cortisol levels skyrocket every time you check the news.
I know because I was there, too. I was managing a support team in 2020 and 2021 and I’ve talked to a lot of other people leading teams during Covid-19 and the BLM protests. I don’t think I did the best job I could have but I do think I learned a lot, and I think the failure modes that I’ve seen are useful to talk about. Not to fully prepare, which is impossible, but to be aware.
There’s no playbook for success, but there’s a playbook for failure. The two ways I’ve seen people fuck this up are:
This is the most common scenario: You’re a manager trying to keep a team operating. You’ve got your Director or VP or C-something telling you to keep numbers up, you’ve got your own job to worry about, and you’re also living through the health crisis (2020) or financial crisis (2008) or any number of other crises. That gets pushed down to the team, where everyone is already stressed and trying to keep their heads above water.
The focus is on the business, because the show must go on. We tell our teams to ignore their outside problems while they’re at work - “Put your problems in the cubby,” as my mother says - and focus on the job. And maybe this works for some people for whom work serves as a needed distraction from outside stressors, which is fine, but it doesn’t work for everyone. Chances are you’ve seen this happen to a team and the team slowly (or quickly!) falls apart. People quit because of the stress. People “underperform” and get put on performance review plans and are eventually let go. The people remaining are less productive, even while there’s more work for them to do, and morale is at the bottom of the Mariana Trench.
The problem here is that leadership didn’t treat the team like people first and foremost. The business is a machine and the machine needs smoothly running components. But it almost never works that way, people are not components, and pushing them until they crack is almost never a good idea, especially when the outside world is also pushing.
I know, I know. But stay with me.
I see a lot of managers, especially new managers, take a heavy people-first approach that backfires. People are the core of the business. They aren’t cogs. But they are also there to do a job, and a leader’s role is to help them do the best job they can while they’re there. (Note: the best job they can do during the time in question, not the job the C-suite thinks they should be doing.) You were on a team not so long ago and remember how it feels.
The inclination with the typical people-first approach is to lean deeper into the humanity of your team members and help everyone get through this together; you want to give people the space they need and not add to an already-stressful situation. And as with the business-first approach, this works for some people! But it doesn’t work for everyone, or for the business paying everyone’s salaries.
In an effort to treat people like people, you make the team’s mental health your number one priority and try not to pressure people to focus on work. With less motivation to push the business forward, teams miss deadlines and customers are left hanging. Churn follows, creating a new financial problem for the business that adds more stress to the team.
(It can help to have space to talk through what’s on your mind with people going through the same thing. However! Remember that (a) you’re a manager, not a licensed therapist and (b) that’s not what everyone wants or needs, especially at work.)
We need to remember that we’re part of a team that was put together in the service of a business. It’s not glorious, but it is important: If the business suffers, our jobs and paychecks suffer. We have a collective responsibility to try and keep it operating even when the outside world is adding to our mental and emotional loads.
You were probably expecting me to say to always treat people like people, or something like that. And you should, but it also doesn’t help people for their company to go out of business or do another round of layoffs.
As Garen’s mother used to say, “If you fail to plan, you can plan on failing.” There are things we can do before an outside force throws our teams around, no matter how unknown that unknown is. Before a market downturn prompts a wave of layoffs or dire wolf rabies rips through your community—that’s the time to think about how to prepare.
Where to start? Talk to people. That’s step one.
In both examples of failure, there are people who react well and those who react poorly to the leadership styles. This doesn’t have to be a guessing game; you can talk to the team and find out what works for each person. And not just in a crisis - you should know your team members well enough to know what motivates who, and what adds stress, and how everyone works together. What works for your people, and your team as a whole. Don’t wait until the shit hits the fan.
Step two: Use what you just learned, and lead.
You’ve figured out how people react to stress and change, and you’ve talked to them about what they need to do their best work. Now make it happen! You’re the leader, so use your power on behalf of the team. Change those OKRs and quarterly goals. Shift schedules and expectations where necessary. Take the bigger picture into account in performance reviews. Be a buffer, and advocate for your team when your boss’s boss’s boss tells you to “do more with less” or “put the pedal to the metal regardless.” (Can this be a little uncomfortable for you? Yes. Sometimes being the leader is uncomfortable.) Support your peer leaders as they do the same.
You, the team leader, have the power to give people the space and the support they need to get through difficult times together. Use it.
]]>“Take some time off. Everyone needs a chance to relax and recharge.”
You’ve probably heard that a lot lately. It’s great advice, but for Support Professionals it’s easier said than done. Customers don’t stop needing help because you’re on vacation. And during the holidays? Seems like customers need you the most when the rest of the company is on a holiday break.
Time off isn’t just a holiday issue, either. Does your team participate in annual work retreats as fully as other teams do? Does everyone in Support get at least one uninterrupted week of vacation per year? How about two or three weeks per year, like most workers in the US?
I’m going to guess that your answers are “no.” I’m also going to guess that the idea of taking that much time off causes stress instead of relieving it, as you think about how the understaffed support queue will look and your eye starts to twitch.
It’s a problem. And from what I’ve seen, it’s industry-wide. But you and your Support colleagues really need some time off, so let’s look at the most common ways Support teams handle vacation—and their pros and cons.
When I was managing a small Support team, I kept the team operating in shifts with reduced hours: each day, a small number of team members are working and the rest get that time off. The size of the working team and the length of each shift (half days, full days, multiple days) will depend on your team size and customer needs, but the goal is for each member of the team to have roughly the same amount of time off. On my team, this worked well enough for holiday breaks and company retreats—it’s particularly useful for week-long blocks where the company or the team will be in some reduced capacity—that we did it for a few years.
Pros:
Cons:
When you need to maintain customer response times, start thinking about bringing in outside help to supplement your team with extra people so team members can fully unplug. There’s a range of ways to do this—you can hire seasonal or part-time contractors or increase the usage of a pre-existing BPO vendor. No matter where the help comes from, it’s important that anyone interacting with customers be fully trained before being let loose in the queue, which often requires thorough documentation.
Pros:
Cons:
Like shopping in your own closet, you can bring in help from other teams within the company. While I personally advocate against all-hands support, many teams use this as a way of spreading the work around the company.
Pros:
Cons:
The most extreme option is turning off support for the week. Maybe leave some team members on call for urgent issues, but let customers know that your team is away and let them take the time off. Some support tools (like Yetto!) let you automatically triage support requests, so you don’t need to have someone monitoring the queue; when something urgent comes in, have your system notify the person on call so they can drop in as needed.
Pros:
Cons:
No matter which option you go with, you’ll need to do some up-front work to pull it off. Clear documentation makes it possible for non-regular staff to handle all the situations they’ll see in the queue. Training new staff—outside contractors or colleagues from other teams—takes time. Scheduling support coverage requires research and planning to get the right number of people working at the right days and times for your customers. Changes to automated triage workflows need to be set up before folks log out for vacation. Even choosing the “turn it off” option takes prep, so your backlog is cleaned out and your customers aren’t left hanging.
Don’t try to jump into vacation mode without preparation; the advance work gives your team and your customers the best chances of success. And most of the prep, like updating documentation and training materials, is good hygiene for the team anyway.
These are a few of the more common ways to give your team a break, but there are surely others that I didn’t mention or haven’t heard of. And these can all be mixed and matched in ways to best suit your organization. Maybe you’ll give everyone some time off and let other teams share the on-call rotation, or maybe you’ll do shifts for a few days and close completely for a few days. There’s no magic solution—it depends on your team, your company, your product, and your customers. Do what works for you!
I hope you and your team got some time off over the winter break, or that you’ll get some now that the holiday rush has passed.
]]>I’m not particularly worried about any of these companies shutting me out with no warning, but it’s possible. People get banned from social media platforms all the time. People lose their Gmail accounts, which have become keys to people’s online identities. And none of this addresses the idea that we’re supporting these companies financially, either directly or by putting all of our information on their platforms to feed to advertisers.
It makes sense to want to own some little corner of the internet for yourself. To put your own little web site up somewhere and say what you want, how you want, to whomever you want. That feels like what the internet used to be like back in the 90s. I regularly see people on Bluesky or some other platform talking about how we can reclaim some of the internet for ourselves, without being reliant on one of the few mega-corps.
But is that realistic?
I spent some time over the past few weeks giving it a whirl. Here’s what I did and what I learned.
Let’s say you want to set up a website for yourself. Just a little blog that you can share with friends. There are a couple of ways to do that. A non-exhaustive list:
I wanted to own as much of my site as possible, so I went with the do-it-yourself option. There was a Raspberry Pi sitting in a drawer in my office, which seemed like the perfect candidate for a personal server.
The Raspberry Pi got reformatted and hooked up to my home network. I had migrated balevine.com from WordPress to Jekyll a few months ago, so I only had to move the files to the Raspberry Pi and tell my domain registrar what my new IP address would be.
That’s where things got a little tricky. I use a small mesh network to get stable wifi throughout our apartment, which is connected to a router supplied by our ISP. To set my site up, I needed to set up port forwarding for the router to the mesh network, and then from the network to the Raspberry Pi. None of that was particularly difficult, but it was a bit of a pain to find all the settings on all of the devices and get it all working together. I also had to configure the Raspberry Pi to serve the static Jekyll site at the external address. Then I had to get the external IP address of the network to direct traffic to the Raspberry Pi. All told, the whole setup process took a couple of hours to go through. Now that I’ve done it, I could probably set the whole thing up in about 10 minutes. But reading through docs and switching between networks to get to the right configuration panels took some time.
However, my network has a dynamically set IP address (as I think most home networks do by default). Which means the IP address could change without warning or notice of any kind. Restarting the router will reset the address. Sometimes the ISP will just change it on me for what seems like no reason. If you’re using the internet like a normal person, you’d never notice and wouldn’t care. But if you want people outside your network to be able to access your address - for example, if you’re hosting a web site from your home network - you ideally want a static IP address. Failing that, you want to know when the address changes and to update your domain records with your domain registrar as soon as possible.
Over the holiday break I hacked on a little Bash script that solves this problem for me. I moved my domain record management to Cloudflare, which offers a nice API for this sort of thing. Then I wrote a script that periodically checks the external IP address of the network. If the IP has changed, the script updates the settings in Cloudflare and stores the new IP address for future reference. It’s not perfect, but it works for what I’m doing. This was then set up as a cron job that runs every 15 minutes, which means I’ll typically have no more than 15 minutes of downtime if and when the IP changes. It’s a little hobby site, so that seemed acceptable.
To finish it all up, I wrote some scripts to let me write new blog posts on my laptop and upload them to the site. They run a Jekyll build process and then use rsync to copy the built site files to the Raspberry Pi. It has to work from within the network (if I’m at home) or from an external network (in case I’m at a coffee shop or something). That was another half hour of Bash scripting, which was a great way to avoid watching National Lampoon’s Christmas Vacation for a little while.
There we have it. A live web site, hosted on my own hardware and running through my home network. I could have used a third-party service to handle the dynamic IP changes, but I wanted to rely on as few external services as possible. The registrar is unavoidable, since you have to get the domain name somewhere, but otherwise I don’t want anyone to be able to shut me down. Except my ISP, I suppose.
This shit sucks.
It’s absolutely possible to set up a server yourself and claim some of the vast internet space as your own. Divesting yourself from most of the big tech companies requires some technical know-how, but not a ton. Most of this stuff can be found online and nothing I did was new or innovative in any way. But I’ve been futzing with computers for decades, so my comfort and familiarity with this stuff is beyond that of the average person.
Should we expect people to learn about port forwarding and domain records and Bash scripting and all this other shit just to have a silly little website on the internet? And even after doing all that, I still have to pay someone a few bucks a month to keep my domain up. It’s unreasonable.
Of course people stick to Instagram and Facebook and Bluesky and Medium and Substack. Post all you want for free. Don’t worry about how the internet is held together. Most people won’t get shut down out of nowhere, and most people probably don’t know or care what the tech companies are doing with their money. There’s no ethical consumption under capitalism, after all.
Setting up your own local server is a pain in the ass that you should only do if you’re looking for another hobby. I’m glad I set up my server and that I have my site here instead of on WordPress or AWS or wherever. But ultimately I don’t think it matters. Most people can’t and won’t do that and will have to rely on some big tech company. We still rely on those companies for a bajillion other things, anyway.
That might sound defeatist. And maybe it is a little bit. I prefer to think of it as pragmatic.
]]>Hey, Support friends. This one is for the Product and Engineering folks. Send this to them if you like, and then go take a coffee break. You deserve a moment to yourself.
Customer Support teams exist to solve problems — specifically, the problems of people who use their company’s products. If your product worked flawlessly and did exactly what every customer wanted and expected, you probably wouldn’t have a Support team at all.
Your product isn’t perfect, though (sorry to break it to you). Nobody’s product is perfect, so everybody has Support people who talk to customers all day every day. All they do is answer questions that customers call or write in about, right? They react to customers, fix their problems, and then everyone goes home happy.
Wrong. That’s a limiting belief and a huge missed opportunity for everyone. Open yourself to insights coming from your Support teams. Your product teams — and your customers — will thank you.
People in most of the Customer Support circles I travel in talk about “the value of Support.” They talk about how to bring value to the company, how to show value to the C-suite, how to prove their value to other teams. For years, I’ve heard people plead their worth to those in charge. Wherever Support Professionals gather, this conversation happens.
It’s great that we’re talking about how important this work is; thousands of us do this work because we care about it and want it to be better. But we don’t seem to be convincing anyone outside our smallish circles that the work is valuable.
The core sources of value Support Professionals tend to bring up are:
All of these improve the customer experience and, in most cases, improve the company’s bottom line.
But.
All of the things we value from Support teams are reactive. Everything on that list adds value to the customer experience after a product is built and shipped and in a customer’s hands.
We’re missing out on something big here. And we’re devaluing the work of Support by limiting it this way.
Your Support team is sitting on a mountain of data regarding how customers use your products, and it’s a big mountain. They know what customers want, expect, and need. They know how customers act (even though they would often like to forget everything they know about how customers act) and have insight into what they’ll do with a new product or feature - how they’ll react to it, how they’ll try to use it, whether it will meet their needs and expectations. Product teams pay large sums of money to contractors and consultants for this kind of data.
If you’re lucky, your company has a user researcher (or even a user research team) specifically tasked with getting this info. But your Support team already has it… though it’s probably uncategorized and disorganized because nobody ever asks them about it. Support teams are asked for feedback about products that have shipped (sometimes; oftentimes, we aren’t even asked about that). But I very rarely hear about Support teams being asked to weigh in on product conversations during the earliest stages of development.
There are two benefits to bringing the Support team into product conversations as early as possible:
That second point is huge… and is almost universally ignored. In my experience, bringing Support into Product and Engineering conversations at every stage of the product development cycle yields better products that are better received by customers. (My data is anecdotal, but I stand by it.)
When a Support person is “in the room” for product conversations — from first idea to first release — the product will likely have fewer edge-case bugs. The Support team doesn’t just know what bugs customers run into: they know why the customers run into them. This insight can help predict what kinds of edge cases new features and products will need to handle.
The Support team can also give early feedback on product direction. What will customers think of this? Will it solve the problem that we want it to solve? Will it uncover new problems that the Product team might not know about? I’m not suggesting that Support should dictate what gets built; there are lots of inputs needed for those decisions, and Support often has a biased view since we primarily talk to customers who are having problems with the existing product. But it’s a deeply insightful source of input if harnessed well, like by having Support vet new product ideas.
Too often, Customer Support teams only talk to other orgs when there’s a problem. When there’s a bug that needs to be fixed, we talk to Engineering. When there’s a sudden influx of negative feedback about a new feature, we talk to Product. But not seeking Support’s input on new product developments throughout the product lifecycle is a missed opportunity for Product and Engineering. It means changing your MO slightly, to make space for another hand in the pot and another person in the meeting, but the potential payoff is significant.
You’re smart people. You want to do what’s best for your products and your customers. You want to do the right thing for everyone at your company. I’m sure you can find a way to include Support’s input and insight earlier in the design and development process. I believe in you.
]]>It’s been fun and relaxing. Cooking gives me something to do at least once or twice a day that doesn’t involve looking at a screen. I can spend a bunch of time researching recipes and ingredients and whatnot, but when I’m in the kitchen I have to pay attention to what I’m doing so I don’t cut or burn myself, which means I’m not on the computer. And that’s been great.
Recently I had some friends over and served some new dessert I made. I’ve always enjoyed cooking for people, though I used to stick mostly to barbecue. Now without an outdoor space and with some new recipes under my belt I’m branching out and making cakes and pastries. What a world.
Anyway, I served some food and everyone was into it and that was nice. One of my friends said something along the lines of, “This is so good. You should sell these!” And I know that it’s a compliment and kind of a throw-away remark, but it’s been rattling around in my head for a bit now. Because why should I sell these? Can’t I just enjoy making them and giving them to my friends? Isn’t it enough that I make some tasty food to eat and then eat it?
Like many people reading this (and I know that’s absurd because there aren’t “many people reading this” but you know what I mean), I’m on LinkedIn all the time. It’s how we all stay employed, isn’t it? We’re all there, and we’re all inundated with people talking about how to monetize this or that and how to turn everything you do into a side hustle. It drives me into a rage. I don’t want every moment of my life to be consumed with the drive to make more money! I want to just enjoy things for the sake of enjoyment once in a while.
Whenever I complain about this - and I do complain about this online and in real life pretty frequently - someone will inevitably tell me to shut up because “the system” turned us into this. And there’s truth to that. Modern capitalism (at least as practiced in the United States) squeezes people pretty hard. A lot of people are struggling to pay their bills, forget about spending any money on things to enjoy. It shouldn’t be surprising that everyone is looking for extra ways to make a little extra money. People are looking for a side hustle because people need a side hustle. I get that. I’m not suggesting that working more than one job is a moral failing or that it hurts me or even affects me in any way.
What I’m complaining about here is how so many people have absorbed that mindset so thoroughly that telling other people how to monetize their free time has become normal. Telling people that they could make money selling their hobbies has become so ingrained in how we think about our time and energy that it’s now an off-hand compliment. That’s shitty.
I’m not saying that you are shitty. I’m not saying that my friend is shitty for complimenting my sticky toffee pudding by saying I should sell them. I’m saying that it’s shitty that this mentality has become so pervasive, at least within the United States. (The big caveat here is that I only ever hear this from my American friends. I don’t often hear these kinds of hustle culture comments from non-Americans.)
Point is, you should be able to do things you enjoy without thinking about how to make money off of them. You should pick up new hobbies because they’re fun. Do things you’re bad at because they make you happy, even if you’ll never become a professional. Play music poorly. Sing off-key. Cook and bake and play soccer and make clothes. Do some things that fill you up even if you’ll never make any money doing them. Because you’re a full person and what the fuck are we doing here anyway?
I’m going to learn how to make falafel because I love falafel and I’m never going to make money off them.
]]>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.
“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.
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.
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.
]]>