Featured Technical Communicator: Luke Pivac

August 2023

Luke Pivac, smiling. He's wearing a light grey suit and matching flat cap.Luke Pivac is a technical communicator, senior agile leader, and author. He has a lot of experience and passion for combining technical communication with agile methodology. Be sure to check out Luke’s books and other learning resources at the end of his story.

How long have you been a technical communicator and how did you start out?

I have been a technical communicator for nine years, from 2008 to 2017. My first job in this field was at Navico, a company that specialises in marine electronics. I learned a lot from a senior technical communicator who mentored me and showed me how to apply technical communication theory in practice. She was very knowledgeable and supportive, and I appreciated her guidance. She was fluent in multiple languages and had excellent writing skills. She taught me how to communicate clearly and effectively with different audiences, using Adobe tools to share and review documents. Working with her was a valuable experience that helped me grow as a professional.

After that, I joined a startup company called Unleashed Software.

There, I worked with a dozen developers, and three or four testers. There were some conflicts among them, as you get in startups. As a result, they asked me to run the meetings as an impartial facilitator. As a technical communicator, I had the skills to do that. I tried to make the meetings productive and respectful, and to resolve any issues that arose.

I responded positively to this amazing opportunity. I quickly found out that it was not just about taking roles and checking on people's feelings - they were following the Scrum framework. As I learned more, I adapted easily. I took a course and Agility became my new passion and career. In that process, I learned how to balance end user documentation and running scrum teams.

Now, I am a senior agile leader, but I still have my writing skills. What I enjoy most is combining my nonfiction writing with my passion. And I use the Plan, Do, Check, Act cycle. I learn from work, do some research, and then I reflect on it. And then I write it. And if people are interested, then it's a benefit for everyone. But that cycle has been a common theme in my work career for the last 15 years.

Do you have any technical writing (or similar) qualifications?

I successfully completed a Technical Communication and Information Management diploma course from the Open Polytechnic in 2007. This qualification has equipped me with the skills and knowledge to produce clear, concise, and effective documents for various technical audiences and purposes. Prior to that, I worked as an audio-visual technician at the University of Auckland for several years. In this role, I was responsible for assisting lecturers with their audio-visual needs for their large-scale lectures in the auditoriums. It was through this experience that I developed a keen interest in writing about technology and how to communicate complex information in a simple and engaging way.

What does a typical workday look like for you?

I am a morning person, so I like to get an early start and dive into my work as soon as the sun rises. I begin by planning my day, checking my emails, and reviewing what I need to prepare for any upcoming meetings or deadlines.

This systematic approach helps me stay on top of my tasks and maintain my wellbeing, as I enjoy having a clear and consistent routine. However, I also recognise that my energy and productivity levels tend to drop after 3pm, and I start feeling the effects of fatigue and boredom.

To cope with this, I try to schedule the most challenging and demanding work for the earlier part of the day, when I am more alert and focused. And when I reach the mid-afternoon slump, I switch to less challenging and more routine type of work, such as filing, updating records, or responding to simple queries. This way, I can still make use of my time and complete my work without compromising on quality or efficiency.

What kind of content do you create?

I love writing about adaptive ways of working, Agility, and how it can help technical communicators be more productive. Hence why I wrote ‘An Agile Playbook for Technical Communicators’. But I have written several more eBooks on these topics since then, such as ‘Leading from Afar’, ‘The Craft of Servant Leadership’, and my latest one, ‘Team Facilitation the Agile Way’.

I'm looking forward to start working on my next book, which I'm calling ‘Project Management the Agile Way’. You can probably tell that Agility is a huge passion of mine.

When I'm not writing books or blogs, I still do some technical documentation for work, but for a different audience. I use Wikis like Confluence and Jira a lot. I enjoy communicating every day. The skills I learned from over ten years of technical communication have made me a better writer and helped me excel at what I do now, just in a different way. I'm very proud of my technical communication background and how it has shaped me into who I am today.

