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.

Deirdre Doyle on collecting stories at the 2015 Nordic World Ski Championships.

On a clear late-winter morning in 2015, I eased into the driving seat of my car, looking forward to the solace of a three-hour drive. Having worked 12 days straight at the Nordic World Ski Championships (held from February 18 to March 1), I was looking forward to the simple purr of the engine and the low winter sun for company on the empty highway. As I pulled out of the parking lot, leaving behind Lugnet, Falun’s sports arena, the grit-covered piles of melting snow already started to fill me with a sense of nostalgia for the live action.

As part of the Sitrus team tasked by Ericsson to gather content (interviews, films, stories and pictures), it was my job to create the stories about Ericsson, their software and services, and the rapidly changing use of mobile.

Christina Sandell, Head of Marketing Strategy and Operations at BU Global Services, Ericsson, was responsible for the Falun project, on many occasions she said that sponsoring Falun initially was “an offer to refuse”. The first time she said it confused me. But she went on to explain that the local organizer’s vision to use new technology to take the sport to a level never experienced became a great opportunity for the company to showcase its vision of the Networked Society.

Put simply, the technology Ericsson provided, fed the two official championship apps with real-time information mashed from various sources. This included information from TV feeds, GPS athlete-tracking, snow temperature, official timing, and map data. Ericsson’s solution is a clear example of how digital technologies, as it touches more and more industries, changes the way people do things: from how we experience things, to how we communicate, to what we communicate. The solution exemplified how we can use technology to help us, and how technology provides us with innovative — and in this case entertaining — ways of experiencing the world.

Jenny Ericsson (Sitrus Agency) showing a fan how to get the most out of the official event apps

Personally, the Falun project presented me with an opportunity to combine my constant desire to create interesting stories, with my understanding of technology, and mix it with one of my favorite sports: cross-country skiing.

Our first step on the road to Falun was in late summer 2014. During a conference Ericsson brought all the stakeholders involved in the Falun project together. Attending were their own marketing and communications team, the technical team, the app developers, the event organizers, their event agency, and us — Sitrus Agency, the content people.

Through a mixture of presentations and interviews, I spent an intensive day and a half getting to know everyone, their roles, why they were involved, and just what Ericsson had planned for the event. It was complex — not just the service enablement platform, but the project itself that brought together so many people from different industries, all with widely-varying skill sets and each with their own business objectives.

In the 100+ days between that significant first gathering and the first race, we created stories about Ericsson’s Networked Event and the people behind it. We told the amazing story of cross-country skier Dominic McAleenan, an Ericsson employee who represented Ireland in the championships. Perhaps unsurprisingly, he and I connected through a shared passion for skiing, the Nordics, technology, and even a common nationality.

Ericsson’s on-site Digital Experience visitor center

I think my favorite story though was that of Mike Jacquet, CMO for the US Ski and Snowboard Association (USSA). On the day that US teammates Jessica Diggins and Caitlin Gregg made history by taking the silver and bronze medals in the ladies’ 10km (the best ever finish for the US team), Jacquet took the time to come and talk. Shortly after Diggins and Gregg crossed the finish line, he pitched up at Ericsson’s on-site visitor center, ski boots in hand. Giving me a big friendly handshake, he told me about yet another historic event. Thanks to Ericsson’s technology, and that he had the foresight to purchase broadcasting rights for the US, fans back home could enjoy the successes of the US team live and on demand.

The economics of covering a niche sport like cross-country skiing in the US simply don’t add up. But as Ericsson’s solution could mash the TV feed from the host broadcaster together with commentary in English from another provider, Jacquet’s organization was able to deliver premium coverage to the US audience without the need for journalists, equipment, or an on-site organization.

My Falun story is about passion, from the athletes, the Ericsson team, the spectators, the organizers, the sponsors, and the volunteers, to the passion it takes to build the digital solutions that enable more people to share in the excitement. Creating content in such an environment was an amazing experience.

The story comes to a fitting close at the end of 2015 when Ericsson and Sitrus Agency were nominated for a European Excellence Award — which even if we didn’t win, I’m pretty sure we were close.