Marcato

A friend asked me the other day if I had any suggestions on bug classification systems.  While we didn’t get into the specifics, what I gathered was that with four different development teams in different geographies (they have grown by acquisition), they are trying to get to a common categorization scheme.  I inferred this was for two likely reasons – they want to try to merge these different sources of information into one list of field priorities and they are hoping to have this happen efficiently (if not automatically).  They currently use a severity/priority system and she was wondering whether I had used anything else that was simpler than this.

In short, I told her about the system I’ve used for years – I’ll break it down in case you find it useful, but I don’t think the classification scheme is novel.  In fact, it’s the same severity/frequency system she was already using.  For any defect, there are two things that matter – how severe is the problem when it happens (does it crash the system or is it cosmetic, is there a workaround available?) and how often is it affecting your customers (something all users do every day or off the beaten path used only by a small percentage of your customers).  This is the same categorization that we use today and we even show the top issues mapped this way on a 2-D graph for the executive team each week.

So, now assume that you have 100 defects all rated with these two values on a scale of one to ten (with ten being the most severe or having the broadest impact).  Let’s also assume you have a team of people allocated to work on these defects.  Which ones do they fix first?  The one that crashes the system once a week or the one that requires all users to work around a defect 10 times a day?  Is there a simpler formula that maps the 2 dimensional categorization scheme into a simple priority list?  What if I multiply the severity by PI and then multiply that by the square root of the frequency?  Or maybe I just simply add them up?

Well, there is, but you’re not going to like it (I don’t think she did either).  The system is simple, but it is anything but automatic.  The secret?  A cross functional team needs to meet on a regular basis for the sole purpose of updating the ordered list.

See – I told you that you would not find it particularly profound.  What is profound is that if you want the system to work, then you really don’t have a choice but to put the time into it.  To explain further, let’s define “working” as “the team that fixes the problems knows what they need to do, why it is important, when it needs to be done, and what success will look in the eyes of the customer and all stakeholders involved feel that they had the opportunity to advocate for their customers and feel that the outcome is fair and equitable so they support the results rather than work to subvert the system”.  If you have some other definition of “working”, then you can probably cheat the system, but I challenge you to figure out which part of my statement you can remove and still feel like you are happy with the solution.

I see this happen time and again, particularly in the technical arena.  We “technical” people tend to think that efficiency is achieved by removing the people from the process.  In many realms, this is true, but what we fail to see is that some challenges can not be solved this way because they are inherently “political”.  Oddly enough, since engineers tend to shy away from conflict in public forums, we even tend to think that our automated system is a great idea because it eliminates all that messy discussion and confrontation.  We couldn’t be further from the truth.

So, even when all parties have had the chance to have their say, who decides?  The leader of the team that fixes the problems?  No way – the list would be based on which problems were easiest or most interesting to solve.  The head of sales?  Only if you want it to be based on what it will take to win the next deal.  In my experience, the best answer is the lead of the support escalation team, coached to make these decisions in order of impact to the field.  The reason that I would invest this power in that individual is because I firmly believe that in the long run people make decisions in their own self-interest, so the key to getting what you want out of the system is to align their interests with the interests of the people that should really matter – your customers.  While not perfect, the best proxy for field impact is the number of customer issues opened in your support team that would be prevented if the item were fixed.  Said another way, anything that you do which reduces the number of calls or emails you receive to report problems is good.  Listen to the leadership within your support team, and good things will happen.

To summarize our system, all defects are given both severity and frequency ratings on a scale of one to ten, but all work in the development escalation team is driven by a single, ordered list that makes the priority of the work clear.  We meet once a week to review and update the list, with representatives of support and PD present, but the decision on how to rank them is made by our Tier 3 lead.

Some things to watch out for – multiple lists, grouping, and action-ability. 

“One list shall rule them all” needs to be your mantra – there will be lots of innocent reasons to consider breaking out sections of the list so that you can see how many bugs related to each feature their are, etc., but in the end, if there is more than one list then your team that does the work will be confused about how to decide between the 5 “number 1″ priorities that come from each list.  You’ll feel better because you are able to avoid conflict this way (just let each team keep their own list, right?), but less will get done, and they’ll work on the wrong things.  Keeping more than one list is just an invitation for the technical team doing the fixes to choose the work they really want to do instead of what is needed.

