How to avoid writing as an AiT consultant?

Dear community, I would very much appreciate your thoughts on my current career challenge.

Trying very hard to write a book on AiT has made it very clear to me that writing for me is hard. I can write just fine, but for a number of reasons it just takes me forever. (So that book is still unfinished, yes. :disappointed:)

As a consultant with 20+ years of experience in automation, I now focus mostly on automation strategy as it is where I have most value to offer. (And also because many others do mostly technical stuff and few do strategy well, especially above team level). But strategy seems to imply writing lots of advice reports, and those take me much more time than I think they should. That is not only disappointing to an employer or customer but also increasingly frustrating for me.

So I am very, very interested in your ideas on me adding value according to my experience while limiting writing documents to a minimum. Please share your thoughts, also for the sake of others who would rather not write much.

Thank you.


I’d like to understand the problem a little better - what are advice reports? What do they purport to communicate, and to whom? And do they find them useful or valuable, and why?

Also what do you mean by automation strategy? Are we talking about how to build a framework, or how to achieve useful coverage, or how to communicate that coverage between the tool and the testers, or domain rules for formatting/templating/data control/code style/etc? Or all of it? I imagine it changes between companies and projects a lot, as the responsibilities change.

For me a report is just a communications tool, and you can often communicate without writing anything. If you’re looking to reduce documentation I find that abstracting out to the purpose of the thing is a good place to start. Another is to look at why the communication is happening and if we’re splitting responsibilities up correctly (I don’t have to communicate what I want to drink if I make my own drink).

Thanks for your response, Chris. I should have known the strategy bit would raise questions. I am so used to using the term with a specific meaning that I do not always explain it. My bad.

And no, strategy as I intended it is none of the things you refer to. Those are interesting and relevant, to be sure, but perhaps the best term for what I mean is corporate automation strategy: What is necessary to have automation bring real value to the business and how do you make that happen (= what do you decide, what do you do and when). This is also why I mentioned ‘above team level.’ It especially helps not making bad strategic decisions, that hurt the most down the line. But I do not make those decisions and may not be around to (help) implement them.

This area includes what the organization needs to do, the automation lifecycle, roles, training, culture, various processes including the ones touching multiple teams, everything relating to test environments, skills such as architecture and agile specification, engineering practices, and more. The big picture. All this is different everywhere, but looking into that is exactly what I do. I have a method that helps me do investigate all this and report on it in a very structured manner. But advising the management of an organization on this whole spectrum calls for reports, and writing those is … no fun for me. Hence the question.

Hope this helps.

I think about strategy the same way, ideas that guide decisions, I just didn’t expect the problem to be quite that big! It seems like the struggle of connecting your usefulness (your skills and knowledge) and implementing it for long-term change with communication and documentation, which is a lot of a problem to tackle.

So the reason I say to look at the detail of what you’re communicating, to whom, and the value in it is to maximise the efficiency of your communication by not including things that aren’t important, won’t be read, basically stuff that doesn’t have value, and to genericise some things - but you need to find out what those things are. If they are to make it look like money was spent, which I realise is an annoying factor separate from providing real value, it does not necessarily need to be totally bespoke. If it’s for reference then it could be more inclusive than specific. And it could be excluded entirely.

The more generic the information the more you can separate to boilerplate documents, templates, default information, that sort of thing. You can also have a portfolio of on-demand entries to pull from rather than writing everything out. It’s always a mix of what can be repeated and what needs to be bespoke, and essentially you’d be working on the efficiency of that, and also providing yourself resources to create bespoke reports. The abstraction versus the detail. The specificity and control of Lego versus the simplicity and speed of Playmobile.

Another technique that can help communication and cut down writing simultaneously is how it looks. Diagrams, illustrations, charts, cartoons, tables, colours, tags, that sort of thing. When your layout, formatting and illustrations communicate for you then you don’t have to write stuff out as much, and you can pull from a pool of style-matched resources to put your reports together. Also good for readability, branding and so on. And nice reports feel expensive.

Then there’s non-report communication, like lectures, tutorials, workshops, presentations, debriefs and so on. You can also use some of these to train people inside the company to communicate and implement the strategy, why the strategy is good, and how to train others. You can use video and voice recordings here to provide the documentation part of the report - if I give a presentation and record it then people can see it any time they like.

You can also cheat behind the scenes - using voice-to-text means that you can read the bulk of your report rather than writing it, and that includes running VTT on audio recordings you might make at any time on, say, a pocket recording device with a lavaliere mic. There are pens that can digitise hand-written notes so you can jot things down and paste them into digital reports later. So there are a few tools out there to take some of the pain out of the process.

Hopefully some of that inspires something useful!


Sorry for not replying (much) sooner, but your elaborate reply is very useful, Chris. I was already doing and considering some of the aspects, but now that I reread it later I can use even more of it. Thank you.