By Hillary Johnson
Journalism is a lot like software development (or anything else for that matter) in that it's common practice for top performers to eventually move into management, in large part because that also happens to be the path to financial well-being. The worst editors I've ever worked for, and I've worked for a lot in a 20 year freelance career, were genius writers turned editor. The best editors where those who had experience working as writers, but never felt that role was a good fit. Sometimes they had even failed as writers. As editors, these people appreciated and respected their writers precisely because: 1) they knew how challenging the job was, 2) they were never inclined to think they could do a task better themselves, 3) they didn't perceive themselves as having risen "above" those they managed, but as having taken a different path.
The point being, we're all talentless hacks at something, and the sooner we recognize it, the better we'll each be at what we're actually good at.
I was prompted to reflect on all of this by Alistair Cockburn's post about a recent discussion at the Salt Lake City Agile Roundtable where everyone offered up advice to a new team lead, ie, one promoted from star programmer to manager. It's a great collection of thoughts, listed as bullet points, including "In almost any high-skill arena, taking the top performers and making them coaches/managers is almost always a disaster." And, "How can we make it acceptable to promote the people who may not be the top technical performers?!?" Another mentioned the need for companies to create technical tracks that don't require one to move into management to move up.
All of this leads me back to the notion that hierarchy is a poor framework for knowledge work. The native structure of a productive creative team is the network, a system comprised of various nodes, gaining strength through interconnectedness. Think of it as a geodesic dome, rather than a skyscraper. A team need people in roles, rather than positions. What we have a hard time wrapping our minds around is the concept of manager as an equal, not a superior.
It strikes me that the role of Scrum Master is designed to function in this way, and it's interesting that one of the challenges people trying to grasp Scrum for the first time is wrapping their minds around the idea that the Scrum Master isn't a leader in the traditional sense, but a facilitator. Maybe it's the rather unfortunately macho term itself--anyone who calls themselves "master" anything can quite naturally be assumed to be a bit of an assclown.
The notion of servant leadership is also aimed at correcting that very imbalance, but fails because it merely inverts the hierarchy, rather than dismantling or de-emphasizing it--it's still a hierarchy, and worse, it's phony. The only thing more arrogant than someone who calls themselves a "master" is someone who calls themselves a "servant." Sheesh!
What teams need are "peer leaders," those with a talent for human interaction who can be charged with maintaining the flow: a "Scrum Keeper" if you will.