Grouping is the attempt to combine issues together in order to influence the priority – I’ve got 15 different reporting issues but I’ll just combine them into one that I call “Reporting Issues”.  The impact is magnified because I have lots of customers affected when I lump them together – by doing this I took 15 separately minor issue and made the critical en masse.  Why doesn’t this work?  Because your fix team still has to work on fixing them one at a time, and when they do, the criticality of the work they are doing will seem hollow.  You won’t fool them but instead only undermine your authority and their motivation.

Finally, and with apologies to every English teacher I ever had, “action-ability” – is it clear what the technical team needs to do to fix the problem?  All to often I have seen “boil the ocean” issues listed such as “make system more reliable” – again, the more vague you are, the less likely you are to get what you want.  Someone needs to have the job of translating the source of pain (customers keep calling to report that the system is slow) into actionable work (it takes 3 minutes for the employee list page to come up if you use the page during the busy hours) – this is usually the job of the Tier 3 escalation team working in conjunction with the lead from PD Escalation – this is THE critical role for making the system work, so make sure you get the best possible person into it.

CK

Configuration Management Vision

Configuration Management (CM) exists to provide predictability, control, and tracking of the source code that is used to build our binaries and the binaries that are used to build our releases.  Every going concern in the commercial software business has some system in place for providing these capabilities.  This translates into a few basic requirements (ordered by priority):

• The ability to build development builds, release candidates, and releases
• The ability to retrieve release images for every version of every released product
• The infrastructure required to selectively hotfix a build (but not create or deliver the actual hotfix – this remains the responsibility of the PD Escalation team)
• The ability to reproduce a build
• The ability to trace from a release or individual binary version back to the binaries and source that constitute that release version

While these are the core responsibilities for CM, there is still room for a great deal of interpretation in how these are accomplished, and I believe that the expression of these responsibilities into tools and processes can either limit CM to being a tactical contributor to the development process or allow it to play a central and strategic role in enabling new processes and development organizations.  CM needs to be a team member in every product development effort we have if this strategic contribution is going to be a reality.  Here is a list of additional requirements for CM that give it a more strategic role (and the associated processes or team configurations that it enables); some of them overlap as they represent different levels of a capability and investment of time and associated tool costs:

Our vision for CM is to provide any or all of these advanced capabilities while limiting the human cost associated with delivering them.  This means choosing and building tools that have minimal human involvement and administration that can be delegated to IT.  This allows our scarce CM resource to stay focused on the development of expanded capabilities instead of becoming trapped within the administration overhead of the existing system.  The size of the CM team will not scale with the size of the product development organization, but we will invest capital in constantly improving its efficiency through the use of better tools and technology.

What CM Is Not

CM has often had a larger role as we expanded the definition to include other activities.  In the past, these have grown to include the development and maintenance of installations, administration of version control, archiving of history, user administration, source code security, and more.  While CM provides the build infrastructure, CM does not have primary responsibility for the success of a build.  They are responsible for ensuring that their build scripts are correct, but ideally any order dependencies would be captured in files maintained by the development team; it does not make sense to split out the responsibility for maintaining build dependences from development as only they will know when they have made a change that will change the order dependencies. 

CM is one of the most demanding users of our version control system, and as such should have a central role in its selection.  However, I consider the basic capability of having, using, administering, and maintaining the selected tool a 24×7 tactical role best provided by our IT organization. 

While these are all necessary activities, centralizing them into CM either does not make sense as it is inefficient and error-prone to rely on effective communication across team boundaries.  These functions belong either within the team that is responsible for creating the product or within the IT organization where they can receive appropriate support.

In a rare departure from my normal reluctance to strongly endorse the opinions of others, I did once decide to put my money where my mouth is:

http://agilemanifesto.org/sign/display.cgi?ms=000000074

