Thoughts on “Managing” Software Development

I’ve written in the past on management and managers and you can find some of those thoughts here however I want to share some additional thoughts.  These thoughts are basically my answer to the question of: what does a Software Delivery/Development/Engineering manager do?

(Even if you’re one of those who believe managers are not needed in knowledge work, I’ll crave your indulgence to read on).

(I do believe that Software Development/Engineering Manager are better role names than Software Delivery Manager but I digress).

It is dangerous to define the job duties of a role without taking into consideration the guiding philosophies of an organization.  For example, let’s just look at the concept of the manager. The definition of management (and hence managers) in an organization that adopts the principles of Frederick Taylor will be markedly different from that of an organization that adopts the principles of Edward Deming.  In other words, roles are not defined in the abstract.  The organizational philosophy ultimately defines the role.

I belong to the school of Deming when it comes to management, and as a result, my definition and description of a software delivery manager is going to be based on Deming’s view on management and managers.  I posit that real Agile and/or Lean organizations take a similar stance.

A software delivery manager is a “manager of software delivery” and if we decompose the role into its component parts we have manager and software delivery.

Douglas McGregor basically describes the Taylorist manager as person who works with the assumption that:

…workers have an inherent dislike of work and hence needs to be directed, controlled and threatened with punishment in order get them to work hard to achieve company objectives  

The Taylorist manager is all about control and external direction ergo this manager focuses on defining how the work should be done by the individuals on the team and then measuring individuals to ensure they are meeting pre-determined targets the manager defined.  This manager leaves little room for individuals and teams to self-direct as these managers need to do all the planning and provide all direction.

So how does Deming describe as the role of the manager?  According to Deming (excuse the gender-specific tone), a manager:

  1. Understands how the work of the group fits with the aims of the company. He teaches his people to understand how the work of the group supports these aims.
  2. Works with preceding stages and following stages
  3. Tries to create joy in work for everybody
  4. Is a coach and counsel, not a judge
  5. Uses figures to help understand his people
  6. Works to improve the system that he and his people work in
  7. Creates trusts
  8. Does not expect perfection
  9. Listens and learns
  10. Enables workers to do their jobs

Deming is not alone in his thinking.  Other management thought leaders such as McGregor, Drucker, Ackoff, and Senge all share the same thoughts.

If I were to summarize, I would say that the role of the Agile (and some would say modern) manager is to:

Create an environment where people and teams can do their best work for themselves and the organization in a manner that is both rewarding and fulfilling

The modern manager realizes that s/he is dependent on their team to be successful.  The team is also dependent on the manager.  In a nutshell, the team and the manager are interdependent.  The manager and the team share in the responsibility of developing and delivering software.

(If you work for an organization that says they are Agile and but exhibit Tayloristic management tactics, I hope for your sake that the organization is in the early stages of Agile cultural adaption.  If they aren’t, you’ve been warned).

So we’ve defined manager but how about software delivery? Software delivery is simply the aim of the system that the manager and their team(s) belong to. This system has the goal of delivering software that addresses the needs of stakeholders.

What then are the duties of the software delivery manager?  Here are a few that immediately come to mind:

  • Provide clarity to team members and teams on organizational objectives and what achieving them entails
  • Define operating constraints and boundaries for teams in which they operate
  • Provide teams with the appropriate authority, resources, information and accountability
  • Provide career guidance and coaching to individual team members and teams
  • Staff teams appropriately within budgetary constraints.  Manage their budget responsibility
  • Partner and network with other managers in the organization in addressing organizational impediments
  • Provide feedback to the teams on the software that is being developed.  Engage in product “inspect and adapt” sessions.

What else would you add to this list?

While we’re talking about software delivery teams, I need to remind us that in Lean and Agile organizations, the work is done by cross-functional teams.  The implication of this is that software delivery teams will often be composed of individuals from more than one functional group in the organization.  A software engineering delivery manager will often need to team up with managers from other functional groups in the organization e.g. infrastructure manager and together they will provide the team the support it needs.

It’s also important to remember that Agile teams (regardless of the framework of choice), as a part of being cross-functional, have a role on the team responsible for championing the product (or something similar to a product).  This role, often referred to as the Product Owner, and not the software delivery manager, decides what the team should focus on.

