What you generally don’t want on a project

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:

  • “simple”

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.

Here’s why:

  • 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.

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

Epigraph:

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.

Resident of Frogpondia.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store