Montague.tv

(The title is a bit awkward but I loved the alliteration!)

Tell me if this sounds familiar…

…“We want to build trust. We want to have a seat at the table. What can we do to WOW our customers and build trust in our expertise and capabilities?”

It’s familiar to me. In every organization in which I’ve lead IT transformations, this thought makes its way to the fore, early and often. And for good reason. It’s critical to be engaged if you want a true partnership. One bit of often overlooked advice for those wanting to earn their way to “the table”:

Over deliver when it comes to supporting, protecting, and stewarding your production applications and environments.

Our customers rely heavily on the systems we build for them. In some cases thousands of people rely on these systems to do their jobs…all day long. Other systems we build help our customers get paid and plan for their future. If you put yourself in the shoes of these customers, the most important thing we can get right is supporting *current products*. I don’t want to undervalue new product development, but those products typically don’t already have hundreds or thousands of people relying on them (yet). It’s the legacy stuff…the stuff no one wants to talk about or touch, that tends to catch us flat-footed. We are judged every day, by each and every one of those “ticking time bombs” that “were developed by someone else”. Those tools that we haven’t touched in 6 years are the ones that can kill us, erode trust, increase our risk, and get us forcibly removed from “the table”.

Implicit Contracts

Many companies don’t have explicit service contracts for their internal products, especially the legacy one’s built by “someone else”, but you better believe there’s an implicit one in place. Every time you roll something into production, you are telling your customers,

“Here is a product of our end-to-end IT capability (project management, business analysis, QA, development, deployment, network and infrastructure). This is what you can expect from our teams.”

Customers pick up these products and USE them. Many times they build their worlds around them. Some by choice, some by force. We’ve handed them a tool with a smile and a handshake and said,

“Here. Use this.”

What do you think their expectations are in this interaction?

The distance in time and space between today’s staff and “old” products and commitments makes this problem tough to stomach. But it shouldn’t make it hard to understand. Customers don’t care when we use the term “legacy code”, “classic ASP”, “VB6”, or “spaghetti code”….. THEY – DON’T – CARE. They are in pain because of a product IT built. We are IT. By the transitive property, WE are causing them pain. This is implicit, but that doesn’t mean it’s imaginary. It means it exists whether we say it or have agreed to it or not.

Ok, after we breathe deep and swallow hard, how do we go about fixing this issue? One way is to live by and teach some very specific values.

The Boyscout Rule

“Leave things better than you found them.”

As simple as it sounds, when everyone on your teams (not just developers) live by the boyscout rule, systems will improve dramatically. In an awesome twist of fate, this is especially true in organizations that have lots of issues. Why? Because there are dozens of opportunities every day to make systems better. Every help desk call, nightly failure, small scale enhancement, and upgrade is an opportunity to clean and polish a tiny section of the system, its documentation, and its “broken-ness”. You’re already putting effort into these systems. Teach your staff how to focus their effort on cleaning up as they go.

(please refer to my favorite scene in “Ratatouille” where Colette (the rôtisseur) is teaching Linguine (the main character) how to be a chef. “Look at this mess! Your sleeves look like you threw up on them! Keep your station clean, or I’ll kill you!”)

Your Professional Signature

Make everything visible. All the hard work, blood, sweat and tears to hold the line on quality should be visible to everyone in the organization. Every time you touch a system, tell people what you did to make it better. Look at every system interaction as a chance to show the team that you have their best interest in mind and you refuse to deliver a Rube Goldberg into production. I’m telling you this is not only a punch in the stomach of our customers, it’s also a kick to the shins of your peers. The person who made the mess RARELY is the one who deals with the second and third order problems it causes. Refuse to make that “normal”. Your professional signature should go on EVERYTHING you touch. What better way can you show respect than that.

Shared Accountability

Related to your professional signature, HELP your teammates deliver. Hold one another accountable. Discuss. Debate. Raise concerns. One thing I’ve recognized through the years is that one person will never solve this problem. Go to your peers with an attitude of compassion, understanding, and help. Don’t refuse their work. Show them what you expect and help them get there.