So there you have it.  These are my thoughts on the Software Delivery/Development/Engineer Manager.  I anticipate that some readers will disagree with me.  Please share your thoughts in the comments.  But as you disagree with me, take a moment to explore why it is that you disagree with me.  In fact, I would implore that you examine the underlying philosophy and mental models that inform your definition. Where do they come from?  Do you know?  Are they based upon Taylor’s Principles of Scientific Management, Deming’s principles or something else?  

Our actions reveal our beliefs.


Sharing In The Risk….

Over the last 48 hours, I’ve been engaged in some #NoEstimates conversations.   A tweet this yesterday evening re- introduced a very interesting dimension to the conversation (at least in my opinion).

What risks are we possibly concerned about here?  I can think of two related to the actual process of software development and one related to the people actually doing it, so in all 3 major risks (even though I wouldn’t be surprised if there are others):

  1. Risk of team not developing the right thing
  2. Risk of team not delivering on time
  3. Risk of team not doing their best

Getting It Right/Being On Time (Value 3, Principles 1 and 4 at least)

It is my experience that software development is largely non-deterministic and empirical.  YMMV.  (If this is not your experience, I’d love to hear about it and the software you develop). There is a significant amount of learning that occurs as the work is being done.  Just pull any developer off any team and ask if they “figure things out as they do the work?”.  I’ve been developing software long enough to remember a number of approaches to software development that tried to front-load learning via the use of documents and models of other forms.  We still found ourselves learning a lot as we actually typed lines of code.  We can debate ad nauseam as to whether our discovery process was broken and I imagine there are those who simply say that we should just get better at identifying and writing requirements. There may be some truth to that, but I’m positive it’s not the only way.

Agile as an approach to software development desires to exploit the uncertainty and learning that is inherent in software development. This post is not an Agile primer and yet a meaningful study of Agile methods/frameworks shows that the first two risks are actively being addressed all the time as the team works together to deliver working software.  Remember the team includes the paying customer.  They are part and parcel of managing the first two risks as we go along.  They are part of actually providing a solution.  If the customer is not heavily involved in the development of the solution, and yet wants a guarantee around the first two risks, then you may need another approach that lends itself to such an engagement – I’m not sure Agile is it?

So this puts us in the land of contracts.  By contracts I am referring to any agreement (verbal or written) on what is going to be delivered and when it is going to be delivered – think funding models as well.  When a team commits to delivering X scope in a period of Y, a contract has just been put in place.  The nature of the contracts ultimately impacts the behavior of your teams, which impacts how software is truly developed.  But we know contracts don’t guarantee results (think about all the prenup’s that have gone by the way side), they guarantee (maybe) a course of action when things go wrong. They can be an indicator of low trust.

This is an opportunity to go read up on what Agile contracts look like (there is no shortage of resources on this topic).  But the essence of many of them is that the buyer makes small bets while remaining part of the team.  Do they often bear a larger percentage of the risk? Possibly. They often reap a larger share of the reward as well.  What they don’t do is handoff a problem and say “see me when you’re done”.

If you thought that software development happens in a bubble, you were mistaken.  There are multiple organizational conditions that influence it directly and indirectly.  It’s not just something that those technology guys and gals are doing.  Agile software development is disruptive to the “normal” way of working. It requires the investor to be part of the team in some form or fashion.

