Short version: It is the part of the process which is not documented which causes delays
Generalized: Deadlines are as feasible as the tasks they are set for are understood
Ultra-specific request of managers: Remove these words from your vocabulary, except for in extremely specific cases:
- “But I know how to do it.”
We were in the home stretch of a project which had all the hallmarks of failure: introduced mid-sprint with other commitments on the line, little or no planning, no comprehensive team schedule or document, deadlines made without team acceptance, tasks introduced as people thought of them.
It was Friday afternoon. I was asked to perform a function I had never performed before. Sizing it up and accounting for problems, I estimated it at one and a half hours. It was due in 2 or 3 hours.
It was a keystone task. If it failed, the entire project failed. It also required extreme attention to detail as most steps were manual and included setting multiple configurations in several different interfaces. It was also poorly documented.
A new lead said: “I’d expect it done within 30 minutes.” I pushed back: “I’ve never done this before, and I’m leaving room for me to learn and for there to be problems.” We compromised on an hour.
It took almost an hour and a half.
- The file format of a key file, JSON, needed to be on a single-line, not linted. This was something the lead knew, but I did not know. It was not documented.
- Once I submitted the request again with the same file edited for formatting, the file failed because it needed a new name the second time. For all other processes, we could leverage the same file name, but this one file name couldn’t take it. This was something I didn’t know. It was not documented.
- I needed a refresher on how to obtain key logging to assess errors myself. This had been visually demonstrated to us as a team, but there was not adequate documentation for my use.
- I tried to call the person who maintained the process, but he said he was only available for Slack. Nobody had accounted for limited key resources.
- I was being asked to do this when there were people available who had done it before under much less pressure.
This is an example of the Gotcha.
Leadership patterns in response to or preventing a Gotcha include:
- Documenting mission-critical processes so that even a new person can complete them with a basic understanding of fundamentals
- Allowing for a first-time process execution to have learning time, time for attention to detail, and time for mistakes
- Accounting for who is best positioned for a mission-critical task, including backup if a new person is asked to work on it
- As time permits, only provide a demo when adequate documentation exists — then provide a demo with clearly identifiable documentation for later use
- Bake in time to document
- Improve project management for the flaws that got you to a place of introducing critical tasks at the last minute without refinement
I got the task done within my initial estimates, but I was struggling with feelings of anxiety and resentment doing the task.
We didn’t perform corrective actions immediately, leading me to want a corrective actions input system to track things as they occur so they can be fixed later.
Who am I?
As someone with over two decades of leadership experience in the tech world, I still make mistakes. I have a treasure trove of anti-patterns I’ve either seen or exercised myself.
In short, I know the good stories. Don’t assume my stories are from my current place of employment. Odds are they are not.
I’m a senior data engineer experienced in Python and various SQL flavors, a process improver, a leader/manager, and someone who wants employee experiences to improve.
I hope you enjoy reading the articles in the Leadership Anti-Pattern series as much I enjoy writing them.