Enough said…

<Reprinted from www.projectknighton.com/ckblog>

For those of us ancient enough to remember the birth of e-commerce, you can probably recall that ten years ago we were all worried that this new medium was unsecure and that using it would put us and our personal information at risk. God forbid we would actually let them store our credit card information for us – the less they knew about us, the better.

Now, ten years later, I wish I could get back the hours spent retyping in the same contact information, billing address, etc and I readily accept that these companies know a lot about me, that they are inferring from my behavior that there might be other products and services that I want, and that they keep a close eye on my purchases and follow up with me to find out if I was satisfied. I’m amazed how quickly familiarity and convenience can overcome paranoia.

One of the many pleasant surprises I have encountered now that I have moved from packaged software to software as a service is the remarkable opportunity to improve how customers are served through their entire lifetime of using the service. Of course, if you are looking for a sinister motive, then “the man” is only using your confidential information to exploit you by forcing you to get the full value out of their product. Is that really so wrong? So, let me get this straight – every month I get my bill and decide whether or not I will pay it or cancel the service. With this awesome power they now have they are somehow forcing me to feel happy with the service and to believe that I am getting enough value to continue?

No, of course not. In fact, I would argue instead that the new model is much better both for the provider and the consumer. The consumer now gets to decide very frequently if the service has value and if they will continue, and the provider gets to use their knowledge of the consumer’s use of the service to figure out how to make sure they are getting their money’s worth.

I suspect there is a subtle economic truth in here – every product would be better if offered as a service. Commodity consumer products work like this, and this is why these companies invest so much in brand and reputation. They have to because there are so many opportunities for substitution. But back to digital products – if the product is software offered as a service, then it’s quite practical to monitor the product’s usage and to assess if the customer is actively engaged and happy with the product, or worse, to be able to predict that their use is waning and that they are likely to churn.

There is an ethical hazard here to consider – believe it or not, in some cases people or organizations will continue to pay for a service that they do not use. I logged into my cell phone account to add a new service to one of my phones and among other things discovered that I was paying $2 a month for roadside assistance for my son that does not even have his driver’s license. So, here is the question – if I am a service provider and I see that a customer is not using a feature of my service for which they are paying, should I tell them?

Some day there may be companies that actually differentiate themselves by behaving this way, but I suspect that most companies today would simply stop communicating with that customer for fear that they would raise their attention to this fact and only hasten their departure.

Now, imagine if you will, that we take this idea of monitoring usage of a service as a service in and of itself. Imagine that you are a provider of a service but have not yet figured out what are the critical use patterns that indicate a healthy customer nor have you built the tools that would mine the data for these patterns and provide reports and alerts as to the health of your customers. If so, then I would guess that you would find value in a meta-service that did this for you. In our case, we are doing this for ourselves, but as the SAAS model continues to proliferate, so will the demand for such Service-As-A-Service offerings. We know from practical experience that this is not easy to do and is hard to enable through competing for scarce product development resources. If only someone could do it for you…

At the risk of introducing an entirely different topic late in the game, I think that one thing that Google has done for (or to) the software industry is to get many of us to thing of software applications as “content”. That is, we are beginning to expect them to constantly change and evolve, to stay fresh, to regularly add new features, and to not have to pay for them. This new visibility into customer usage patterns also enables this – it allows you to watch how new features are adopted and what can be trimmed as unnecessary feature bloat.

There is great value in knowing how an individual customer is graded today, but even more in knowing that their scores are gradually falling and if not corrected will likely lead to a precipitous decline and churn. With this kind of information, customers can be nudged back to health instead of a drastic intervention in an attempt to recover. With this should come a better world for software in which customers only pay for the software they use and providers only invest in the features that sell.

There are many books that I have read over the years that have influenced my thinking about software developer processes, but probably the most influential had nothing to do (at least on the surface) with software development. That book is “The Goal” by Eli Goldratt.

Eli is a physicist with the rare talent to be able to apply his understanding of the mathematics behind the behavior of complex systems into a very easy to understand novel about a plant manager faced with the challenge of trying to figure out how to save his plant and make his company more profitable.

