Photo by Denise Jans on Unsplash
My dispute with the word improve began some years ago when writing for a software company. It’s a tough one in the tech world because I’d say that improvement lies at the core of technology. Tech companies constantly make improvements to their products, making them faster, more widely accessible, reducing environmental impact, and so on.
In my mind, improvement is fundamentally about change. To make an improvement, you must change something. You might, for example, change the chipset your product runs on, use different materials, or rewrite a piece of code to take advantage of new hardware technologies. For readers, I believe that understanding what has changed allows them to infer improvement — instead of me telling them what has improved because what I think is an improvement may not hold for somebody else.
A former colleague of mine once said we could improve the office environment by having a Starbucks machine in the reception. I believed she had a point, but mainly because the coffee in our office at the time was atrocious — but that’s my opinion based on my preferences. Not everyone approves of the great coffee giant and its promotion of single-use cups. In such cases, it’s better to talk about the change and leave it up to the reader to decide if an improvement has been made. And if your case is strong, the likelihood that your customers will believe you’ve made an improvement will be significant.
To test the validity of improve in my copy, I have developed a test: is there enough context for the reader to understand what has changed, and if so, do I need to use the word improve at all, or can I simply talk about the change — is the use case strong enough?
Going back to my time at the software company, we had a lot of different products, and one of my responsibilities was to write the release notes for each new version. Today, the mere mention of release notes will send me running for the hills, hoping never to return. The problem is that release notes are a sweet spot — or, in my opinion, a sour spot. They bring engineering, marketing, tech writers, product managers, and leadership (mainly the CTO) together — which is a recipe for disaster because everyone has a different agenda.
Depending on the size of the release, the notes will include three elements: new features, enhancements, and bug corrections. The problem usually arrives in that last section because writing about new features and enhancements tends to align with the needs of all stakeholders — including customers. However, when it comes to explaining bug corrections, the heat turns up — and I think it’s due to that agenda misalignment.
The CTO wants to ensure that anything we write about a bug fix doesn’t have damning implications for the company. The marketeers want to ensure that customers understand the value of the changes that have been made. Product managers want to make sure that their product image remains intact. The tech writers are concerned with making sure that what they write is understandable to the target audience and accurately reflects the change. And the engineers don’t want to lose face by admitting their code has flaws.
But what has all this got to do with the word improve? When I’d receive content from engineering about changes, bug corrections tended to be an endless list of improvements. And I’d be like, what does that mean, improve? How did you improve it? What was wrong in the first place?
My main objection to this word is its lack of specificity. It would help if you quantified the improvement. Otherwise, you’re leaving yourself wide open to interpretation.
Imagine a software add-on called ‘the accelerator,’ enabling clients to process ten times the number of transactions per second. We’ve received a bug report about the add-on that the engineers have resolved. For the release notes, the engineers gave me this: we improved the accelerator.
I now want to put my sneakers on and run. Depending on a customer’s specific experience with the accelerator, this sentence will likely raise more questions.
In such cases, I would go to the engineering team to ask some more questions. On the rare occasion that an engineer decided I was worthy of their time, the conversation might go something like this:
Me: How did you improve it?
Engineer: You don’t need to understand that we just fixed something that wasn’t working, and now it works.
Me: What wasn’t working?
Engineer: It’s complicated (while staring out the window).
Me: Try me.
Engineer: Our accelerator wasn’t working for some of our customers.
Me: What wasn’t working?
Engineer: It was slow in some environments.
Me: What do you mean by slow?
Engineer: We have this one customer who reported the bug. When they implemented the accelerator, they didn’t see any increase in the number of transactions being processed.
Me: Oh dear. And will they experience a 10% increase with this latest release?
Engineer: Yes.
Me: So, what did you do?
Engineer: When we looked into it, we saw that this customer was running many tasks on the same VM, and our accelerator wasn’t getting any compute power.
Me: So, nothing wrong with the accelerator?
Engineer: Well, no, not exactly. But we should have included code to ensure access to compute power.
Me: And you’ve done that now?
Engineer: Yes. But we’ve only tweaked it for the specific hardware configuration that this customer has. We don’t want to disturb customers who don’t experience the problem. But we think we may need to do a redesign to cater for more complex server configurations.
Me: But for the moment, you’ve solved the problem for the customer who reported the issue.
Engineer: Yes.
Me: That’s great. But that means that this customer may experience a degradation in the other tasks they are running on the same VM?
Engineer: Possibly.
Me: So how about we say this instead: When running the accelerator with <name of cloud operator> on <type of server>, the accelerator will now be assigned with static processing resources to ensure transaction performance.
While the above is an entirely fictitious conversation, my aim is to highlight the importance of asking questions, dig down, and find the root cause of the problem — because that will give you substance and specificity.
But there’s more, the problem with improve is not purely rooted in the way readers might interpret the word. I’d say that most people feel that improvement is generally positive and particularly in the tech world. But, if you need to improve a product, you are inherently implying that there is something wrong with it. Yet that may not be the case because you might improve something by availing of new materials or hardware techniques — changes that have taken place outside of your domain. And you are simply ensuring that your product remains relevant.
So, my advice is this: talk about the change and allow your readers to infer the improvement.

probably wouldn’t do when we come down here during the summer. I chose to go on the local tour of the salt flats of Torrevieja, which is carried out in true tourist style, on one of those excruciating choo-choo trains. As we age, we learn to appreciate the things, which in our youth, we regarded as sad, boring, or naff. The tourist choo-choo (along with cheese in a tube) remains on my list of highly-uncool-things this planet has to offer. I don’t think I’ll ever enjoy them.
The trip around the salt flats takes about an hour and I was in good spirits when we returned to Torrevieja. I decided that a cup of coffee on the strand, or maybe even lunch, would be a perfect way to complete the morning. So, I ambled along the seafront until I found one of those outdoor cafes with ocean-facing sofas. It doesn’t get any better than this: I don’t have to be anywhere, I don’t have to cater for anyone else’s tastes, I have only myself to please. So, I plonked myself down on a vacant sofa and started to people gaze as I asked the waiter to bring me a menu.
Once home, I’m now starving. I have two choices: eat the dodgy packet soup that’s been in the cupboard since who-knows-when or walk 20 minutes to one of the locals. I chose the better option and took a stroll down the beach to one of the seafront restaurants. It was quiet, I ate an absolutely fabulous lunch while I watched a family brave the cold of the November sea, the surfers battle the waves, all while people around me smoked like troupers. I was upwind.
Jenny Ericsson (Sitrus Agency) showing a fan how to get the most out of the official event apps
Ericsson’s on-site Digital Experience visitor center