Safari!

In the spirit of Lean and Kanban, ask your teams involved in IT to visualize their value stream and hold daily stand-ups. This gives the rest of the organization the ability (and opportunity) to do safaris to the other teams stand-ups. We’ve found these incredibly useful as we now can hear and see our partners pain points (with us and others) and can take proactive steps to resolve any quality issues we might witness. For example, take the opportunity to listen to the support teams talk about your product portfolio. If you hear them bash certain products, repeat the names of the same systems over and over, or roll their eyes, you have a culprit to deal with.

Conclusion

If you want to WOW your customers, give them incredible service on the things they have already come to rely on. If you can’t get that right, STOP BUILDING NEW PRODUCTS until you get it right. For the same reasons, you won’t win friends (trust, respect, legitimacy) rolling out products that no one can support either. There are definitely times when building new tools and products gives our customers a stunning advantage in the market, clear efficiency in daily work, and the ability to evolve their business. I don’t think anyone would argue that. What I hear regularly is minimization for the need to support and maintain our systems (time, effort, pain, importance, focus), and to build them well – right out of the gate.

Interestingly (and poetically) the more time, effort, focus, and pride you and your teams put into supporting and maintaining systems, the LESS time you’ll actually spend doing it. Not only that, your partners will build you a permanent seat at “the table” when you get it right.

First of all, I’m SO sorry for the terrible Top Gun reference in the title.  The best title was already used and this one is less than awesome.  OK, now on to it.

Recently Jim Benson (author of Personal Kanban) asked that I provide him some feedback on a piece he is writing called “Reading is (Still) Fundamental” (said title from above).  He wanted to know my thoughts on reading, and encouraging reading in the workplace.  I thought it was an interesting topic so decided to share my response.

My Response:

A staff that is willing and equipped to read is a staff that understands the need for continuous improvement.  In that regard, reading, reflecting, and learning is crucial.  To understand why, let’s simply look at one of the most common reasons given (to me) for why some don’t read.

“I learn enough through experience!  Everything I know I’ve learned through the school of hard knocks.  What could a book *possibly* tell me that I can’t get from experience?”

While it’s true that experience is likely the most powerful means of learning, the sad truth is that we don’t have as much experience as we think we do.  As I’ve learned (in books no less) most of us rarely have “20 years of experience”.  We typically have one year of experience FOR 20 CONSECUTIVE YEARS.  That’s right.  If we reflect on our past, occasionally we have brand new experiences that indeed teach us quite a lot.  But for the bulk of our past, we tend to repeat what we know over, and over (and over) again.  In that way, I would argue we need to step outside the boundary of experience-based learning and learn from others collective experiences.  You do that in books, articles, websites, blogs, and yes, tweets.

As you might guess, it’s important that your teams are “willing” to read.  Just as important, they need to be “equipped” to read.

As employers, we can help control the second of these two statements.  Our obligation while building learning organizations is to model behavior, challenge assumptions, infuse an attitude of curiosity, and generally create conditions that allow (and encourage) people to read and reflect.  After all, as adults, quiet reflection is critical to our growth.  We are therefore obligated to not only “allow” people to read at work, but to encourage and incent them to read at work as well.  In that way, each employee becomes a wellspring of “new” ideas, and a potential catalyst for infusing those ideas in our organizations.

In Homer’s epic “The Odyssey”, Odysseus, King of Ithaca spends 10 years traveling home from the Trojan War.  On his journey through the lower world, Odysseus was warned by Circe, daughter of the Sun, to be wary of the Sirens on his journey home.  The fate of sailors hearing the beautiful Siren Song was to be lulled into lethargy, and subsequently smashed against the rocks of the Sirens island.  “Their song, though irresistibly sweet, was no less sad than sweet, and lapped both body and soul in a fatal lethargy”.