At the risk of spoiling the book (it won’t, and it’s such an easy read that you will find that you learn much more by doing it), let me tell you about what I learned. The first and most important lesson is about process bottlenecks and how to identify them. Every process with dependent steps has a process bottleneck – to find it all you need to do is to look for the step that has work in process piled in front of it. Closely related to this is the notion that all work in process us waste – “lean” thinking in manufacturing or any process design focuses on removing that waste by balancing the capacities of all steps in the process.

In the book he tells a memorable story about a scout troop that has a goal of getting their entire troop to a destination by a certain time. Inevitably, there is one scout that just can’t keep up (more of that rampant obesity in America’s youth!). At first they just let him fall behind, but someone finally realizes that this doesn’t work as they still fail in their objective. Next they try tying a rope between themselves so that no one can go any faster than the slowest person. This keeps them together but

Then good things start to happen – because they are tied together, they realize that the only way they can succeed is to help the slowest person go faster. They start volunteering to help carry his pack and other supplies, and the net result is that the team starts to move faster.

I read this book during a time when I still thought of testing as a downstream function performed at the completion of coding activity. I was also working on shortening release cycles and was looking at how to pipeline releases so that I could keep the developers busy building v2 while v1 was being tested. However, what I saw was that this trapped us in a cycle that guaranteed the testers could not participate in design of v2 and led to frequent complaints about inadequate design documentation and lack of access to the developers during testing.

My systems engineering training taught me one important thing – delays in systems lead to instability. In effect, the delays between development and testing were leading to both poor quality as well as lots of gyrations to try to accommodate the differences in time of these activities. Also, there was a tendency to under staff the testing function, further exacerbating the problem as this shared resource pool was frequently switched in and out of projects based on timing and need with no long term association or specialization.

To solve all of the problems, I needed a “rope” to tie these functions together. That rope took to tangible forms – first, testers were assigned into teams so that they were part of the team for the full lifecycle of the work, and second, we started adopting agile practices with shorter iterations focused on completing whole features and no one on the team was done with the sprint until the whole team is done and the story can be closed.

With this model in place lots of things became apparent – there was not enough testing capacity, so developers had to lend a hand in certain situations until we could fix the ratio. Testers were part of the full cycle of developing the feature and should never be left behind. I no longer had large piles of work in process sitting waiting for testing resources to become available. And finally, perceived throughput better matched real throughput – in fact, the perception of every company I have been in that does this is that even if it means fewer developers, more features are making it to market faster.

So, if you are looking for inspiration yourself, check out “The Goal”.

Several years ago I was inspired to give a speech (not just a presentation but a real, formal, written speech) as part of redefining my role as a leader to be a stronger advocate for quality.  While many of the references are probably not meaningful to people that are unfamiliar with the products of my employer, I found as I re-read it that the themes still carry and it was better to leave it in its original form than to try to scrub it.  Without further ado…

Quality Talk

<Reprinted from www.projectknighton.com/ckblog>

I was reminded yesterday that I had written a paper for a Quality Management class a year ago that is worth sharing. The basic premise is to track the evolution of software development methodologies and to relate them to Quality principles and methodologies that have developed in parallel, finally leading up to the integration of Lean and Agile into an approach to software development that is very powerful. Enjoy…

Quality In Software

<Reprinted from www.projectknighton.com/ckblog>

The context of the title of this post was a discussion about knowledge management, but the phrase triggered a tangentially related idea that I’ve been meaning to write about – the convergence of 2-D and 3-D mapping and virtual reality models with location-based applications. If you tried the Second Life application, you know what I mean by the former, but I should probably explain what I mean by a location-based application. We now have readily available technology in our cell phones, smart devices or dedicated navigation systems to provide our software applications a sense of where you are at any given time. This means that we now have the ability to associate information with the location where that information was entered, gathered, or used.

