Skip to main content

Empowerment.

I received a very earnest email from a senior IT director that implored us (the unwashed masses) to provide feedback on how 'empowered' we felt.

'Great' I thought.  I chance to voice an opinion, vent some frustration and maybe, MAYBE, even help to change things for the better (no, I'm neither delusional nor stupid - I didn't believe that last one for a second).

I had a quick glance round the office to make sure my boss wasn't around - he'd have spotted the dip in productivity with a blindfold on at a thousand yards.

I clicked the link (after the usual concerns that it was a test of how easily we might be caught out by phishing scams) AND...

NOTHING

 Because as I flexed my fingers over the keyboard I couldn't think of any examples where a lack of empowerment had hamstrung me.

So I refreshed myself on the concept:




Without any empowerment we would, essentially, be subject to a prescriptive and highly inflexible regime.  Trotting out 'projects by numbers' slowly, inefficiently and with the minimal possible creativity.  Approval gates, formal boards and the ticking of process boxes would cast into shadow the actual project delivery. (Who am I kidding, we all know someone who's worked somewhere like this)

But empowerment can't be the granting of ALL powers to ALL people.  That would be anarchy.  The Developers would all be working on some really esoteric issue that they think is interesting while Production bugs would go untamed.  The testers would probably be found wherever there was a good source of tea and the Business Analysts would abandon the whiteboards and start drawing process maps on every conceivable surface.

So...

That brings us to one of my favourite watchwords: BALANCE.

On the one hand
I want to be empowered
to get on with my projects
without constantly needing
to seek permission
On the other, 
I want access to
 senior management for
 support, for escalations
 and sometimes, even, 
(now and then) for direction.

I want to be empowered to:
  • choose my own approaches to delivery, documentation and reporting (to some extent)
  • move, share and redeploy my resources in a way that keeps the highest priority work moving.
  • speak to and work with all internal and external suppliers and customers
  • be honest in my communications
  • make decisions (at an appropriate level) without recourse to higher powers 

And therein lay my issue as I sat pondering the requested feedback.

I am already empowered to do the things I should be empowered to do.

I can already imagine my colleagues raising an eyebrow and mentioning the things that hold us up:

  • getting access to specialist resource
  • 'colleagues' in remote locations who work completely differently and hold us up
  • parts of the organisation who insist on paperwork over productivity
  • slow/broken kit
  • not having the right tools for the job

None of these are insurmountable obstacles and occasionally there is an opportunity to make an improvement that we can grab.  But these tend to be small and covert tweaks (the conference phones we 'acquired' from an undisclosed location so we could actually use our meeting rooms.  2 years of trying to get permission went nowhere so we had to go rogue.)

The things that really hurt our productivity generally require large spends.

And while empowerment is an excellent buzzword to make us feel like we're in control of our own work-lives, we will NEVER be empowered to spend this sort of budget without starting our own company.

If empowerment means we're abandoned to suffer without support from above then it's no solution at all.

Simply:
  1. Empower us so we can understand the landscape
  2. Give us a way to feedback our blockers and improvement ideas
  3. ACT UPON THE FEEDBACK
As opposed to :
  1. Tell us we're empowered but just give up supporting us.
  2. Request regular feedback
  3. Ignore all feedback
Labels:

Comments

Post a Comment

Popular posts from this blog

The case for Project Management in Agile?

OK, I know how most of the Agile community feels about Project Managers: Process over People Meetings Documentation Urrgh... But however you name the role (Agile Delivery, Scrum Master, Project Manager) and whoever does it  - someone needs to help the team to: Plan Track Deliver Communicate Being a group of incredibly talented engineers does not give a team the right to ignore 3.5 of these. All too often, engineers want to dive in to designing and building great software, but see planning as a hassle, tracking as a waste of time (or an abuse of their rights), communication as an alien concept and delivery (the fun bit) as something that will be done when it's done. It may be popular to talk about being a 'self-organising team' and railing against any form of 'order' being imposed.  But why is that order being imposed?  Maybe it's to deal with the chaos that your s-o-t has failed to deal with so far. As organisations scale and the senior leadership gets further a...
Post a Comment
Read more

Agile Armchair Generals

If you're an Agile practitioner of any sort you will understand what I mean by Armchair Generals (if not, it may be an idea to check if you are one..). Apropos of nothing an email arrives that questions the management of your project in terms of whether it is properly 'Agile'. Feedback is, of course, a great tool.  But it must always be understood within the context of the person providing it. So when the email lands questioning the type of contingency you've built into your project or the depth of analysis performed on your requirements set, ask yourself: 1. Has the questioner spotted something you and the team have missed? It happens.  That's why independent reviews can be helpful. 2. Has the questioner misunderstood something about your project?  If so, maybe your communications weren't quite clear enough or they've missed something - it happens, we're all busy. If the questioner has understood the topic correctly and is simply disagreeing ...
Post a Comment
Read more

Project Team morale and how it is affected by YOUR leadership style.

If I asked what qualifies someone to lead an IT Project you might immediately think of literal qualifications; a degree, a PRINCE2 practitioner certificate, DSDM certification. You might think of the practical skills needed to achieve Project Management tasks; the ability to plan, management of RAID/CARDI items, stakeholder communication. All of these things are vital to managing a project, but as we're often reminded: Management ≠ Leadership And projects need leaders.   Why?  Because people need leaders.  Humans are pack orientated creatures and we are most comfortable within a structure that supports and guides us.  Within a project the same is true.  The 'doers' usually thrive within a supporting structure that takes care of their (professional) needs and protects them from attack.  Without Developers and Testers the rest of the project team is just a lot of expensive * flesh. In a mature and capable project team there is a certain joy to be ...
Post a Comment
Read more