Odysseus, a brilliant leader, had the foresight to heed Circe’s warning and filled his crews ears with beeswax.  He then instructed his men to tie him to the mast of the ship and under no circumstances release him, no matter how much he pleaded.  When he heard the Siren Song, Odysseus implored his men to release him, but they bound him tighter.  When they had passed out of earshot, Odysseus demonstrated with his frowns to be released.

So what can we learn in the world of technology from Homer’s eponymous hero?

The seductive Siren Song we hear, in today’s parlance, is the relentless call for “faster, short-term, tactical” solutions to problems.  Our business partners and customers enchant us with the beauty and promise of feature after lovely feature.  We are lulled into a belief that the opportunity to deliver today will *always* outweigh the problems we might encounter later.

Not unlike Odysseus’s crew, we need leaders.  We need a leader that will tell us to stay the course and shield us from the merciless call for the quick win.  We need the type of leader that has the foresight to save us from the rocky shores.  We need leaders with enough fortitude to plan for the perilous attraction of the Sirens Song.  Someone who won’t allow us to hear it, and will make plans to keep us from the short sighted problems it will cause.  Yes, we need them in IT, but we mainly need them to come from the business.  The sad fact is that this is *their* ship….they are the captains and stand to lose the most.  We need to find them and ask them to take responsibility.

It isn’t enough to pretend that most technologists, especially in corporate IT, have the ability to resist this call on their own.  In almost every way, IT practitioners act as a crew on a sailing ship, dutifully delivering value and doing everything in their power to serve the needs of the captain leading them.  It’s romantic to think that one of these folks will rise up and steer the ship away from the rocks.   This is sadly the exception, not the rule.

We need an Odysseus, a leader in the business, to face the Sirens.  Our duty as steward and custodian is to find them.

I’ve been reading a very interesting book written by John Bogle of Vanguard fame called “Enough”.  It’s a wonderful read and highlights some very fundamental values he espouses and has lived throughout his life.  You can get a feel for the book simply by looking at chapter titles.  Here are chapters 1-3:

• Too Much Cost, Not Enough Value
• Too Much Speculation, Not Enough Investment
• Too Much Complexity, Not Enough Simplicity

One chapter in particular, “Too Much Business Conduct, Not Enough Professional Conduct”, struck a cord with me in a number of ways.  It reminded me of Bob Martin’s Craftsmanship and Ethics outlook and books espousing a professional code of conduct.

In Mr. Bogle’s book, he discusses an article that describes 6 core principles of a profession, a professional, and professionalism.

6 core principles of a profession:

1. A commitment to the interest of clients in particular and the welfare of society in general
2. A body of theory or special knowledge
3. A specialized set of professional skills, practices, and performances unique to the profession
4. The developed capacity to render judgments with integrity under conditions of ethical uncertainty
5. An organized approach to learning from experience, both individually and collectively, and thus of growing new knowledge from the context of practice
6. The development of a professional community responsible for the oversight and monitoring of quality in both practice and professional educators.

“The primary feature of any profession is to serve responsibly, selflessly and wisely and to establish an inherently ethical relationship between the professional and the general society”

As I read the list, I tried to think through MY chosen profession and wondered if we consistently have “Too Much Software Development, and Not Enough Professional Development”.  I also wonder how many of the above 6 principles my community exhibits.  Sadly, it seems very few.  What’s interesting about that is how awkward it is to think about true professions behaving like we tend to behave in our daily work.

Some examples of professional absurdity from 2 well known professions (Medicine and Law):

• Think about the lowly hand surgeon.  You go into their office with a little hand pain.  If your hand surgeon tells you that you don’t need surgery, do you force them to do surgery anyway?  On the spot?  Moreover, would a professional hand surgeon actually do it because they notice that you seem upset?
• Now think about a lawyer.  You get caught stealing Ryan Braun jerseys from the local truck stop.  You stop in to see your lawyer and tell him about the case.  Do you tell the lawyer you won’t use him unless he guarantees, unequivocally, that you will be acquitted of all charges?  Would a professional lawyer tell you they know, without question, the outcome of your case?  What if you were wealthy, intelligent, wore a suit to the appointment, and seemed upset?  Would they guarantee it under these circumstances?

