Toolsmith Kaizen

Currently not being able to afford the time to prepare a technical-with-source blog entry, I thought I would write a little about a softer issue that I have been working on lately.

I am unable to get to the bottom of the problems on my plate. I am always playing catch up. That is how it has always been - here at Jyske Bank, at Systematic, and before that, at Red Hat and Cygnus Solutions. I guess it is the way the world works.

However, as my primary concern is improving the tools used by our developers, I badly need feedback from them to improve their world (or I'll be working blind).

In my experience, it is very easy as a Toolsmith to lose touch with the developers; they tend to suffer in (for the Toolsmith's ears) silence. While they may have gripes with the tools, they don't bother telling the Toolsmith about it unless it is really horrible or critical for their work. Their experience and assumption is that nothing will probably be done about the problems they see - so why waste time reporting them?

At least that is how I behave when my feedback has no effect. And how I have experienced developers I work with to behave.

And obviously, it is a self fulfilling prophecy; if problems go unreported, odds are they will not get fixed.


So I have decided to change the behavior of the developers here at Jyske Bank - to try and get some more feedback and, in the end, become a better Toolsmith.


I base this on the important observation: I will never ever get to the bottom of my task list. So tasks are always delayed to some extend (ultimately depending on their importance).

Which leads me to: if tasks are always delayed, they might as well become a little more delayed, in exchange for providing a better (perceived) service to my customers (the developers).

So I decide to actively prioritize improvement suggestions from the developers (issues have to be relevant and worthwhile, of course).

Specifically, for 2 weeks out of every 8 weeks, I will focus on implementing developer suggestions (as general firefighting allows). Votes in Jira serve as my guide for which issue to fix and in which order.



That is the foundation on which I want to build the change of behavior.

The rest is public relations; I need to get the word out and lower the bar of entry for the developers.

Enter my slogan: "Red Hat Kaizen"

I use my red fedora (and probably abuse RHAT's trademark - my apologies) as a gimmick; I wear it in the two-week developer-issues-have-priority period. And whenever I happen to be visiting developers to help with specific issues. It definitely creates some attention :)

Kaizen is for enticing the developers. I emphasize that there is no lower limit to the stuff they should report. Every little improvement matters - especially if it benefits 80 developers.


I have been pushing my little agenda for some weeks now, and while management is exuberant there has not been the reaction from the developers I hoped for (i.e. I am not swamped in new Jira issues).

But I have faith and patience. It'll come, I'm sure...

Have a nice vacation!