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 reasonable 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”? (Remember – Servant Leadership). 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 KitIn order to work more productivelyAs a DeveloperI 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 kitGiven I have a sudden need for a new piece of kit
When I request that new piece of kitThen...Story: Development Team Needs a New Team MemberIn order to continue meeting commitments to our stakeholdersAs a Development TeamWe need to find and enrol a new team memberScenario 1: We know of someone who could fill the roleGiven some folks already know someone who would be a good fitWhen we need to make them a job offerThen...

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 “management” 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:

1. Add a test – the simplest possible
2. See it fail (red)
3. Make all tests (to date) pass, using the minimum amount of instructions (green)
4. Refactor

Using this approach, the manager can – incrementally – implement some part – or all – of each “service” story, in turn. Of course, the “instructions” will not likely 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.

Your thoughts?

– Bob

Further Reading

Servant Leadership ~ Greenleaf
The Responsibility Virus ~ Roger L Martin