Each one of these 6 principles could generate its own post, but I want to focus on the quote above from the book.  I key in on the words “serve responsibly, selflessly, and wisely” and it conjures memories of all the discussions I’ve had, witnessed, or lead that were simply attempts to cajole development staff (myself, peers, direct reports) to leave their professional judgment at the door.  I’ve written a bit about why this happens, and the fact that there are no villains in this equation.  Everyone is operating with the best intentions.

Knowing there’s rarely something subversive going on, I think our community members need to think much harder about their professional conduct as much as the next great framework or development practice.  As a trustee and steward of technology, our obligation to the “greater good” is to stand up and help others make good choices.

“Develop a capacity to render judgments with integrity under conditions of ethical uncertainty”.

While we may not face unethical choices, we clearly face choices of uncertainty.  In this regard, the work Bob Martin is doing is wonderful.  That said, the “6 principles of professional conduct” message tends to get muddled by the 1 or 2 principles espousing the, mainly, technical skills development and practices.

For now, I leave you with one question.  What are you doing to teach and advance the profession of software development, in its entirety, in your organizations?

I decided to write a bit on slack based on my all-to-regular defense of slack in my daily work.

Most employers and managers tend to erroneously equate Activity with Value.

“If we keep people busy, we will get more done” is a common refrain and seemingly fundamental belief.  Leaders tend to put more energy into increasing current capacity than the more powerful approach of understanding throughput.  This all happens for good, although misguided reasons.  Allowing the appearance of “wasted bandwidth” in your system is more than uncomfortable – it feels criminal.  Especially in systems that are struggling and overburdened.

There is so much to do! We need to get every drop of available capacity from our teams we can! NO DOWNTIME!

Paradoxically, these are the times we as leaders should lead and teach our teams that slack is not only appropriate, it’s likely the only way to get out of the mess we’re in.  I know what you’re thinking.  But how could that be?!  We’re behind and you’re telling me to allow, nay force people to be less than 100% allocated!?

….yep.  And here’s why.

Metered OnRamps

If you think about the (overused by me) analogy of a highway, why is it that we don’t crank the system to 100% of its capacity, filling every available slot on the road with a vehicle?  It seems pretty simple in these terms. It’s because our highway would quickly become a parking lot.  However, our expectation is that a completely full highway moving at 65 mph yields the best throughput over time. This sentiment is unequivocally true. No doubt about it.

So why does the highway operate so inefficiently at 100% capacity?   The reason is that each “seemingly independent” vehicle on the road depends on other vehicles on the road to get to where it’s going. If one of these inter-dependent vehicles brakes suddenly, the cars behind it have no option but to do the same. The result is a tsunami of brake lights and the system slows dramatically.  The cars on the road have no ability to absorb even minor changes to the system, and therefore the entire system is affected by minor changes (I assume you’ve heard of “gapers delay”?)  Throughput in a system like this is completely constrained by minor issues and ultimately you get wild fluctuations.  From very high throughput to near zero.

To achieve the absolute highest levels of throughput in a real world system, the trick is to work and experiment your way to the inflection point where:

1. too much slack artificially degrades throughput (meaning we are missing an opportunity to add more vehicles without degradation of the system) and
2. too little slack that ensures any minor (and inevitable) system changes become amplified and choke throughput.

The World of Teams and Portfolios

There’s nothing trivial about building slack into your systems, or daily lives for that matter. What is clear to me is how critical it is.  My advice to you as leaders is to “keep your eye on the baton, not the runners” (Vodde, Larman).  Work to largely ignore “activity” and focus ALL of your time trying to understand the total throughput in your system.  Make small changes to your systems and portfolios and observe the impact.

Slowly filter “work” into your system and observe the point where more work yields less delivery.   When that starts to happen, don’t panic and spin up more projects to fill peoples time.  Relax.  Breathe deep and look around your system for the next challenge.  I promise you’ll find some.

