Software: Art, Craft, or Business? - continued
Continued from:
http://www.6thsenseanalytics.com/blog/posts/638/
As it so happens in a recent Joel on Software series, Joel examined several software team management styles. There were a couple of references that I'd like to bring out that relate to my current business theme. However you'll also see connections back to my past blog themes on team leadership�
Check www.joelonsoftware.com for all of these posts and a vast history of solid insight and extremely relevant council.
Joel basically defined 3 levels of software management or leadership:
- Command & Control - Telling folks exactly the right thing to do
- Econ 101 - Provide incentive ($) for folks to do the right thing
- Identity Method - Gaining mindshare so that folks want to do the right thing
in a series of recent posts. In the Econ 101 post he makes the following statement:
The biggest problem with Econ 101 management, though, is that it's not management at all: it's really more of an abdication of management. A deliberate refusal to figure out how things can be made better. It's a sign that management simply doesn't know how to teach people to do better work, so they force everybody in the system to come up with their own way of doing it.
This made me think about my own experience with Econ 101 management and I've seen quite a lot of it. I think there is a significant population of managers who subscribe to this philosophy which isn't leadership at all. It's unfortunate really because it gives the profession a bad name (read that as pointy headed managers) and is truly an immature and ineffective style.
Personally, I've always been a leader who wants to understand the nuance of my team. I've always been interested in metrics, capabilities, complex relationships, performance differences, characterizing technical challenge and the myriad of variables that make up the dynamics of software development. Why? First, I consider it my job. Not so I could micromanage or tell developers specifically what to do. And not so I could set up incentives for them to guess what to do.
Rather, I was looking to coach and improve my teams. To understand the performance proposition in each unique team context in which I was working and then to guide the team forward - towards improved performance. Not performance for its own sake, but connecting it towards the business goals of the organization. My role was essentially to lead.
One of the reasons that I'm so attracted to 6th Sense Analytics is the level of data they provide. For inquisitive, non-Econ 101 style managers, it uniquely provides the insights you need to be able to effectively coach, guide, and lead your teams to greatness. Joel hits it in the post, it's not about telling or throwing dollars at them. It's about insightful leadership that connects to the team and business context.
In this same post, Joel mentioned the work of Robert Austin in the following excerpt:
Robert Austin, in his book Measuring and Managing Performance in Organizations, says there are two phases when you introduce new performance metrics. At first, you actually get what you wanted, because nobody has figured out how to cheat. In the second phase, you actually get something worse, as everyone figures out the trick to maximizing the thing that you're measuring, even at the cost of ruining the company.
Worse, Econ 101 managers think that they can somehow avoid this situation just by tweaking the metrics. Dr. Austin's conclusion is that you just can't. It never works. No matter how much you try to adjust the metrics to reflect what you think you want, it always backfires.
I just wanted to mention that Dr. Austin is on the Technical Advisory Board of 6th Sense Analytics. I also wanted to point out that our metrics disrupt some of the basic assertions that run through his work�first is the cost of collection and second is the notion of gaming. If you consider the essence of our sensor-based model, both of these assertions are clearly and fundamentally affected. I also think Joel takes some liberty in paraphrasing Austin, particularly the overall potential for success of metrics programs. If done correctly, metrics can be driven successfully and Austin provides examples of such.
I realize that I went slightly off point, but the Joel posts connected too well to my recent themes to pass up. In his final post he provides an example of a conversation he had with a project manager over a planned release date. In order to truly create mindshare, he doesn't tell or incent, instead he discusses the business forces influencing the earlier release date. How it maps into his companies economics (the business) and the actual budgetary trade-offs associated with the December 2006 vs. April 2007 release decision. He provided data and looked to create an insightful, team-based, decision.
Joel is immensely respected in the community, as is Greg Brunell. And both of these guys truly "get" the nature of software development and how metrics-driven leadership fits into driving business value as an outcome from today's software teams. So, software is ALSO about the BUSINESS and may we never again lose sight of this principle!
Previous Post:
Challenging Assumptions
Next Post:
6th Sense Analytics Selected by the Council for Entrepreneurial Development for Demo Showcase
