I saw a great quote the other day referenced on a blog. I can't stop thinking about it. It's from the book "Powerful Project Leadership" and the quote is:
"Managers use people to accomplish work; leaders use work to grow people".
This quote captures a great deal of what I think about leadership. It's about really caring about people. You can try to fake it (ala "How to Win Friends and Influence People"), but folks can see through the ruse. True leadership requires, I think, a fundamental desire to develop people to their ultimate potential. It's sort of like the adage "Satisfy the customer; the profits will follow" with a twist: "Satisfy the fundamental needs of your employees to contribute and grow, and the profits will follow".
Thursday, October 18, 2007
Sunday, October 07, 2007
Agile Leadership and Typical Management Titles
I worked at a very big company as a software engineer for 15 years. When I began out of college, my title was "junior programmer". The promotion path was well known. Perform at a level between barely satisfactory and outstanding and get promoted in a year to "associate programmer". Keep doing a satisfactory job, get promoted again two years later to "senior associate programmer". Two more years and it was "staff programmer" (and get your own office). Promotions after that were less structured/timed and based strictly on merit.
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):
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?
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.
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.
Subscribe to:
Posts (Atom)