One of the keys to successfully leading teams of people is to run effective meetings.  On the surface, this seems pretty straight-forward.  Ensuring you have an agenda, take good meeting notes, and sending action items out afterword aren’t rocket science.   Relatively trivial, even though consistency is key and rarely is delivered.  However, when you are dealing with those recurring tactical meetings, especially ones that occur multiple times per week, the old model falls down.

To begin with, there really isn’t a simple strategy to produce detailed agendas any longer.   Many topics, the critical ones that need to be discussed ASAP, sometimes come up just hours before the meeting.  Furthermore, the priority of the litany of things that are on the list changes at a rapid pace.  Sending anything in or prepping for those discussions can be fruitless at best, and counter-productive at worst.

Enter the “Weekly Tactical” meeting format:
Some of the concepts in this format were adapted from the book, “Death by Meeting” by Patrick Lencioni, but others were evolved on the spot as the need arose.

The basic premise of the Weekly Tactical meeting is to get a group of leaders together to make decisions.  We don’t want to go to meetings to “talk” about decisions, we want to MAKE them.  (After all, that’s one of our core job functions)  So many organizations are plagued by the notion that meetings are simply to “discuss”, not to “do”.  This simple shift alone will increase the effectiveness of most meetings.  The word Tactical, for our team, implies that the scope of topics should cover 1 week from the date of the meeting.  We have 2 Tactical meetings per week that are 1 hour each.

Detailed Overview:
The following photos show the simplicity of the process.  I have a large whiteboard in my office that is refreshed each time we have this meeting.  It has the template written on it and is ready when the team comes in.  The image at the right shows what the layout looks like.  I tend to facilitate the sessions, but now anyone can do it as the process is simple and well understood.

Next let’s break down each section with details.

Lightning Round:

Decencies
We have recently added a kick-off titled “Decencies”.  This is probably the one I’m most excited about, and most proud of.  After re-reading Tom Peters book, “The Little Big Things” last week, I was reminded of the need to refocus our efforts on our people.  I’m leading a group of manages and architects and we tend to get mired in the day to day.  The complexity and pressure for those leaders is immense and it’s easy to get stuck focusing on “work stuff” and neglecting the “people stuff”.  Tom reminded me a second time “it’s all about the people”.  Hence, the “Decencies” kickoff was born.

Essentially we will create actions to recognize the wonderful and talented staff we have and the things they do every day to make all of us successful.  We will also think about ways to remember the Power of Pleasant, how we can connect emotionally with our customers, and hopefully keep some “damned perspective” when the tension escalates.

Topics
We then go to each person and ask for their topics.  If you have an issue or topic that you need help delivering, or you need a team decision, then it’s a good topic for our meeting.  They each have 1 minute (yes, 1 minute) to get through their entire list, along with associated explanations if needed.  We then move to the next person, in order, until we have a list of topics.  We then get started at the top of the list.

Note: we used to prioritize the list, but as of late, we have blown through very large lists so rapidly that we haven’t needed to prioritize.  If we start leaving important stuff undone, we will go back to prioritizing.

Actions and Decisions:

We then take each topic one at a time and attempt to give each topic its due attention.  We are all aware of the need to get to an Action or Decision so we tend not to lollygag.  We will discuss for a while and someone will say, “Do you need us to help choose for you?” or “Is there a next action for this that we can assign to one of us?”  More often than not, the topic simply needed a quick decision and some collaborators to ensure there wasn’t something being missed.  Other times, the issue is a bit more complex and the initiator needed help deciding on the next steps to take.

As we move through the list, the grid in the image to the right begins to unfold.  We assign tasks with associated details, 1 per line until we’re done.  Normally a “decision” is indicated with a task to communicate the decision so we ensure we are communicating those decisions effectively.

Parking Lot:

As a group, we occaisionally bump into a topic that has no simple solution or the right parties aren’t present to discuss.  They also span many teams and possibly a large time horizon.  These issues we deem “strategic” and get placed in the parking lot with associated detail.  We have a few venues that these strategic topics can end up in so we attempt to classify them on the spot

