Over the years, I've often taken on a "technical leadership" role. Sometimes it was in my job description. Sometimes as an advisor to those who were. And most recently, I've joined the exciting world of middle management!
Years of reading Scott Adams gave me a healthy fear of being a pointy-hair. Adams' Dilbert Principle made middle manage sound like the anti-thesis of competent engineering. Well, before he became a polarizing political pundit.
The problem I inherited was poor tracking of projects. This meant we couldn't trust any of our reporting:
- What projects are active
- Who's working on what
- When the work is done
"You don't manage people; you manage things. You lead people."
It became clear that I needed to manage the process, but be mindful how this impacts leadership. "Can't trust the data" means an inability to know who was working on what, and if it's valuable to the company.
Which isn't to say there wasn't existing process, but it did have a few flaws
The workflow to process engineering requests was Kanban. It made some sense. This was a request-based team, but the requests themselves weren't discrete atomic units. A request might be something mechanical like "I want access to _____ resource". Or a show stopping "TLS traffic isn't working for North America East".
Asymmetric units is bad for metrics, but not that bad. No one's getting fired because they didn't close enough pieces of flair^H^H^H^H tickets. The big stuff still gets attention, but the little stuff falls by the wayside. Several months of no one paying attention to the little things meant our WIP grew to the size of our backlog.
After the first few reviews, I saw people weren't just abandoning tasks. For some tasks, the engineer started, but work stalled because the timing wasn't right. They weren't blocked. Priorities changed, or a constraint was external not only to our team, but the entire company. And it didn't feel right sending it back to the backlog. We needed a status to cover these 'on hold' that doesn't confound where we actually spend effort.
I was certain that someone just needed to review this stuff, little or big. And the way I decided to tackle it was with automated reporting. At the beginning of every week I get reports on:
- Tasks that haven't been updated in a while
- Tasks with a duedate approaching or missed
- Tasks that we owned, but were "out of band"
- Tasks that we started, but couldn't finish just yet
I knew that if I worked these reports to zero, we'd solve our project visibility problems! And I knew that the person before me had the same idea. The Kanban board was a silver bullet to track of tasks, status, and whatever else it is that Agile peddlers promise when they're hocking smoke and mirrors.
These reports were useless unless someone was willing to sit down, and review these tasks. I took a suggestion from Oren Ellenbogen's in Leading Snowflakes. I made an appointment in my calendar to focused on capital-m "Manager" stuff (I also had time set aside for capital-d "Developer" stuff). .
I guarded this time window from myself, and ignored the feeling of pushing it off "just this one time". Okay, I may have let Sev-1's have a hall pass, but this was the time to put on my big boy pants, and manage our process. Besides, I gotta do something between ordering donuts and yelling at people.