Are there other technical communicators in your workplace? How many?

Well, I'm not sure how many tech comm folks we have here. Westpac is a big company and all, and I don't get to interact with everyone. But I know there are some, at least. Maybe a dozen or so? I guess it depends on how you define technical communication, too. Some people might do it as part of their job, but not have that title. Anyway, I think it's cool that we have some tech comm experts in our field. It shows that we care about communicating clearly and effectively with our customers and stakeholders.

Do you work with subject matter experts or product owners? How?

I work with subject matter experts and product owners every day. My role as a workflow manager is crucial for collaborating with product owners, scrum masters, data engineers and technical business analysts. Years ago, I recall working with an engineer, who would always dodge me, knowing I would have some questions that only a subject matter expert could answer for the end user documentation. But some things never change. Some of them still try to evade me when I need something from them. Just kidding, I'm amazed by the talent and skill of the people I work with. It doesn't matter if you're a technical writer or a scrum master, people are the most important factor. They make the difference, and whether you're listening and translating their insights for the end user, or working with your team on some deliverable, it's always better to do it as a team. That way you learn from each other, earn respect as a team player and a teammate. And when you succeed or learn as a team, you're growing, and that's what I love about what I do.

Did COVID-19 change your role? If so, how?

COVID-19 changed my role a lot. I used to be a Senior Scrum Master at Health Alliance, a government agency, and we had to switch to working from home ASAP. It was crazy, I had to figure out how to run things with thirty plus developers, all online.

But it was also awesome, I learned so much from that experience and it made me better at my job. I'm proud of how I managed to lead a team of engineers during the first COVID lockdown of 2021.

Have you been following the buzz about ChatGPT? Have you tried it? What do you think of it?

I have been following the developments and discussions about ChatGPT with interest and curiosity. I have tried it out a few times, but I have found that the quality and accuracy of the information it provides can vary greatly depending on the topic and the query. I have decided to stick with Bing for now, as it is more reliable and consistent, and it does not cost me anything to use.

I do not rely on it for creating or editing copy, but I do find it helpful for generating ideas and inspiration for my blog posts, and it is very handy for that purpose. I appreciate that it can assist me with my research and act as a sounding board for me to refine and develop new ideas and perspectives to write about.

It is a tool that can enhance my creativity and productivity, and for that I am grateful. I try not to view it as a potential threat or competitor to my career, but rather as a facilitator and collaborator.

What tools do you use to do your work? Are there any you recommend?

I use a variety of tools to help me with my work, depending on the task and the project. Some of the tools I use frequently are TechSmith Snag-It, Microsoft Office, Confluence and Jira. TechSmith Snag-It is a great tool for capturing and editing screenshots, which I often need for creating documentation, presentations, and reports.

Microsoft Office is a suite of applications that I use for writing, formatting, and publishing different types of content, such as blogs, eBooks and newsletters. Confluence and Jira are two products from Atlassian that I use for managing projects, collaborating with teams and tracking progress. Confluence is a wiki-based platform that allows me to create, share and organise information in a central place. Jira is a project management tool that helps me plan, track and deliver work using agile methodologies. I have been using these tools for many years and have become very proficient in them. I recommend them to anyone who needs to work efficiently and effectively in a digital environment.

Which parts of your role do you enjoy the most?

I love finding new ideas from books or online and trying them out in my job. It's fun to experiment and see what works and what doesn't. Another thing that makes me happy is collaborating with awesome people who are good at what they do. There's a lot of them around here, so I never get bored.

I am currently working on the programme planning side of things and having recently been certified in Managing Successful Programmes (MSP-5), I am happy applying what I have learnt into my job. This has been a common thread in my career, be curious about things you are passionate about, ask questions, write it down until it makes sense, apply it in practical situations and then teach it to others.

