Manage As If You Meant It
(With thanks to Keith Braithwaite for inspiring the title of this post)
Wouldn’t it be great if you had a specification describing the “API to your manager”? I mean, think of all the things a useful manager can do for her people, and how many of these things never happen – or at best, happen haphazardly – because no one knows they’re there, how to invoke them or how to track things?
Aside: At this point, you may just be reminded of Robert K. Greenleaf’s idea of Servant Leadership. If we have to have leadership at all, then maybe servant leadership is a fair kind of leadership to hope for. Or perhaps Host Leadership.
As well as providing generally improved clarity regarding what a manager can and will do, a well-defined API might – as Roger Martin writes in The Responsibility Virus – “help people avoid the natural predisposition to screw up the handling of responsibility in ways that undermine their goals and well-being,”
If a manager embraced the idea of an API, and, more specifically, wanted to develop one, how might that happen?
Aside: I’ve been musing on the idea recently, as an offshoot of some work I’ve been doing on Product-Development-as-a-service. This latter may likely be the topic of a future post.
The Manager API
So, the thought occurred to me, could we use something like BDD to facilitate a conversation between a manager and the folks to whom she’s providing services – not least the folks she’s “managing”? In other words, what benefits might accrue from having clarity on what the manager can (and can’t) do for her people, and for others who might, from time to time, also ask her to do things for them?
Here’s a couple of examples of stories that might be relevant for this “Manager API”:
Story: Developer Needs a New Piece of Kit In order to work more productively As a Developer I need to have a way to obtain the necessary kit (computers, peripherals, software tools, etc). for the job at hand. Scenario 1: I have a sudden need for a piece of kit Given I have a sudden need for a new piece of kit When I request that new piece of kit Then... Story: Development Team Needs a New Team Member In order to continue meeting commitments to our stakeholders As a Development Team We need to find and enrol a new team member Scenario 1: We know of someone who could fill the role Given some folks already know someone who would be a good fit When we need to make them a job offer Then...
The TDD Connection
OK, so let’s assume that our manager has been having conversations with her stakeholders, and has identified some (early) versions of some stories worthy of implementation. How to approach such implementation?
Here, might Test Driven Development be helpful? Using TDD, the service implementation can emerge and evolve without much (hard) thinking. Here’s the vanilla TDD four-step red-green-refactor process:
- Add a test – the simplest possible
- See it fail (red)
- Make all tests (to date) pass, using the minimum amount of instructions (green)
Using this approach, the manager can – incrementally – implement some part – or all – of each “service” story, in turn. Of course, the “instructions” will not be coded in a programming language, for execution by a computer, but in human-readable e.g. pseudo-code or work instructions, for herself, and for others helping her deliver the service.