Why Good Record-Keeping Saves Time in the Long Run
I find my obsessive attention to detail on technical projects sometimes irritates colleagues who think it is time wasted instead of just performing a task assigned and moving on with a one-liner success comment on the ticket. Over the years of troubleshooting issues on the technology stack, I have to heartily disagree for a few reasons.
Firstly, let me start out by saying that slow is smooth. Detailed record keeping allows you to quickly check up on one's actions in response to queries from management, colleagues, and the business as a matter of normal course in enterprise-level engineering, development and operations teams. There are many more reasons to keep detailed logical records, some of which are as follows:
- Project Instructions. Lack of detail in technical instructions happens for many reasons. Regardless of the reasons why, the outcome of these vaguely detailed instructions always raises the risk of misunderstanding on what the actual ask is elevating the risk of mistakes, misdirection in a project and ultimately the failure of a project. Creating a structure to build an overview of what tasks you need to do to complete a picture of your work input on the project allows you to measure your workloads required. If the instruction does not allow you to do this, then ask questions and query until the picture is complete allowing you to proceed into a planning phase for work implementation.
- Technical Structure. On a technical project, we as Engineers live in a detail-orientated world so it's very easy to get lost in a task. The wider level tasking can have timings set to them for project success or as recently as last week for me, have a large tasking subsection of complex technical actions to be taken. Given their complexity, the tasking payload can lead to mistakes due to the volume of sub-tasks required to complete the actual task at hand. Structure your tickets to break up the tasks and keep a forensic track of your implementations via detail orientated record keeping. Keep a note of the task, action that was taken in discovery and/or implementation alongside the result and next steps. Good comment keeping on tickets can be a handy way to detail a diary of the next steps at the end of a comment update.
- Work Done. Keeping track of project work is tricky at best making detailed record-keeping a good practice for keeping up with your progress. Good project structures (i.e. Epic into Stories into Tasks into Sub Tasks) also helps with breaking up a project tasking into appropriate chunks for execution. This is where your project detail will reside. Keeping a word or text file with a summary of your work taken as a diary document can make tracing your actions taken on a project very easy to review over time. It's extremely useful if something goes wrong and you need to review your actions taken on a project at any point in the future (e.g. Technical Root Cause Analysis/Audit Query). Also, if your timekeeping is for billing or overtime purposes, this diary approach can double up as a reference document if you place times alongside your entries.
- Time Management. If you are like me and suffer stress when you are buried in the chaos of unstructured workloads leading to long hours of toil, then structuring your workload is an essential beginning to onboarding any work instruction. If left unstructured, the workload overload often feels like the more you do, the more there is, and it depreciates the quality of your working life. Managing time into reasonable workloads per day must be your first action. This can be done by detailing your workloads as discussed above along with keeping detailed records. The result of a structured workload implementation allows you to complete manageable workloads per day on your ticket. It also allows you to mentally sign off at day's end with another piece of work complete making a large job a little smaller for tomorrow. The sense of control leads to a sense of empowerment and satisfaction at work. This in turn leads to lower stress levels, lower propensity for mistakes and higher productivity on the project.
On the way home, if we can unplug knowing we have structured our work-life as Engineers to plug right in where we left off on a project then it's a good day's work. The records we keep will seem to be a redundancy after the project on our project management system, yet they act as a guardian of our technical work history should any issue arise in the future ensuring the integrity and quality of our work.
Stay tuned for more on Infrastructure in this blog along with articles on other areas of interest in the Writing and DevOps arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!