Having a Committed Team (Principle #5)

Ok, so maybe I can leverage Agile contracts for work that is outsourced but what do we do when the team is part of our organization and is salaried?  We could be paying them and not getting results.  Well, this leads us to risk 3, the risk of the team not doing their best or to put it more bluntly, not being committed.  While we can definitely focus on getting the team to comply with internal contracts and similar instruments (such as threats), things are not often what they seem to be.  Metrics and efficiency numbers that show a team is “working hard”, “improving” or “getting faster” are not a true indicator of a teams commitment.  Maybe they are an indicator of compliance, maybe.  (If compliance is good enough for your organization – Agile is probably not a right fit). Leaders who are looking for what they deem to be “tangible” stuff should really be focused on how much value is being created and generated.

Here is a formula for committed teams: Hire great people, create cross-functional teams, give them meaningful work, share with them how their output as a team will make a difference, tell them about important dates and budget and then let them loose.  Support them by providing enabling conditions that allow them to excel.  Follow’s Drucker’s advice; see them more as volunteers than anything else.  This requires you to discard your Theory X approach to management.  It requires you to actually trust them – if they are committed they’ll share in the risk as well.

Manifestos and Things

Take a look at the Agile Manifesto (I’m sure you can find it).  If you look at it carefully you’ll see that this post has gone over some of the Agile values and principles.  This, to me, is what software development guided by the Agile Manifesto is all about. It’s not just about standups, backlogs and story points.  In fact, I consider those important but lesser.  It’s about a particular culture of developing software.  Any method that consistently demotivates or disempowers is not Agile. This is at the center of the #NoEstimates dialogue in my estimation (excuse the pun) – the culture of software development and hence the engagement models that arise as a result of the culture.  (Sidebar: I find myself continually saddened by Agile leaders in organizations and consultants who don’t get this and still claim to be leading Agile transformations.  They are doing more harm than good). Agile is not mandatory, it’s choice.


In Agile software development, the risk is shared and mitigated by everyone involved (including the investors) by working together in an Agile manner with a committed team.  This may or may not work for you – it does not however mean that it is not an option (or the only option).

Ownership over Accountability

(I really should be at the piano but I find that there are few things on my mind this morning).

I find myself engaged in my fair share of conversations around accountability in various settings – particularly the Western world’s spin on it.  That is, who can we hold accountable when something goes wrong?  As I’ve blogged in the past, I personally think that individual accountability for team outcomes is a bit misguided.  Debating “who gets called in the middle of the night” is truly missing the point.   If you structure your organization in a manner such that individuals are solely accountable for team outcomes then don’t be suprised by the behavior that follows.

(As a leader, you are first and foremost a system designers and influencer.  Don’t forget that.).

However, I do wonder what would happen if leaders spent half the time they spend debating who is accountable, actually promoting individual and team ownership in their organizations.  Do individuals and teams feel ownership over their work, processes, techniques and outcomes?  Or do they feel like their stuck simply following instructions? A means to an end? It’s not enough to simply talk about it, we need to intentionally create the conditions that actually support ownership at all levels.

Does your organization have a culture of ownership?  What would a random survey show if you asked that question within your organization? How much time is spent discussing what needs to be done so that individuals and teams actually take more ownership?  Nothing is a panacea and yet low ownership levels leaves a lot on the table.

Let’s focus more on a culture of ownership, maybe it’ll address our accountability problem.

(Now off to the piano…)

Decentralize City

Is your organization highly centralized or highly decentralized?

Lean organizations are characterized by pushing decision-making to the “lowest” possible level. In the using the word “lowest”, I am just reflecting the hierarchy that exists in most organizations. What we’re really talking about here is ensuring that decision-making occurs where the work is actually happening. In order to enable this, the information also needs to be shared with the team(s) actually doing the work.

This is at odds with traditional work structures where people at the top were paid handsomely to have all the information and the peons were given such dumbed down tasks, that they didn’t have to do much thinking.  Take a few minutes to study the history of industrialization.  You may be surprised at what you uncover.  Unfortunately, this “thinking” still influences the control structures of the average organization.

Even though in knowledge work, the “associate” is often a highly trained and educated individual (see Drucker), most organizations still create structures where all the important information is held at the top.  You know, with Director X, VP Y or C-level exec Z. Nothing meaningful gets done without a decision being made by someone with a big title.  Supposedly, those at the top are more informed and have more experience. Supposedly.  The Taylorist mindset lives on; cloak and dagger style.

You can choose whether you want to work in organization like these.  I made up my mind a few years ago that I wouldn’t except I was helping to the change that situation.  You know why?  I can’t stand to see so much human potential wasted.

Additionally, the delays introduced as a result of waiting for people at the top to make decisions impacts us economically (well except we’re a monopoly).  Innovation is stifled, creativity pretty much killed.  But someone still ends up with a fat bonus.

As a leader, how much decision making is centralized in you? How much decision-making is decentralized on your team? How much information is given to individuals and teams that enables them to actually make decisions?  How many centralized boards and bodies does your organization have?

The greater the centralization the lesser the ability for the organization to scale and the more human potential is being wasted. The waste of human potential is such a sorry thing.


A Little Learning Is A Dang’rous Thing

Last night I tweeted:

One of the most intelligent guys I know (and just reconnected with) Abiodun Ofuya, responded with:

Leave it to Abiodun to pull in both Greek mythology and Alexander Pope.  He’s been doing this since we were in high school 20+ years ago.  The message came through loud and clear.  From Alexander’s Pope’s poem “An Essay On Criticism”:

A little learning is a dang’rous thing

Drink deep, or taste not the Pierian spring

Little learning is often worse than ignorance as little learning gives a false sense of understanding and prevents additional learning whereas ignorance is simply that, ignorance. Little learning is one of the more common conditions present in many organizations that they are unaware of.  Little learning leads to the improper implementation of methods, practices and measures.  The moment we believe that “we’ve got it” or have become “an expert”, we may be dangerously close to “little learning”. Regardless of where this “little learning” lies within the organization, it is often leads to the creation of bad system.  As Dr. Deming said:

A bad system will defeat a good person every time

So what’s the antidote:

Drink deep

Make a personal commitment to continual learning.  Allow your existing mental models to be challenged.  Consult those who are further along the learning path.  As the child of two academics, I believe (based on my personal experience) that learning never ends and I’m always amazed by the new stuff I learn even in areas where I’ve been highly engaged and involved with for a long time. Remember that:

…drinking largely sobers us again

Keep learning.

* See Pierian Spring for more information.


Accountability, Say What?

Accountability is defined in the dictionary as:

The quality or state of being accountable; especially : an obligation or willingness to accept responsibility or to account for one’s actions

Responsibility is often used as a synonym for accountability however frameworks such as RACI distinguish between the two words stating that those who do the work are “responsible” and the individual who is ultimately answerable is “accountable” as only one person can be accountable because accountability cannot be shared. I suppose this may work in non-team environments or co-acting groups but I struggle to see how it can really work in organizations that are committed to self-directed work teams.

For example, let’s take a a football (soccer) team, and apply the RACI matrix to it. Based on the RACI definitions, the players (workers) on the team are not accountable (answerable) for their play or the teams outcomes, only the coach or manager is.  Or how about a choir? Should the members of the choir not be accountable for their performance or is the choir director the only one accountable?  I wouldn’t want to be a part of a team where my teammates did not feel we were collectively accountable for our results.

George Santanya famously said:

Those who do not remember the past are condemned to repeat it.

It’s important that we don’t forget that matrices such as RACI are products of project management which is a by-product of scientific management. If you are a manager and/or leader in an organization, hopefully you are aware of scientific management and Taylorism. My experience (unfortunately) however, is that many managers and leaders are not familiar with management theories.  Read the label before use, please.

Self-directed teams are accountable for delivering a work product that pleases those who will use or benefit from their work product. Accountability for delivering the work product should be that of the team and not that of a single individual whether that individual is the lead developer, architect, product owner, project manager or simply the smartest guy or gal in the room. Team members are individually accountable for meaningfully contributing to the overall success of the team.  If you intend to make one individual accountable for the work product, then you must also give them full control and strip the rest of the team of their accountability.  As Stephen Covey said:

You can’t hold people accountable for results if you manage their methods.

Is this something your really want to do?

While we’re talking about accountability, I should point out team accountability is not an idea original to Agile. A review of the work and study done on team-based work structures make it very clear that one of the conditions needed for self-directed teams to be successful is team accountability.

Some of my colleagues in Agile-sphere have an aversion to the word accountability because it often translates to a “who do we blame when things go wrong” culture.  I happened to work in an organization with a business unit that had a strong culture of blame.  I can recall an experience where a VP wanted me to let him know who on my team would be working on a certain piece of functionality so that he would know who to go to when things went wrong. He wanted to know who was accountable.  Unfortunately for him, I wasn’t in the mood to provide that type of information so I ultimately became accountable.  I don’t believe that accountability needs to translate to a culture of blame if individuals and teams take both responsibility and accountability.  Unfortunately, many organizations are challenged in this area.

If you’re truly making the commitment to self-directed work teams, make the commitment to team accountability as well.  More to come on this….

PS: I started this post in October of last year (2014) but never really got to completing it.

1. Leading Self-Directed Work Teams by Kimball Fisher
2. Leading Teams: Setting the Stage for Great Performances by J. Richard Hackman

Who Are You?

It’s been a minute since I’ve blogged as a lot has happened in life recently, the biggest being the passing and laying to rest of the matriach of our family, my grandmother. Hannah Joji Ikonne.  She was the best grandmother ever and her passing away is one of the sources of inspiration for this post.

Who are you?  When I ask myself that question I realize that I am the sum total of the experiences and circumstances (and more) that have occurred during my lifetime.  Let me quickly share a few:

  • I grew up in a home of faith
  • I grew up in a third world country
  • I did farm work, cutting foliage with a cutlass, planting corn, cassava etc etc
  • I walked 3 miles to my high school and 3 miles back home every day for 4 years in the scorching sun
  • I lived on a university campus where academic rigor was the order of the day
  • Etc etc…

How have these factors impacted me as an individual?

  • I am person of faith
  • I have empathy for the less fortunate and I’m content with whatever I have as I realize there are people who have much less
  • I am not afraid of hard work and get irritated often when people complain about certain aspects of our white collar jobs
  • I appreciate having a car 🙂
  • I have little respect for those who haven’t done their research on a subject and yet have such a loud opinion on the subject

These are how the factors impacted me, not anyone else.  A lot of the folks I grew up with experienced similar conditions and were impacted in a different way. (You know who you are).

But the point of this post is not to make my life experiences material for the public domain but rather to remind us of something we already knew, we are complex creatures.  I feel that this is extremely important to remember as we interact with one another, especially in the workplace.

Don’t be quick to judge or jump to conclusions.  Remember that the individual on the other side of the table is also a product of their life experiences just like you are.  Have empathy.  Be tolerant. Be vulnerable.

Now I know for a fact that this is easier said than done (I personally struggle with being vulnerable for example) but we need to keep trying if we want to experience deep and meaningful relationships. Paraphrasing St. Francis:

Seek to understand then be understood

Rest in peace Mama Ukwu.



Cause and Effect – Is It Really That Simple?

So this post has been on my mind for a while, but something happened at work today….

It would seem to me that it’s human nature to explain occurrences in the simplest manner possible, often in the form of linear “cause and effect” relationships.  You know, after you kick a ball, you realize the that the kick (cause) led the ball to move (effect) and so we are always looking for that “kick” that led something to happen.  For example, why did we find fewer defects this sprint?  Well, it’s because we went from a 3 week sprint to a 2 week sprint.

Is it really that simple?  I don’t think so.  I’m reminded of the phrase “correlation does not imply causation“.  In the domain of systems thinking (and every one responsible for the system should have a basic understanding of systems thinking), we realize that there are often many variables at play in the system.

Take the “fewer defects” example I mentioned earlier.  While it is true that the sprint duration was shortened, is it possible that other conditions changed as well?  Was the team now a bit more familiar with the work?  Was their less pressure because they committed to less in that particular sprint? Was this work less complex than the work before? Was technical expertise that had been missing before made available?  What about the conditions we are not aware of? I mean, we can’t be aware of everything can we?

The additional challenge we have is that we rarely have the luxury of repeating our experiments.  Every time we try something new, the conditions are different.  How many times do we get the opportunity to develop the same feature repeatedly just to capture how effective a change is?  I assume rarely, if ever.  Our laboratories don’t allow us to reset and run the exact same experiments over and over.

So where does this leave us? (Especially those of us who consider ourselves to be expert problem solvers!).  Does this imply that we cannot attribute cause to the things that happen around us?  I think we need to be a bit more respectful of the complexity of the problems we often face.  We need to understand that the underlying structures and conditions continually impact one another.  To use systems thinking parlance, structures reinforce and balance one another. There are often many factors at play and we should be careful latching onto a single one as THE (only) cause.  This complicates things for us in some regards, but put us in a position where we can actually dissolve problems.

It is rarely as simple as we often make it out to be.

PS.  Some links to my posts on systems thinking.

Have You Seen The System Lately

Appearances Can Be Deceiving

Build What Product Management Tells You To Build. Really?

A current (ok now its old) conversation on LinkedIn was the source for the first post of 2015.  (Yes I’ve been slacking a bit).

While on vacation, I spent some thinking about the fact that many organizations have “Product” groups that are separate (read completely different organizational structure) from the “Technology” group.  In fact, the only organizations where I have not seen this are the technology startups that I have been involved with.

I happened to bring up this point in the LinkedIn conversation only to be told the following:

Software Engineering – Build what product management tells you to build. Worry about predictability, quality, productivity and extensibility

Product Management – What should be build? What is the business case for it?

Really?  Is that really what Software Engineering is about?  Building what product management tells you to build? Could it be true?  We shouldn’t care about what we’re actually delivering?  I believe that such an opinion leaves a lot on the table and yet I’ve found it to be a common opinion in more than one organization.  Ever heard this: “don’t ask why, just do it”!  Unfortunately, statements like this reveal a complete lack in understanding of software engineering.

I won’t get into a discourse on software engineering as there are many institutions of repute (and Google) that can you help you out with that but I do want to point out an important aspect of software engineering that trained software engineers are very familiar with – requirements engineering.  Requirements engineering is all about determining what problem needs to be (dis)solved and what outcome is desired.  I realize that “requirements” is often a red word in Agile circles because of its literal application in many command and control type organizations.  I mean, who hasn’t heard the “go read the requirements” reply before?   But when you really think about it, you’ll see that Agile methods promote performing requirements engineering throughout the entire product development process.

So its my belief that software engineers need to understand “what should be built” and “the business case for it”. In fact, I’d suggest that it’s irresponsible not understanding why.  Sure, there may be another group (for example product) focused on idea generation and problem identification but instead of walls between product and development, let’s have a mesh with ideas and information flowing both ways.  It is product development afterall, isn’t it?  Software engineers ultimately need to understand the problem to be able to deliver the best solution (they are capable of delivering).

As I pointed out here:

To get the “best” solution, it seems to work best IME when those delivering the solution understand “why” and the outcome desired. I have been told many times in the past to do X because it was needed but if I had understood “why” and the outcome, would have done X+ or maybe Y. A key component of software engineering is requirements engineering. Requirements engineering asks us to understand the problem.

So friends, don’t let friends tell you that software engineering is just about building what we are told to build.  It’s more than that!


Even The Best Plans Fail

Plans fail, and they tend to fail quite often.  In all walks of life, even the simplest plans tend not to unfold as originally designed.

Organizations spend a lot of money and time creating groups solely focused on ensuring that plans do not fail. Senior leaders hire individuals and give them the sole responsibility of managing plans to success.  It is quite the lucrative profession to be given such responsibility.

Recently, I asked our church pianist to perform special music at church.  Early in the service, a group of children came up to perform special music.  As they were singing, I walked over to the pianist to discuss a couple of things but before I could say anything he whispered in my ear “the kids are singing my song!”  I couldn’t believe it!  What were the odds that the children and pianist would choose to sing the same song on the same day? Pretty small.  But it had just happened.

So our best plans fail to go exactly as we thought they would when we drew them up.  It is rare that we are 100% certain that things will work out exactly the way we expect them to yet we often behave as if that’s the case. There is always the chance that something unforeseen will swoop in, alter the landscape and impact our plans.

How then do we proceed?  Do we stand a chance of getting anything done?  Do we have to spend all our effort trying to ensure that our plan unfolds as we originally designed it?

Back to my story… I was beginning to feel very concerned for our church pianist as I didn’t know what he would do given that the children were singing the song he had prepared.  At that moment he leaned forward and whispered “don’t worry I prepared two songs, I’ll sing the other one.”,  He had prepared two songs!  He had options!   His options allowed him to adjust when his original plan did not work out as he thought it would have.

When you develop plans, do you identify options for when things go wrong?  Do you explicitly consider the fact that even the best plans fail?  Some may consider options to be “contigencies”, “alternatives” or “backups”.   As I type this post, I’m at Owo-Ahiafor, Nigeria – my hometown.  When I planned the trip to Nigeria, I identified options for various pieces of the plan where things could go wrong.  Having options is part of developing a risk mitigation technique.  It’s common sense but then again common sense is often not that common.  Options should be identified based on the likelihood of the plan not working out as originally designed or based and/or on the impact (financial, social, physical) of the plan not working out.  In the case of my church pianist, the odds that the two songs he prepared would be sung on the same day, were pretty slim because it was a regular church service.  However, if it had been a concert, he may have needed three or four song options to reduce the odds even further.

At the organizational level, I’ve observed that many an organization will spend a lot of time creating plans and yet don’t spend the time to consider the fact that even the best plans fail, ergo, they have no options or scramble to find options when things don’t go according to the plan.  As a result of this, certain people in the organization are incentivized to make sure the plan works at all and any cost.  Often, they are not the individuals actually executing the plan leading to unnecessary friction within the organization.  I’ve lost track of how many times I’ve seen people recognized because they “rescued the plan”.  In previous posts, I’ve hinted that outcomes are what we truly care about.  The plan is often a means to an end.

Do you have two songs in case someone else sings the song you originally intended to sing.  Do you have options for when things don’t work out as planned?  As we head into 2015, remember, even the best plans fail.