I do therefore I am
As a developer, maker and doer I favour doing stuff rather than nattering about it. I subscribe to the mentality that activity follows identity or as Descate kind of said
“I do therefore I am”.
But management types don't “do” they direct and that's not contributing is it?
Well as it happens it is.
If you have read my blog before you will realise that I don’t identify myself with being a “management type” but inevitably as the years have marched on I have had to admit to myself and others that I am now more manager than maker. At first this was a difficult transition. You see creative types (like me) reject management intervention of any kind no matter how cool they make out.
My antidote to being a “management type” was to adopted a laissez faire approach to directing my colleagues. I worked at the rock face; I was as transparent as I could (without shouting fire of course) and directed with the lightest of touch. On the whole this worked.
But light touch is not the solution to everything.
There is a bias that clever folk have. They assume is that everyone around them is as clever as they are. Underneath this bias is an unspoken assumption that whatever they are doing is “obvious” to everyone. Anyone to whom “obvious” is not obvious is deemed a freak unworthy of the salary associated with them being present in the any meeting.
But you know what? It turns out that I had this bias too. In my nievity to not rock the boat with my creative team it was my assumption that each of the team members also knew what they are doing too.
As I have gained my management maturity I have collected stories from the mates I have worked so closely with in the past and have been amazed to discover how little they knew about their team’s or even my work.
Devs are an insular bunch of people and they prefer to slap keyboards making digital stuff than talking about it. And as the owner manager this was music to my ears, but I mistook this activity.
As Hemingway once said
“never confuse movement with action”
Often we would work belligerently down dead ends when team members too fearful to say something knew better.
As an Agile Fu Master these days I work with a more targeted form of management based on a little more than being laissez faire.
Agile is a methodology that is designed for projects with a deal on unknown in them. It wrangles the assumptions of co workers knowledge and shines the flash-light of transparency explaining the project's progress to everyone in the team. It does this by forcing laser focused agenda for a few very simple meetings.
While it is management, it is management with a soul that understands developers issues as well as those paying for it.
If you liked this
I hope that you have found this article of interest.. If you did then I have written more about developing products using the Agile Methodology. I have tried to make the book as short on fluff and full on content as I can so it can be read in approximately an hour.
You can download my book by clicking here: AGILE FU
Anyone purchasing the book will receive not one, but TWO FREE mini e-books that are supplied directly as PDF files to your inbox. These can be distributed to you team when starting a new project or used simply to sanity check your existing processes.
Until next time
Paul