Note: this classification exercise is new.  I will update you on how its going.

The three Strategic Meetings are a “TRI-Weekly” meeting that we prepare for in advance.  It includes both leadership teams in my organization (Development Managers and Enterprise Architecture) as well as any special guests needed to (once again) make decisions on the topic at hand in the meeting.  The second is a “Development Manager” Strategic meeting and the third is ”Architecture” strategic meeting….all similar formats.  I will try and describe these formats in a subsequent post.

Well, there you have it.  This evolved format has helped our team and organization communicate better, make timely decisions, and get aftet the topics we know are critical for success.  With the addition of our Decencies section, it will also help us double down our efforts to remain focused on whats important, our people and their well-being!

When people encounter issues in their day to day business, there seems to be a human need to find a villain.

This is borne out of the mindset (or mental model) that says we are all independent entities, operating on our own. Decisions are linear, so we need to decompose our world into component parts and perfect each piece. Within this world view, of course there is a villain. Someone did do this to you, and it’s likely the person directly upstream from you. “Someone’s to blame here.  This didn’t happen by itself!”, is a common refrain of the linear thinker.  Sadly, formal education seems to exacerbate this model given the way we are taught to solve problems.

Let’s reflect on this a bit.  One message I’ve heard loud and clear from the likes of Deming, Ackoff, and Senge:

The key to understanding what needs to change isn’t to react to dysfunctions and failures, but to stand back and attempt to get a broader view of the entire system.

When we do this, we learn that a core truth is that we are all inter-dependent, not independent beings. All parts are connected.  The processes are connected. The variables are connected, and each of these things affects outcomes.  It’s core to systems thinking.

The Fifth Discipline
Peter Senge, author of “The Fifth Discipline”, teaches that, as intelligent human beings, we tend to make reasonable (and reasoned) choices. He goes on to say that we rarely fail because we lack the ability to make reasoned choices, but sometimes we fail because of those reasoned choices. The failure is not in decision making, but our inability to “see the whole”.

How could this be?!  If I’m making rational choices, how can I fail?

By way of example, Senge describes (via analogy) controlling the temperature in a shower. When you turn on a shower and the temperature is cold, a well reasoned decision might be to turn the hot tap up a little. If nothing happens, you might turn it up a bit more. If still nothing happens, you might crank it way up, only to find seconds later that the water is scalding hot.

Nothing. Nothing. HOT!!!

This cycle then starts over again in the opposite direction.

Nothing. Nothing. FREEZING!

This is a trivial example to understand because the affect of your actions are relatively close in time and space. At some point we realize we need to turn the temperature dials… and wait. But think about this same concept in the context of your business, relationships, and personal life. Simple decisions that are well reasoned at the time of the decision often affect the system in catastrophic ways way out in the distance. It might take weeks or months to see the affect of decisions. As humans, if an outcome isn’t tied closely to the event, then we think they aren’t linked. When we focus on local, linear outcomes and don’t take into consideration the whole system over time, we make “good choices” that force the overall system to lurch wildly. (Nothing. Nothing. HOT!!!! )

That Sounds Familiar
In corporate IT shops, what tends to happen when business partners feel they aren’t getting their products or features fast enough? In my experience, customers tend to ASK FOR MORE.

They reason, “If I only get half of the things I request, I’ll just ask for more stuff. If I ask for more, I’m bound to get more.”

The fallacy here is that those same business partners don’t see the effect on the entire system. They don’t step back and look at the system. If they did, they might find that their peers are doing the very same thing. They might find that critical projects are being abandoned for more trivial projects from “squeaky wheels”. They might find that ongoing care and feeding of core systems and platforms are being neglected in the hope to “catch up” with project demand.

The net effect? You guessed it…the death spiral. Not only does IT deliver fewer projects “under duress”, the ones we DO deliver are hobbled by poor design and riddled with technical debt. This poor quality creates even more system pressure as developers begin to hide the fact that they are “keeping all the plates spinning” by working to cover up deficiencies in their systems “offline”, effectively hiding their ambient work. Core platform health deteriorates causing rework, errors, and yet more work.