The simplicity of it is beautiful, and I really enjoy that process. There is a simple systems approach called the Denning Cycle, you might know of it as the Plan, Do, Check, Act method. That is what knowledge is like, you are always learning, applying, testing what you have learnt and practising it. I get a lot of job satisfaction from that.

Can you tell us about a rewarding project you've been involved in, in your technical communication career?

During my time at Unleashed Software as a senior technical writer, I had the responsibility of creating and maintaining all the end user documentation. We experimented with several help systems, but none of them met our expectations. They were either too complex, too expensive, or too inflexible.

That was until I discovered an out of the box solution called Help-IQ, which is now known as Proprofs. This solution was perfect for our requirements, as it was easy to use, affordable, and adaptable.

This process of finding and implementing the best help system for our platform was very challenging and rewarding for me, as I was the only technical writer in the company. I had to deal with a lot of changes and transitions, as we moved from a static web-page system that I inherited to several different systems that we tested and evaluated, such as Author-it, and many others, until I finally settled on the right one. All this while, I had to keep up with documenting all the new features and updates that were being released, as well as improving and optimising the help system and its content. It was a very demanding and exhilarating experience, as it felt like I was flying the plane and building it at the same time. What I learned from this experience was invaluable. The web-based help system that I designed and most of the content that I wrote are still in use today. I am proud of the impact that I made and the legacy that I left behind.

It gave me the courage to try new things and explore new possibilities. It gave me the confidence to trust my skills and knowledge and to know that they will be useful and relevant in the future. It also showed me that the experience I gained from this was unique and rare, and that I had something valuable to share from this experience. So much so that a few years later, I wrote a book based on this experience.

What advice would you give to someone starting out as a technical communicator?

You are about to embark on an amazing journey of learning, creating, and sharing. Technical communication is a rewarding and exciting field that lets you express your passion for what you do. Don't be afraid to experiment, to fail, and to grow. Every mistake is an opportunity to learn something new and to improve your skills. Share your insights and experiences with others and learn from them as well. Technical communication is all about collaboration and communication. You will love it. You’ve got this!

Is there anything else you’d like to tell us about the work you do or technical communication in general?

The skills gathered as a technical communicator over the years never leave you. I still use the principles I learned back in the 2010s even today. From my experience, it has made me a better scrum master, project manager, and now workflow manager. Doing the years of documentation means my output is faster than most in my profession and that is because of all the challenges I have experienced and finding ways to overcome them. If it was not for that experience, I would not have been able to achieve what I do today.

The common theme I learned from my time as a technical communicator is the number of skills you pick up. And these are all transferrable skills, using my experience as an example, from technical communicator to a scrum master/project manager. The transferrable skills I used, to help me adapt, were things like documentation (obviously) but technical communicators can use their writing skills to create project documents, such as project proposals, plans, reports, and so forth.

They can also use their writing skills to communicate effectively with project stakeholders, such as sponsors, and other team members. Additionally, all those years of technical knowledge learning and documenting about a product can help you to understand the scope, requirements, deliverables, and risks of a project.

There are also the research skills, the communication skills, not to mention the collaboration skills - for example I already had the experience to work effectively with the project team and other stakeholders. There is also delegating tasks, coordinating activities, facilitating meetings, and fostering teamwork and trust.

Technical communicators are highly adaptable and a very determined bunch, the skills you learn are immeasurable.

Ngā mihi, Luke!

You have some awesome skills and experiences. Thanks so much for sharing your journey through agile working and technical communication with us. Congratulations again on your published works.

Luke’s eBooks

An Agile Playbook for Technical Communicators

Leading from Afar

The Craft of Servant Leadership

Team Facilitation the Agile Way

Audio learning

Using Scrum Values to Optimize Your Scrum Team

Scrum Master Secrets for Remote Teams

How to Lead and Grow Teams with Scrum

Boosting Scrum Team Performance with Small Tweaks

Blog

Agile | Adapt