Well... OK... not just merit.
Of course there was also the management path at this company, but the gig was the same.... keep doing a good job, keep climbing that ladder.
I'm now an agile guy. I look back and can't believe I had to function in such a dysfunctional system. I left that far behind. Or so I thought.
As a consultant, I get to operate in many different environments. Sometimes I get to work with just my team - the enlightened, intelligent, cutting-edge consultants at Thoughtworks and we can build a sort of bubble of rationality - a pseudo meritocracy. More often, I have to manage within the constructs of the company in which I am consulting. Many of them look like my first company where employees are operating on the ladder path.... climbing away. So the question is: when you remove rungs off the ladder in the flattening exercise (whether explicitly or implicitly), what becomes of those who were on those rungs?
Different positions - whether higher (1) on the ladder, lateral, or even lower (1) require different skills and expertise. If you're a developer, you may get promoted to "development manager" because you write great software. The aptitude, skills and motivation to write great software are very different from the aptitude, knowledge, and motivation required to be a good manager or leader. Moving "down" the ladder - say, back to writing software - usually requires missing skills, since technology changes so quickly.
So what aptitude, skills, and motivation do agile leaders need? Here's my list (in no particular order):
- Communication/Collaboration skills - "down" - in coaching and developing people within your organization
- Communication/Collaboration skills - "across" - in collaborating with folks on peer projects, others within IT
- Communication/Collaboration skills - "up" - in managing relationships with higher level IT management/leadership
- Communication/Collaboration skills - "Business" - in managing relationships with the business
- Technical skills - understanding the technology, architecture
- Domain knowledge - understanding the business
- Agile Project Management - from estimation and planning to iteration tracking
- Ability to inspire
- A fundamental philosophy that prefers frequent inspection and adaption to continuously improve
The key for the project, I think, is to ensure that these responsibilities are represented in the leadership team overall, not necessarily in one person.
How do these map to more traditional hierarchical positions?
- development/QA/BA manager (managing a group of folks based on functional alignment)
- lead developer/QA/BA (individual contributor who is annointed with the "lead" adjective).
- architect (might be a member of an architecture team, or may just be a responsibility for someone holding a different title)
- director of development (overseeing everything from requirements to release for a project)
- C-level leader (person who holds the pursestrings, defines strategy, provides the context & constraints in which the project must operate)
Any of the folks in these positions can provide agile leadership. In general, the more of these leadership aspects that are exhibited by folks in leadership roles the better. For example, though the C-level leader is likely to have ability to inspire, having a development manager who can also inspire can be a great bonus for the project.
Stay tuned for more on each of the agile leadership opportunities I enumerated. In the meantime... tell me what I've missed.
(1) Higher and lower are expressed, for the purposes of this conversation, in terms of the typical hierarchical leadership. I'll save the servant leadership and inverted pyramid conversation for another time.
No comments:
Post a Comment