Making an impact: Changing the way Product and Engineering work with the Writing team

How great is it to dive headfirst into a difficult project, take the reigns, and make things better? Do you find it exciting or intimidating?  

Recently, I paid special attention to what I do when I start working in a new product area. I am currently filling in after someone left the organization until we get another person hired and onboarded. As I have been working, I realized that I have been asked to do this a few times. I decided that I must have some knowledge that I can share with others. And, this article was born.

I am going to share just a few of the challenges that I faced, tell you how I handled them, and describe the lessons learned.

This product has a steady flow of releases. I was told to expect to receive information on the release date. Immediately, I knew that this was something that had to change. Receiving information on the day of the release has many risks. Systems go down, people get sick, natural disasters occur, and more. 

Our organization adopted Docs-as-code as a philosophy at the end of last year. Teams were supposed to be trained and transitioned because our Content Management System (CMS) license expired. However, this product team was working in Word and Confluence. They weren't trained and their documents weren't migrated.

Communication was done through meetings, email, and instant messaging. While the Scrum Masters were known to be wonderful people, you must simplify when you are one person dealing with multiple teams.

So, you can see that I faced some challenges when I started working on this product on April 14, 2021.

Agile Working Agreements

In 2018, our team created Agile Working Agreements for the Information Development (ID) team and the Product and Engineering teams. Like all Agile Working Agreements, this was intended to identify behaviors that can impact the team. For example, you must hand off information to ID for <insert item> X number of days before the release date. If the handoff is late, the consequences are listed. These agreements help reduce risk and ensure everyone is accountable. However, I quickly discovered that no one had been following the agreements. 

I reminded the teams about the agreements and when I received pushback, I explained that our team deserves the time we need to do our work, like anyone else. If the developers can't fix a bug, the release doesn't go out the door. If we don't get information until the day of the release, we must negotiate what we can deliver. 

What is the lesson? When you have agreements in place, don't be afraid to hold everyone accountable.  

Migration

From the day I started on the product until the first major release, we had one month. I notified the team that in that month, we were going to migrate to the Docs-as-Code platform. I received some initial pushback. However, I assured the team that we would train the team in the upcoming month and migrate the documents. Also, I notified them of two critical pieces of information:

1. Going forward this was going to be the only way to create, update, or review documents, and
2. We were required to report compliance to upper management and preferred to report positive news.

By the May 14 release, all documentation was created and updated using the new system.

What is the lesson? If you are must make a change, be ready with a plan and execute. Ensure that you have the support of your executive management team.

Communication

Remember that I mentioned earlier that communication happened via email, meetings, and IM? This was challenging, and the teams agreed that it confused them too!

Fortunately, my predecessor and some others had implemented some excellent changes in Jira. Using these changes, I documented a process and reviewed it with the key stakeholders. Then, I notified everyone about the new process.

But, I have learned that simply sending an email isn't always the best way to communicate important information. I wanted to hold a few short training sessions. I contacted the Engineering managers to ensure that they agreed with the process, which included that the Definition of Done must include documentation. I also wanted to confirm that they would give their engineers a half hour to be trained and that they would support the process. After getting their buy-in, I emailed 70+ engineers, architects, and Scrum Masters to offer training sessions. I don't know the results of this at the time of this writing as the sessions are upcoming. 

What is the lesson? Collaborate across departments to create common processes, get buy-in, and communicate the processes.  

This product won't be "mine" for much longer. I will hand it off around July to a new employee. However, I hope that the work that I am doing makes things easier for this person and anyone else who ends up in this position going forward.