This cycle is vicious, costly, and devastating.

The Dichotomy:  This horror is riddled with  * good decisons *. There are NO VILLAINS here.

The next time a system breaks down, stop and think about how you might begin to see the entire system for what it is, and begin to reflect on the part you play in it.  Don’t look for villains.  They rarely exist.

What mortifies you?  What makes you cringe every time you reminisce on the mistakes of your past?  What has made you feel the most human throughout your career?

As I look back at my “blundering youth”, it’s clear that my propensity to debate, correct and contradict has me mortified.  (Pretty specific, right?)  I’m sure I know why I am “the way I am”.  In my house, everything seemed to be up for debate.  It never felt disrespectful or ill intentioned.  It’s just the way we communicated, and I’m grateful for it.  Not to sound duplicitous, but what has plagued me over the years also taught me to question things in my life, right down to authority figures I’ve encountered.  It served me well.

This confidence was/is one of the my best traits.  I quickly learned that the “rule makers”, those dressed up in temporary authority, were no different than you and me.  After all, they were the ones who made the rules.  They are no more intelligent or thoughtful than you and me.

The problems tended to come when I took it too far.  For effect, this is how it sounds when it’s gone too far:

“This is BS.  I can’t believe people are listening to this jackass!  I’ll make my own damn rules.  And dollars to donuts says they’ll be better than the close minded and obstinate dullard leaders force feeding their version of the gospel.”

Does this sound familiar to you?  The above sentiment is a concrete example of how a valuable personal trait can quickly turn harmful and eventually cause embarrassment.   And it did for me more times than I care to mention.  But, alas, I’m not alone.  I’ve learned it also happens to even the best among us.  Turns out we were all young once.

In the classic American autobiography of Benjamin Franklin, Franklin tells how he defeated his unfortunate habit of argument and “transformed himself into one of the most able, suave and diplomatic men in American history.”

One day, when Ben Franklin was a blundering youth, an old Quaker friend took him aside and lashed him with a few stinging truths, something like this:  Ben, you are impossible. Your opinions have a slap in them for everyone who differs with you. They have become so offensive that nobody cares for them. Your friends find they enjoy themselves better when you are not around. You know so much that no man can tell you anything. Indeed, no man is going to try, for the effort would lead only to discomfort and hard work. So you are not likely ever to know any more than you do now, which is very little.

Whoa.  That’s pretty sobering.  So what did Franklin do?  …He did what you might expect someone like Ben Franklin to do.

“I made it a rule,” said Franklin, “to forbear all direct contradiction to the sentiment of others, and all positive assertion of my own, I even forbade myself the use of every word or expression in the language that imported a fix’d opinion, such as ‘certainly,’ ‘undoubtedly,’ etc., and I adopted, instead of them, ‘I conceive,’ ‘I apprehend, ‘ or ‘I imagine’ a thing to be so or so, or ‘it so appears to me at present.’ When another asserted something that I thought an error, I deny’d myself the pleasure of contradicting him abruptly, and of showing immediately some absurdity in his proposition: and in answering I began by observing that in certain cases or circumstances his opinion would be right, but in the present case there appear’d or seem’d tome some difference, etc. I soon found the advantage of this change in my manner; the conversations I engag’d in went on more pleasantly. The modest way in which I propos’d my opinions procur’d them a readier reception and less contradiction; I had less mortification when I was found to be in the wrong, and I more easily prevaile’d with others to give up their mistakes and join with me when I happened to be in the right. “And this mode, which I at first put on with some violence to natural inclination, became at length so easy, and so habitual to me, that perhaps for these fifty years past no one has ever heard a dogmatical expression escape me.”

I can’t say I have this licked.  But for me, and for adults generally, learning and maturation happens through quiet, thoughtful reflection.  The great Ben Franklin has definitely given me something to reflect on.