Let’s look at a simple example of how these could intersect into a solution that is more compelling than the products offered today – a personal digital photo library. Today we have traditional applications that collect the photos into a library that you can browse; the pictures often have date/time information attached to them, so it’s easy and natural to construct a library that organizes the pictures by time. If you are disciplined about managing your library, you might also actually sort them all by location, but who has the time for that?

Imagine instead a world where you take pictures with either your cell phone or your camera (these are converging too…), but regardless of which you use, every picture you take not only has a time but also a GPS location (stored in latitude/longitude) and maybe even a heading (direction you were pointed when you took the picture).

Now imagine uploading your pictures into a 3-D world that represents the actual world. Your 2-D and 3-D perspectives in this world would show you your digital library organized by place. Every picture would show up on the map or in the world exactly where you took it.

Now, I don’t know about you, but my memory is awful for remembering details like what year it was when I took that trip to Yellowstone, but I do remember Yellowstone and I do remember where it is on a map. What if I could zoom out in my perspective and see that I had a cluster of pictures in Wyoming, then zoom in on that cluster and see the detail of the geography start to fill in with names of roads, towns, and eventually even specific landmarks such as Old Faithful rendered on the map/world. Then I could see floating in space in front of me the pictures I took of Old Faithful.

This is a simple example of how to associate information with location, but a powerful one, and all of the technology exists today to combine these into a compelling new solution. Let’s see who does it first…

<Reprinted from www.projectknighton.com/ckblog>

I have a great deal of empathy for anyone that tries to explain service-oriented architecture, especially to a non-technical audience. When this trend first hit the market a few years ago, I was the VP of product development at another company and it was my job to explain our SOA strategy, both in white paper and presentation form. I think that this is difficult for several reasons.

First, the people you are talking to expect to get some kind of “ah hah!” moment that probably doesn’t happen. This might be because they can’t relate to the details in their own business and think that their business and technology already works that way, or instead because they do know those details and really struggle to try to imagine how to separate all the things that happen every day out into well defined processes with distinct components that can be abstracted such that substitution of alternatives becomes a practical reality. Either way, the look I used to see on people’s faces was always one of confusion rather than enlightenment.

Second, if the audience is technical, they tend to think not about the positive impact to the business of better clarity for processes and the agility that can come from an organization that is so transparent that its operations can be summarized by a process chart. Instead, they think about the bits and bytes – hey, this is just good programming practice and of course I would build my product to be modular. SOAP? Big deal; it’s just fancy function calls that work across different machines and technologies. Yeah, it’s nice that it’s standard, but let me tell you about all of the limitations. It’s not secure, it’s really only discoverable and reusable if you limit yourself to simple data types, and it’s painfully inefficient and therefore hard to scale for high volume applications.

Third, few people have a lens broad enough to encompass both the technical implications and the organizational impact that SOA can have, and even more rare would be finding someone with the leadership and change management skills to drive the transformation of both domains that is needed. The scope of participation is just as broad as any quality initiative – pick your favorite based on your age: Total Quality Management, ISO 9000, Business Process Re-engineering, Six Sigma, you name it…

Finally, because the movement started as a technology initiative, my view is that it still reflects a set of ideas such as interfaces that are abstractions more easily accomplished in the theoretical world of software architecture than in the practical world of business. The reality I see is that the majority of activity in any business is reactive, unstructured, and ad hoc. Information flows through the organization through conversations, emails, instant messages, presentations, written documents, pictures, etc and software systems have a difficult time dealing with these as anything but opaque blobs of stuff that only a human can understand and categorize. Software systems have come a long way in attempting to bridge this gap and turn unstructured data into categorized information, but these systems can’t finish the whole job as they can’t really determine meaning, intent, or the potential value of the information to specific people.

The net result is that the system would be perfect if it wasn’t for the carbon-based lifeforms that are also involved – if business happened solely through silicon talking to silicon, then reconfiguring a business by dragging and dropping shapes on a flowchart might become a practical reality, but as long as there are people involved we remain the weakest element in the design.

Yin and yang

Taijitu, the traditional symbol representing the forces of yin and yang. <http://en.wikipedia.org/wiki/Yin_and_yang>

