Once upon a time there was a functioning software development team. Every day the team worked together to add features and fix bugs. Everyone on the team had their own specific roles. Everyone did their job well, and features were flying out of the door!

One day a database developer announced that he had found a new job and would be leaving our happy little team. Panic set in – he was the only person on the team who actually knew how to deploy database changes! We fell into a common trap: we had become way too siloed. The first week there was no discussion of what we were going to do – maybe if we pretended like nothing happened then it wouldn’t happen? Unfortunately, our database developer did not feel that way and his last day was looming in seven days. Our next release, which was planned to happen in ten days, was also ominously looming.

It was decided, finally, that what we needed to do was to shadow the database engineer during a pre-release to get the full story of how to run the release. The database engineer was kind and helpful throughout, but it was quickly discovered that he didn’t take very careful notes of how to do things. It was also discovered that not just anyone could access the database, only certain people had that permission. Because we all worked at a large enterprise company, we had to make tickets to gain access to the database, which took time to process. In the meantime, two team members began to shadow the departing database developer, watching him as he did the pre-release and asking questions and documenting things along the way. The two shadowing team members finally gained database access on the database engineer’s last day, just in time…or was it???

A new problem arose when we tried to release a few days after the database engineer’s last day. Our database dashboards had been upgraded to a newer version and did not match the dashboard we had been shown, so all the careful documentation that had been written during the pre-release was largely irrelevant. We also had issues with one person’s new account not getting the correct access, so they could not help with the release. With incomplete documentation, variable dashboard, and the pressure of releasing it correctly without our former colleague, things were stressful!

The day was saved when we were able to Google what the buttons on the departed database developer’s dashboard translated to on the newer version of the dashboard that our un-siloed developers had access to, which made the work slow but bearable. The release went out delayed by a few hours, but was mostly successful…or was it???

We discovered that some of the tables had not been migrated correctly when reports were no longer being populated correctly. We wondered, had we missed a step in the release notes? It turned out that it was a release-specific task that had not been done in the pre-release process and had not been documented! The docs were hastily updated and the same issue occurred again in the next release three weeks later – the docs were updated more throughly this time and we didn’t have an issue with the reports again during releases.

The moral of this story is:
• Don’t exclusively rely on self-documenting! It never is as complete as somebody else new to the process trying to accomplish the goal.
• Don’t silo yourself or your team! This is an easy trope to fall into since everyone likes being good at their one job, but any of us could get hit by a bus, an of us could get sick, and re-orgs happen all of the time.
• Document, document, document! When in doubt, write down what you are doing, how you do it, and update the documentation. A calendar reminder to re-visit your docs helps keep your documentation up to date.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.