If you haven’t read Dr. Russ Ackoff, you should. I’ve recently become acquainted with Dr. Ackoff’s work. I was immediately drawn to him because he reminds me so much of my Dad. He, like my father, is an architect by trade. He’s also a systems thinker and a leader in his heart.  He inspired this post and the examples within, and I want to share something I learned from both of them.

Think about the system, the whole, when leading change.

As leaders survey organizations in need of change, they will often take a reductionist view.  They break the organization into tiny pieces and look at those pieces to find problems.  When found, they set about solving local problems and optimizing each individual piece.  And who could blame them!  This is how we are taught to problem solve.  Break it down.  Focus on each piece.  I can almost hear my 7th grade algebra teacher as I write this.

The problem is that long term, effective solutions to issues occurring in complex systems (ie our organizations) rarely come from fixing mere components.  Awkwardly, the opposite is more likely.  (optimizing a part tends to sub-optimize the whole)  To make matters worse, most system issues arise in parts of the whole that are completely unrelated to the actual issue. The solution to that problem often needs to be addressed far away from where the symptom is actually occurring.

Take the “system” of the human body, and the “symptom” of a headache. When you have a headache, the issue causing the headache is rarely caused by the head.  If I have a headache, I can take aspirin or drink lots of water, which typically alleviates the headache.  What I don’t do is brain surgery.  Why?  Because it’s not the problem…the symptom of the real issue is occurring in the head, but the head is not the issue.

What is the typical response from most organizations that are experiencing the proverbial headache?  You guessed it – brain surgery.

Quality is low -  the code is crap…builds keeps failing.  Bugs are everywhere!

In the case above, the knee jerk, “brain surgery-style” solution is…?   It MUST be the developers!  We need to ride those darn developers until they get it right!  (or worse, we need new developers!)

This is not fiction, it is sadly typical.  My suggestions for situations like this is directly related to values espoused by Lean and Systems Thinking.  “Go and See”.  Map the value stream and see how the work works.  Look for bottlenecks, gaps, workarounds.  Ask tough questions and gain some insight.  Look at the entire system as a whole.  Learn about your systems, the people, their process, and more importantly their pain.  You might be shocked what a little understanding will yield.  It might just save you the painful recovery of brain surgery.

Over the past year, our staff has grown dramatically. What happens when you grow dramatically in a highrise office?  You run out of space. Fast.

We were no exception and we quickly ran out of space for new team members and co-located spaces for teams.  We began to do what we could to give people their own space while we look for more permanent digs. Temp space is not ideal. To be honest, it blows. Even so, our teams have done a fantastic job keeping their spirits up while we are in transition. Even they realize that temp space was inevitable (for now).

Interestingly enough, I recently hired a leader for one of our teams. He happened to be the new manager of one of the teams in our temp space. He hated it and I felt bad for he and the team. But something interesting happened. He began making simple, cosmetic changes to the area. Nothing earth shaking. Removing old vertical cabinets, arranging the coffee pots and desks in a particular way to open things up. Removing clutter around the windows to let light in so teams could see the great views from their floor.

Now these aren’t crazy changes. They’re simple, low cost, reasonable changes that have made a dramatic difference.  You might say, “so whats the big deal?  Seems like a few simple little changes.  Anyone could have done that!”

Exactly…    So why didn’t they?

I think the reason is non-trivial.  I’ve written in the past about managers and their tendency to assume that the affect of a change is in direct proportion to the force applied to the change.  For instance, they feel that if a change is dramatic, or expensive, or earth-shaking, it MUST be a change worth pursuing.  They also feel the inverse is true.  If a change is small, why do it?  How could it possibly yield results?

The sad fact is that most big wins come from small, inexpensive, sometimes miniscule changes to the landscape.  The simple act of paying attention to these details (ie “we feel like we are in a storage room”) and making micro-enhancements has a huge effect.

In a word, this manager has made his team’s space “pleasant”.  Not extravagant. Not expensive.  No approvals had to be given.  No blood was spilled.

Pleasant….and it has already made a world of difference.