My first real mentor in my professional career was (and still is) a brilliant man. While he taught me many things about technology, most of what I learned from him was about people, organizations, and leadership. While quite successful in his own right, he was not one that sought a leadership role because he wanted or needed to satisfy his ego. Rather, it was a job that someone needed to do and he served in that capacity until he was done, then moved on from that role and organization to do what he really wanted to do, which was to teach.

On many occasions I found myself frustrated with his tutoring. I would be in the midst of some dramatic and emotional situation and going to him for guidance in making a decision, but I would end up walking away even less certain of what path I should take and with a new homework assignment – a book to read. For him, the answers to life’s questions could be found in books, and there was no ailment he couldn’t fix with that prescription. While I don’t have the foggiest idea what was wrong at the time, more than once the answer was found in the Tao Te Ching.

“Yin (陰 or 阴 “shady place, north slope, south bank (river); cloudy, overcast”; Japanese: in or on; Korean: 음, Vietnamese: âm) is the dark element: it is passive, dark, feminine, negative, downward-seeking, consuming and corresponds to the night.” – From <http://en.wikipedia.org/wiki/Yin_and_yang>

Since my basic nature is to tend to view things as absolutes, I now believe that what he was trying to do was to teach me that knowledge of the simple extremes of black and white is important, you rarely get to apply such simple principles in being a leader and making decisions. When confronted with this duality, asking someone else what you should do may influence your decision, but for it to really be your decision it must come from an understanding of the full spectrum of possibilities available to you and a rational justification for the one that you choose. This can seem foreign to Americans as we are taught that the best leaders act from instinct (the gut) and lead with charisma (the heart).

Very early in my career I discovered two things – I was a generalist and a “natural” leader, whatever that is. As with all careers, I started with mastering the tactical – I satisfied my need to build things by learning as much about technology and engineering as I could before my curiosity was sated.

From there, I sought an understanding of strategy – this may sound cynical, but still to this day my favorite definition of what I learned is this: “strategic” is what you call the things you want to do that you can’t prove will help you win (make money, win the war, whatever the objective) but that you are going to do anyway. The transition from tactical executor to strategic thinker is one of the hardest career changes to make.

“Yang (陽 or 阳 “sunny place, south slope, north bank (river), sunshine”; Japanese: yō; Korean: 양, Vietnamese: dương) is the bright element: it is active, light, masculine, positive, upward-seeking, producing and corresponds to the daytime.” – From <http://en.wikipedia.org/wiki/Yin_and_yang>Although not really sequential, my next struggle was to understand the nature of credibility. In particular, how one can maintain credibility as a leader when the tools we use to get a result are people and they are fallible. Every leader puts their own personal credibility gained through past individual accomplishments at risk when they are placed in a leadership position, and it is a hard lesson to learn that the personality traits and behaviors that led to your success in the past are most likely going to contribute to your downfall in this new role.

Having navigated my way through these challenges, I have over the last few years struggled with how to best balance the yin and yang of leadership – creating a culture of accountability and excellence in execution while also nurturing and sustaining the needs of every individual in that team. Another way of stating the opposing forces is between timeliness and quality of work. In the software world, one ALWAYS compromises on the quality of work in order to ship – in fact, I am fond of stating that the only unnatural act in the software development process is to ship. People will willingly do everything else that you need.

“Yin is often symbolized by water and earth, while yang is symbolized by fire and air. Yin (dark) and yang (light) are descriptions of complementary opposites as well as absolutes. Any yin/yang duality can be viewed from another perspective. All forces in nature can be seen as existing in yin or yang states, and two produce constant movement/force of the universe.” – From <http://en.wikipedia.org/wiki/Yin_and_yang>

One of the first lessons in the leader’s handbook is to keep your message simple and consistent, especially when in public. In private, in a one-on-one situation you can afford to have a more nuanced discussion, but these details are lost in the realm of public debate, especially with other leaders in a public forum. This is the source of the problem – when one must choose ONE message, which message is it going to be? Shipping or Quality?

