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

Continuous (Self) Improvement

“Everyone thinks of changing the world, but no one thinks of changing himself.” - Leo Tolstoy Introduction: Most people talk a great game about continuous improvement.  And as a group, most of us truly agree with and see the benefits of, the concept as applied to our projects and teams. Sprint Retrospectives, Post Implementation Reviews, 5S, DMAIC, PDSA (not the dog people) and so on. But... Do you practice it personally ?  I don't mean training courses, formal development plans and all the other bureaucracy that people step through stoically every year in a bid to get a pay rise.  I'm referring to the small (but meaningful) improvements we can make every day. Or to work in an Agile principle: "At regular intervals, the team (of one in this case) reflects on how  to become more effective, then tunes and adjusts  its behavior accordingly." Step 1: Feedback (aka input to the CI process): Of course, all improvements need to be identified i...
Post a Comment
Read more

"We are Agile!"

A phrase Project Managers hear a lot, and one that occasionally proves to be at least partly true. As it's most often spoken rather than written, it is hard to know whether the speaker means 'agile' or 'Agile'.  I find that asking the question ('big A' Agile or 'small a' agile?) can reveal a lot about that person's knowledge of the 'Agile' world.  If you find yourself asking the people around you this question and you receive blank faces or confused responses you can be fairly certain you haven't landed in a particularly Agile organisation, rather you're somewhere that has rolled out a buzzword in the hope of improving speed of delivery. Organisations tend to fall into one of the following categories: - Comfortably Waterfall - Fine . This organisation knows how it wants to work and perhaps has reasons why they prefer to keep projects waterfall. - Waterfall but concerned they need to get on the Agile bandwagon - Confused ....
Post a Comment
Read more

Definition of Done - An example

Done? To call a story 'Done-Done' we should refer to two things: the acceptance criteria for each story the team’s Definition of Done The DoD is defined by the team and should be updated whenever it seems appropriate e.g if there's a big change in the team or the work; or the team simply sees the need for a change. If you have project based teams, it's something to agree before timebox 1 kicks off. If you're more product based and continuously working through an ever growing backlog, slot it into a timebox kick-off, a retro (if that's where it was discussed) or just grab 10 minutes after the daily stand-up. An Example: Here's a basic example created by a team I was working with: ---------------------------------------------------------- A. Dev done ---- Code review done ---- Unit Tests written and passing ---- Integration tests written and passing B. Test complete ---- Manual Testing complete – Acceptance Met ---- Automation Tests written and ...
Post a Comment
Read more