For years, my mantra has been shipping – in fact, my motto is “Shipito, Ergo Sum”, or “I ship, therefore I am”. This motto has served me well, as it allows me to focus on timeliness and the needs of the business and to overcome the natural resistance to shipping. The easiest thing to do is to not ship, and I have seen organizations crippled by this culture. I suspect that this is why I have such a strong affinity for Agile development, as I see it as the best process around for creating and sustaining a “shipping” culture. It measures and encourages all of the behaviors needed to focus your team on what is important to your customers and to the business and to establish rhythm and a sense of urgency around getting the job done.

“As the universe is relative and interdependent, the determination of which thing is yin or yang depends on what is its complementary opposite – that is, the frame of reference. This yin-and-yang relativity concept forms the core in understanding of many Chinese philosophic classics as embodied in the Tao Te Ching.” – From <http://en.wikipedia.org/wiki/Yin_and_yang>

Since you have made it this far, it’s time to tell you how the story ends and then you can decide if you want to go any further in trying to understand it – are you ready?

Summer Walking Bridge - Coon Rapids, MN

The message and the process the leader chooses are the yin-and-yang of the organization.

 Wow, that’s it? Yep, although there is certainly more to say on the topic.

Back to the struggle about choosing the message – it seems to me that there are really 4 available options, and no good MBA student would be happy without a quadrant as an analytical framework. I’ve named each quadrant for effect:

As you can tell, I’m not a big fan of quadrants 1 and 4; when a leader chooses both process and message to support the same goal, they risk creating an organization that delivers products of poor quality or that never delivers.

The real breakthrough for me is that I thought my only real choices were 1 and 4, based on the simple assumption that your process and your message had to be consistent. This strikes at the heart of integrity – consistency in what you say and do, and everyone wants a leader of integrity, right?

But, since I wasn’t happy with what I viewed as the inevitable outcome of choosing either 1 or 4, I realized that what I had actually been doing for the last few years without knowing why was pursuing quadrant 2. When introduced to the organization I start in quadrant 1. This is necessary because in order to lead process change your Message needs to align with your Process. Without this you can’t get the behavior change you need to embed the process into the organization.

However, once the process has become natural, then what do you do? You swing your Message to Quality and start to institute measures to support your message. The trick is to continue to sustain the process you have in place to drive timeliness and shipping, so your Message can’t be one of radical change or the process will get placed back into question and you’ll have a revolt on your hands.

Quadrant 3 is an interesting long term alternative to consider as well and may be a good choice for some leaders. I suspect that the reason Quadrant 2 has been more successful for me has been the nature of the cultures where I have worked and my own personality. Because Quadrant 2 is my preferred style, I tend to fit better with the needs of a smaller, more entrepreneurial organization. In fact, I now realize that when I worked at a MUCH larger company that already had Quality processes firmly embedded in the culture, I started in Quadrant 1 as usual but migrated more to Quadrant 3 to balance the macro-culture at work. I also discovered that I was not happy when my natural inclination was counter to what the organization needed and I decided to leave.

There is still a loose thread that needs to be tied – how do I deal with the question of integrity caused by inconsistency in Message and Process? I guess I’ll give you a non-answer by giving you a quote from F. Scott Fitzgerald to consider instead: “The test of a first-class mind is the ability to hold two opposing views…at the same time and still retain the ability to function.” Most people working with you will hold you more responsible for your Message than your Process, so it is difficult to wage a personal attack on someone’s integrity when their Message is Quality.

One last note – you may have noticed that I haven’t had anything good to say about Quadrant 4. In fact, I’m not sure there really is a situation where this is a useful combination for a leader. Unfortunately, I have seen examples of others starting there and getting stuck there, especially in smaller organizations where speed is often of the essence. In these situations, I think they become certain that only quality oriented processes (RUP, for example) will master the chaos so they implement an overly burdensome process and then stick to their message of Quality even as the organization reels from the impact that the process change has on apparent productivity. I think most engineers think they want to work in Quadrant 4 environments, so when they get the chance to lead that is what they try to create. I don’t think they appreciate how few environments and business situations can actually sustain that behavior, especially in the software world.