In this brilliant video, Dave Foster Wallace explains that real education is not about knowledge, but about how you look at your challenges in life and how you choose to interpret life’s annoying trivialities that are all around you. Education is about awareness.

This is his commencement speech from 2005 at Kenyon College. I’m having a tough time explaining the not-so-trivial impact this lesson has had on me.

We all have a choice. Education affords us an opportunity to reflect. We have the opportunity to choose to see things and interpret their meaning positively, compassionately. Or, we can choose to be miserable, self centered wretches, unknowingly imprisoned by what we KNOW to be true (that just isn’t). That our default condition (that WE are the center of the universe) can be overcome with hard work and deliberate effort, and the knowledge that we can choose to think differently.

Related to work and career, one thing I do know is that happiness and fulfillment is not found in your “work”, per se, but in relationships and committed, long term sacrifices for those you serve – eg people you care about. (family, friends, teams)

http://youtu.be/vET9cvlGJQw

At a recent leadership event focused on Organizational Change Management, one of the comments I heard described a key point that I felt I couldn’t let go unnoticed. The comment that was made was, “we need to continue to show empathy to our partners, teams, and peers”.

At the surface, this seems like a “garden variety” type of statement. It’s not.

At one point in the day long leadership event on OCM, I told the story of my own attempts early in my careeer related to organizational change. It was mainly about mistakes I made related to “human factors”. My failure is littered with me (as the change agent in firms) showing very little empathy. Unfortunately, I see a lot of that everywhere I go, and sometimes (sadly) I was the cause of it. It’s sad because at NO point in my past did I feel like I was doing the wrong thing. From my point of view, I was trying very, very hard to help. What I learned was how much you have to pay attention to people, their emotions, their circumstances, and definitely have empathy if you’re ever going to have a chance to help them.

Devolve Into Name Calling

I don’t like to generalize too much, but this one actually might help. This incredibly simplistic generalization is that leaders tend to self-select into 2 groups:

• Change Agents
• Managers / Stabilizers

Change Agents challenge the status quo and tend to feel good with ambiguity, breaking things apart and trying to affect the system in a positive way. Managers / Stabilizers are focused on effectively and efficiently operating the system and spend their time making everything work predictably, at reasonable cost, with low risk. Basically, change agents change broken systems and stabilizers run and perfect them. What I have learned over the years is that WE NEED BOTH. After all, you can’t constantly smash organizations to bits and rebuild everything. You also can’t “polish”systems that are deeply, or fundamentally flawed.

I have also learned that there are predictable tendencies between these two groups:

1. Change Agents tend to look at Managers / Stabilizers as incapable of change, inept, lazy, and attribute behavior to personal characteristics (e.g. those people don’t know what they are doing!)
2. Managers / Stabilizers tend to look at Change Agents as arrogant, emotionless villains who are only out for their own self-interest. Everything they do is seen as despotic and offensive. (e.g. that guy is an asshole!)

Essentially, organizations devolve into name calling and the Fundamental Attribution Error. This cognitive bias basically is placing a heavy emphasis on personality traits to explain someones behavior rather than thinking about external factors.

A Third Trait

A third trait needs to evolve if we are to ever get forward momentum in our organizations. We need Leaders. Leaders help others understand that empathy and understanding is critical, and people behave based on incentives, as well as intrinsic or extrinsic motivators. They also teach that diversity of thought is critical, and that organizations need heavy doses of both roles to be successful. Leaders help both sides (and the unlucky middle) understand why we need both types of people, and how to effectively coexist. In effect, they teach people about ecology.

I will be writing more about ecology in upcoming posts. In the meantime, let me know what you think!

As a strapping young lad, I worked for my Dad’s management consulting firm “on location”. I happened to work at a firm that made a very, very exciting product – metal drawer slides (booyah!). In its simplest form, this product has exactly 3 parts: 2 pieces of metal (bent, punched and painted) and 1 nylon wheel that gets pressed onto one end. This firm did not suffer from lack of customers or an oversaturated competitive landscape, but this firm was clearly struggling. So why were we there?

For starters, they did not really understand their entire business from end to end. They hadn’t given thought to an integrated supplier network. Partnership with the people that actually shipped their products, raw material suppliers, etc? – Uh, no.

I will write at length about the menagerie of issues they encountered in another post, but for now, let me describe ONE of the symptoms those issues caused – a massive finished goods warehouse. The warehouse housed actual finished products, buffer stocks of every product sku, and much more. It also housed huge quantities of production product runs that weren’t to spec, or were sent back from drawer manufacturers in large quantities because they “didn’t fit”. It also contained blems, discontinued product lines, and more buffers.

At first blush, I’d guess this seemed like a pretty good idea. How else would they ensure they had enough product on hand to ship to customers at a moment’s notice? Not only that, it took 2 full days to retool the machinery and powder coating bays to get ready for new product runs. So, while they had their most popular models running, they decided to build extra units to ensure they were being efficient, and didn’t have to retool the machines (and waste all that time). So, they did what many manufacturing firms did. They built a massive finished goods warehouse. When they ran out of space, they built it bigger. In my estimation, they’d run out of space 3 or 4 times before we got there.

Imagine their surprise (and mine) when the first thing I was asked to do was to take 5 friends from the shop floor and start “recycling” mass quantities of finished goods, old parts, blems, etc. It was a horrible job. It felt like I was on an episode of “Hoarders – Enterprise-style”. We gutted that warehouse over the next weeks and months, leaving one “relatively” tiny section in the back corner near shipping and receiving for storage.

Why would we do that?

Let’s start with how firms look at excess inventory and why they manage it the way they do. How firms view excess inventory often determines the practices they employ to manage it. Excess inventory, in many manufacturing firms, is viewed as:

• An Asset (because it is listed on the left side of the balance sheet)
• A Stock buffer – “insurance” for demand fluctuations
• Insurance for production problems (scrap, incorrect bills of material, shortages, on the floor engineering changes)
• Some also view it as efficient use of resources. After all, BIG BATCHES are more efficient, right?

So what’s the real impact of excess inventory? Many companies view costs as simply the cost of borrowing money to finance and build the excess inventory. The true costs are significantly higher and include the following:

• Holding costs (cost of capital, warehousing, lost items, theft, damage, insurance, physical inventory counting)
• Product Obsolescence – finished goods are at heightened risk of becoming obsolete or unneeded
• Opportunity costs (missed sales)
• Delayed shipments due to order fulfillment issues and growing complexity – sometimes requiring expeditors

When all costs are considered, most companies find that inventory costs are in the 25 percent to 35 percent per year range. Yikes. This warehouse became a dumping ground for an out-of-control process. It was simply waste, but no one understood it. They didn’t have an idea of its true cost, how to rectify it, or how to eliminate it.

So how does this relate to Software Development?

If you look closely, there are obvious parallels in the software development space. The most obvious is related to the “large batch efficiencies” firms think they get in specifying software in advance. This one is fairly obvious to most, as requirements and “intended solutions” age and become obsolete. This causes an entire raft of dysfunctions from the waste of refactoring old and outdated specs, to the worse problem of massive and onerous change control processes that tend to drag projects out for months or years (and sadly products are built that no one wants or needs). What a waste!

If we dig a little deeper, many organizations (like mine) have adopted Lean principles and are attempting to build “flow” and “pull” into our processes and teams. We construct Kanbans to visualize that flow. By in large, this simple visual approach allows us to “see” bottlenecks at every steps in our process. This is HUGE because we can now take action to remove the bottleneck and get prodcuts to flow.

Interestingly, it ALSO allows us to see where we build “buffer stocks” and “finished goods warehouses” in the value stream. These buffers are often NOT acted on as we rationalize away the dysfunctions as “necessary” to our big batch mentality. This is why it’s important to challenge the need and inspect why you have them.

My opinion: Sometimes software-centric “finished goods warehouses” ARE necessary, but mostly they are built to cover up an out of control process that no one understands, all under the guise of “big batch” efficiency.

What we are trying to teach now, and what teams need to start to challenge themselves to understand, is that a “buffer stock” or “finished goods warehouse” can create the very same dysfunctions in your development processes as bottlenecks. It hinders flow, hides issues, and can create massive waste.

So….you are seeing the bottlenecks. Can you find where you build “buffers” or “warehouses” and explain why you need them? Do your kanban boards display excess inventory anywhere – even if you made an active decision to put it there? Is it more important to have them in the process than building flow? Are you building those things into the process to avoid another issue?

So What’s The “Big Idea”

Many of us, including me, work like the dickens to create systems that filter and classify work in our professional lives. Filters that allow us to get things done (execute), and think strategically. It’s critical in business to sharpen our ability to be planful and take advantage of strategic opportunities, and equally important to execute. If we don’t, everyone who counts on us will suffer, including our organizations broadly. The good news is that we have decent feedback loops in a business setting, and we get that feedback fairly quickly.

In our personal lives, this attitude of “plan and execute” tends to change. Somehow we feel that we go home to “get away from all that”. We don’t want to take our work home with us, so we divorce ourselves from the lessons and techniques we use at work when we arrive at home. People think (mistakenly in my opinion) that nothing should cross the work/home boundaries, lest our lives get thrown irreparably out of balance.

It’s no wonder that most people put little to no effort into building a reasonable sense of agency – the ability to think strategically and act on those strategies – when it comes to their own personal lives. My wife and I have come to realize that this is a huge mistake, because the things that we want to accomplish in the pursuit of fulfillment in our own lives tend to come from a category of stuff that we call “life goals”.

So to begin, I want to illustrate how “life goals” differ from other activities.

Define Your “Stuff”

As we take on the challenges of our days, work (or “stuff”) comes to us from everywhere. This “stuff” falls into the Stephen Covey Urgency/Importance Matrix, and can be defined this way:

Distractions - (Low Urgency, Low Importance)
These are items that are not important, nor are they urgent. They tend to be things that pop up all the time, because we let them. For me, these are things like web surfing, short stints in front of the television, arranging papers on my desk, browsing a magazine or two. It’s simple trivia and busywork.

Interruptions - (High Urgency, Low Importance)
These are urgent, but hold little/no relative value. I have three kids, and my life seems to be filled with these. “Dad. Dad! DAD!!!!” my son will scream from his room. When I arrive in a panic, thinking he just broke his leg, he asks me to get him some batteries for his flashlight (or a “peanut granola bar”).

Life Goals – (Low Urgency, High Importance)
This is stuff that’s important, but there is no urgency to get it done. This is where our “life goals” come from. This includes stuff like proactively building strong family friendships, reading and reflecting on parenting techniques to help our children build their independence and life skills, and creating a vision for what our marriage could be as we get to know one another more deeply, and deliberately creating the life we want.

Critical Activities – (High Urgency, High Importance)
These are things that are really important, and have clear urgency. These situations can take the form of emergencies, urgent family matters, disasters, etc. The typical response is to summon any and all resources you can to handle the activity, dropping everything else in your life. You essentially enter autopilot mode and go.

To build a life of fulfillment and meaning, my opinion is that you have to spend as much time as you can in quadrant #3 – Life Goals. Of course we need to spend time in all four of these quadrants, but spending time in the other three is not hard. In fact, those quadrants tend to “just happen”. Busy work, interruptions, and emergencies come and go all the time. And if you let yourself, you will stay in those three areas (and grow very little). Only by building your agentive “muscles” can you think about those areas that will actually create the life you want.

OK. By now you’re saying that talk is cheap. So, to put my money where my mouth is, I decided to take a few key lessons from my professional life and use them in pursuit of happier, more fulfilling days with my wife, my family, and myself. Interesting things ensued! I am learning a great deal about the power of taking my own advice. I’d like to describe the process along with some of the lessons learned (more details in a subsequent post).

The Concepts Used

Specifically, we used a planning retreat, a concept for perpetual planning that works extremely well in work settings. The concept is simple enough. Take yourself and your significant other “offsite”. Go somewhere familiar or go somewhere novel, but find a place that you can get some privacy, some focus, and get to work. Organize your time and prepare for the day with homework. Schedule a follow-up session quarterly. If you’re really aggressive, schedule a weekly check-in.

There are more than a few powerful concepts that emerge from time like this. Some examples include concepts taken from Lean and Kanban. One example: the ability to talk about emotionally charged areas of our lives with partners with a little less emotion. After all, if we have thoughtful life goals (about things like budgeting, marital communication, our kids, etc) and they are part of our quarterly offsite discussions, then we have a non-emotional way to bring these issues up in relative safety, and we can do it on a cadence (versus when we bounce a check) **I feel compelled to tell you we don’t bounce checks. :)

Other concepts examples: treating the “act of planning” as much more important than “the plan”.

“Plans are useless, but planning is invaluable” – Dwight Eisenhower

Via Personal Kanban, we are attempting to get everything out of our heads and visualized to manage the “existential overhead” of keeping tasks and projects in our brains. We combined GTD concepts to put the outcome of our planning in a trusted system so we could “manage the system, versus manage the work”. We determine things that need to get handled NOW, versus things we can PLAN, or those that we can DEFER (or things we can THROW AWAY). We use dates and deadlines sparingly for goals. We have plenty that has to have a date associated with it, but the bulk of our goals have no date because we view those dates as needless constraints and a source of guilt and angst if we find ourselves “living life” and missing occasional deadlines. Plus, we don’t want to be “shackled” to dates if we feel we can deliver faster (ok, I threw that last one in as a challenge to myself)

Lastly, we are using agile principles as well and have created a regular cadence to reflect on our approach (and ourselves) and tune accordingly. One way is through a weekly chat that allows us to review our system. The second is a “re-planning” session that will happen quarterly. If we start to come off the rails, or we feel like we are moving in a direction we don’t like, or we find ourselves with a new challenge we didn’t expect, the mechanism is in place to help us take deliberate action.

Well, that’s it for now. You’ve caught the experiment “in progress”. I would like to describe the actual planning process in more detail and I will do that in the next post. Maybe we will have a result by then!

Recently, Jim Benson asked if I could participate in an upcoming interview series on his blog called the “Modus 3-Question Series”. I unwittingly agreed. :)

Below are my answers to those interview questions.

Q1: Do deadlines empower your teams?

Unfortunately, the short answer is YES, I do feel deadlines empower our teams, but NOT in the way you might expect. Deadline empowerment can lead to wildly varying, and often times negative, outcomes.

To begin, most organizations don’t have a good sense of how to manage software developers or “value” in software projects. So, instead of working on a way to lead more effectively, they use a very handy (and simple) proxy for leadership…deadlines.

For most business leaders who don’t have the time, patience, or inclination to learn about software development, understanding the nature of these projects, and all the variables at the disposal of project teams, is daunting. In many organizations, much of the complexity is ignored, or worse, dismissed. In these organizations, software teams and their importance in the business ecosystem is marginalized and quickly these teams become more order-taker and less partner over time.

So then, what do deadlines “empower”?

Development teams, like any team of people, are motivated intrinsically to do a good job. If “doing a good job” becomes more about WHEN you deliver over WHAT, HOW, or WHY you are delivering, then those teams will move Heaven and earth to deliver ON TIME, ignoring some key concerns.

Common missing components in deadline-driven projects:

• (HOW) The deep complexity and craftsmanship needed to build a sustainable, resilient, manageable product that will grow and thrive over time.
• (WHAT) What is being asked of us? Should we build it all? Some of it? None of it?
• (WHY) Why are building this? Is there a better way? Can we help make this any simpler?

When teams are faced with a deadline, the typical response is to focus on the deadline and deliver (no matter what). This is definitely empowering, and seems like a reasonable arrangement, until you realize the incredible cost associated with missing the WHAT, HOW and most importantly the WHY.

(I can explain those costs more fully in another post.)

Q2: Do your customers expect delivery on deadlines?

Yes they do. And sometimes it is completely rational and unavoidable. Market pressure, response to regulatory mandates, legal requirements, etc., all require rapid, time bound responses to delivery.

However, in my experience over the last 17 years in (primarily) IT shops in financial services, insurance, banking, and even packaged software products, these deadlines are largely imposed by managers as a proxy for leadership. Customers and IT managers simply don’t know what else to do.

Q3: What are you doing to meet customer expectations (in response to or in lieu of deadlines)?

We are attempting to teach a new way of working. There are a few key steps we’ve taken to help our organization realize that deadlines, although sometimes very helpful, can also cause mayhem and colossal long term costs if placed in the center of our work. These costs can be predominantly avoidable.

Here are some key tenets we try and aspire to:

• Ensure your decision makers (the “business”) are engaged and partnering daily, and understand tradeoffs related to their choices. With good decision making and partnership, we tend to maximize what we don’t build, and eliminate waste.
• Educate the organization on the virtues of software craftsmanship, and why high quality software is crucial to reduce costs and to go fast. Architecture is then “baked in” to the process and we find ourselves leveraging our software versus fighting it.
• Teach the organization to “shrink their bets”. Massive projects take on a life of their own. And living things tend to create antibodies to change. With large projects, too much is riding on the vision, plans, and promises of the project and its stakeholders. When that happens, human nature is to “press on” and achieve project deadlines (even if the project or company is destroyed in the process).
• Teach organizations that learning is the most crucial, and scarce aspect of projects, not money or capacity. With smaller deliverables, teams can learn how to deliver high quality software extremely fast, and learn a great deal along the way. Rapid learning allows teams to change course quickly and achieve stunning results in the process, without massive investment in expanded capacity. (we do more with much, much less)

When the above conditions are met, customer expectations move away from simplistic models where DATES are the only thing they understand, to active partnership where RESULTS and VALUE once again take center stage. It’s not that deadlines are all bad. We understand they will always have a place in our work. We simply try and make them less important in our daily lives, and treat them as exceptions rather than the rule.

When we do this effectively, we find that deadlines take their rightful place in the background of our work versus in the center of it. The transition is tough and takes time. Over the years, we have found it becoming easier and easier to implement due to a thoughtful reflection on the deadline based alternative – years of deadline driven management and all the dysfunction and unintended consequences it has created.

I love the word “failure”. I love it! Why? Because it lets me know that teams are trying to get better! People are human, and everyone will fail (with some regularity in complex situations – I might add). To me, an awareness of failure, and open dialogue about failure is crucial for teams to begin to take ownership of committments, and their own evolution. But there’s a problem.

In my experience with some agile frameworks, failure is a nasty little concept. It doesn’t have to be, but sadly it tends to turn out that way.

The story goes like this:

Someone (me in a few regretful cases) enters and organization and creates a buzz around new concepts like Scrum and XP. We form teams and have lots of earlier struggles and, conversely, lots of early wins. During the process, the concept of time boxed iterations (sprints) is taught and internalized. Sprint planning commences and sprint goals are agreed to.

Thoughtful leaders keep these goals from becoming a list of user stories to be delivered. They design goals to be (struggling for a word here)… “thematic” (meaning, the goal is something a team and a business can sink their teeth into and is the living embodiment of the features, stories, and tasks that make it up the Sprint).

Fast forward to the retrospective:

The retrospective kicks off and Sprint Goals are discussed. Inevitably someone says, “we sort of delivered the goal, but we aren’t DONE. We missed 2 user stories. We committed to 10, and we only got 8 of them done. How can that be a success!?”

This is typically followed by a giant sucking sound that, over time, turns out to be the souls of the people that worked tirelessly to get 8 pitiful stories completed. (the sounds of them leaving their owners)

The game is now afoot:

What is a typical Pavlovian response to this kind of interaction? If I rap your knuckles and called you a failure because you can’t plan in 2 week increments, you have 2 reasonable “protective” responses.

1. you learn how to actually predict the future, and only commit to work you KNOW you will deliver, or
2. you sandbag in an attempt to ensure success and your own self preservation.

In my experience, working with brilliant, thoughtful, honest (albeit human) teams, the typical response is #2…. They commit to 6 stories, “success” is restored, and the balance in the force is regained.

What just happened?

My guess is that most teams, as they mature, could begin to deliver huge volumes of value…more than they ever thought possible in the beginning. Unfortunately, when teams link story count and timelines to failure, those outer boundaries are unachievable. Sadly, we have just created a team that will rarely, if ever, commit to more than 6 stories. Mostly it’s because of an incredibly myopic view and definition of “failure”.

Teams internalize failure as “not delivering the requisite number of stories on time”, no matter how hard you try and convince them otherwise. In fact, I have NEVER met a Scrum team that defines failure as anything other than not delivering enough on a predetermined timeline. That’s it. That’s all I hear. Ever…. Ever-ever. Really.

That’s not to say that teams don’t fail for many other reasons, but those really AWESOME failures (the ones we need to discuss and learn from) are rarely talked about, and (as I said two sentences ago) are never internalized as the actual “failure”.

To me, the interesting things that happen are when we try new techniques and they don’t work out, we implement strategies that need a little tweaking, we build a product that no one will buy, etc, etc. Those are awesome and can teach us a lot, and need attention. Time-boxed approaches make discussing these types of failures difficult because most are focused solely on the stop watch.

In Conclusion:

The fact that you cannot tell the future as a team is not revolutionary, interesting OR relevant, so let’s adopt an approach that doesn’t tie “professional guessing” (even in small time boxes) to our shared definition of success. For good measure, I would love to hear some of your examples of sprint failure, or your opinions on the topic! For extra credit, discuss how lean thinking and flow-based models help alleviate some of the problems caused by time-boxed approaches.

As a self-proclaimed “systems thinker”, Donella Meadows has given me quite a lot to think about.

The twelve leverage points to intervene in a system were proposed by Donella Meadows, a scientist and system analyst focused on environmental limits to economic growth. The leverage points, first published in 1997, were inspired by her attendance at a North American Free Trade Agreement (NAFTA) meeting in the early 1990s where she realized that a very large new system was being proposed but the mechanisms to manage it were ineffective.

Below, I have taken Donella’s 12 leverage points and tried to relate them to my context (an IT organization). I have tried to create IT-based examples and only slightly altered the original leverage point itself. The list is in increasing
order of effectiveness.

12. Constants, parameters, numbers (such as standards, SLA’s, etc)
Parameters are points of lowest leverage effects. Though they are the most clearly perceived among all leverages, they rarely change behaviors and therefore have little long-term effect.

The basis for thinking around this dates back to Taylorism – scientific management, and management by visual numbers alone. In most cases its “diddling with the details”. Many of the important issues a company faces cannot be measured (Deming) like the impact of an unhappy customer, or the multiplying effect of a happy one.

That said, it’s not that parameters aren’t import. They can be, especially in the short term and to those standing directly in the flow. People care deeply about parameters and fight fierce battles over them. If a system is chronically stagnant, parameter changes rarely kick-start it. If it’s wildly variable, they don’t usually stabilize it. If it’s growing out of control, they don’t break it.

11. The size of buffers and other stabilizing stocks, relative to their flows
A buffer’s ability to stabilize a system is important when the stock amount is much higher than the potential amount of inflows or outflows. In a lake, the water is the buffer: if there’s a lot more water than the inflow/outflow, the system stays stable. Buffers can improve a system, but they are often physical entities whose size is critical and can’t be changed easily.

Luckily, in software development or a service organization, stabilizing stock might not be physical and therefore the ability to alter it is not a constraint. Tools like Kanban and visualized workflow can quickly show us constraints. Our ability to “batch” just enough stabilizing stock (buffer) can happen quickly and with relative ease.

10. Structure of material stocks and flows
A system’s structure may have enormous effect on operations, but may be difficult or prohibitively expensive to change. Fluctuations, limitations, and bottlenecks may be easier to address.

For example, the flow of finished product into a production environment might be constrained by a teams ability to deliver it without an automated means. Stabilization and flow would require the use of an automated deployment solution which could be costly, and inconvenient to build and maintain.

9. Length of delays, relative to the rate of system changes
Information received too quickly or too late can cause over- or under reaction, even oscillations.

For example, the team is considering building a data warehouse. The project will take 2 years to complete, and the solution will be viable for 7-10 years. The first delay will prevent data from being useful for the first 2 years, while the second delay will make it impossible to build a warehouse with exactly the right capacity.

8. Strength of negative feedback loops, relative to the effect they are trying to correct against
A negative feedback loop slows down a process, tending to promote stability. The loop will keep the stock near the goal, thanks to parameters, accuracy and speed of information feedback, and size of correcting flows.

For example, one way for an IT project portfolio to avoid becoming less and less useful as mass quantities of work bombard the system (and subsequent projects stop being completed) is to implement a simple governance process. As business owners regularly work with one another to force priority decisions and reduce the burden, the participant receive a direct benefit. This doesn’t happen simply by “slowing their requests to IT”, but actually reducing their requests to a level appropriate for IT teams to absorb effectively. The participants cannot benefit from “doing damage more slowly” – only from actually helping.

7. Gain around driving positive feedback loops
A positive feedback loop speeds up a process. Meadows indicates that in most cases, it is preferable to slow down a positive loop, rather than speeding up a negative one.

The “calcification” of an IT ecosystem is a typical feedback loop that goes wild. Through mass contract hiring, lots of processes and projects can be supported. An increase in capacity will lead to an increase in projects and an increase in productivity of the system. More project productivity leads to more technology implementations, more technology (physical and virtual), more processes and activity, more IT support, etc. The more systems are built and managed, the more work is generated, and productivity increases. However, this technology sprawl begins to calcify as it is delivered onto production hardware. The more that’s delivered, especially that which is built with a primary objective of “quick and dirty”, the more complexity built into the system. The more complex, the harder it is to manage ongoing enhancements, and understand the nature of what needs to be enhanced. Over time, complex patches, dead code, contractors exiting firms and taking their knowledge, un-owned systems, and failed refactorings adds to the system calcification until many of those systems are near unsupportable. At some point, the IT delivery mechanism grinds to a hault, and IT staff work feverishly just to “keep the lights on”.

6. Structure of information flow (who does and does not have access to what kinds of information)
Information flow is neither a parameter, nor a reinforcing or slowing loop, but a loop that delivers new information. It is cheaper and easier to change information flows than it is to change structure.

An example is “visualization” of current work in the context of a system. Kanban methods are a good example, and so are scrum artifacts that tend to radiate information. This speeds the information flow to a much broader audience and can have a big impact on the actors in the ecosystem. In many cases, unimpeded flow of information lead to major change in the operation of the system. We humans have a systematic tendency to avoid the impact of our own decisions. That’s why so many feedback loops are missing – and why this type of feedback loop is popular with the masses, unpopular with the current powers that be, and effective when done.

5. Rules of the system (such as incentives, punishment, constraints)
If you want to understand the deepest malfunctions of a system, pay attention to rules, and to who makes them.

In an IT context, rule-making comes from many places (executives, HR, managers, regulatory authorities etc). In general though, the rules tend to come from the management structure that exists in IT. And, “rules” are a very powerful lever indeed (and they’ll always exist). There is a caution though, as rules tend to drive unexpected behavior. I like to believe excessive rule making as “lazy-leadership”. If there are behaviors I want, I offer incentives. If I want a behavior gone, I regulate. In almost every way, both of these tools miss the point, and tend to de-moralize behavior in the system. We drive people to do things for the reward, NOT because it’s the right thing to do. Or, we create a game to find the loop-holes.

4. Power to add, change, evolve, or self-organize system structure
Self-organization describes a system’s ability to change itself by creating new structures, adding new negative and positive feedback loops, promoting new information flows, or making new rules.

Lean and Agile philosophies derive much of their true power from this incredibly influential lever. The ability to evolve a system or subsystem with autonomy and self-organization cannot be understated. The IT community is still grappling with their new found autonomy (in the last 10-15 years), but those that have been given this power have made incredible progress over time. This capacity of part of the system to participate in its own evolution is a major leverage for change.

3. Goal of the system
Changing goals changes every item listed above: parameters, feedback loops, information and self-organization.

An organization might make a decision to change the goal of an IT staff, moving the operations and support functions out of the organization to a third party provider. That goal change will effect several of the above leverage points: information on SLA’s might go from loosely administered to contractual obligations (rules). Or, a IT organization might decide to go from an “order taking” function to a “technology steward” function, altering many of the above levers almost overnight. To be sure, a change in the goal of the system is a powerful lever in the intervention of an IT system.

2. Mindset or paradigm that the system — its goals, structure, rules, delays, parameters — arises from
A societal paradigm is an idea, a shared unstated assumption, or a system of thought that is the foundation of complex social structures. Paradigms are very hard to change, but there are no limits to paradigm change. Meadows indicates paradigms might be changed by repeatedly and consistently pointing out anomalies and failures in the current paradigm to those with open minds.

There exists a concept called double-loop learning, developed and popularized by Chris Argyris. By in large, the point of double loop learning is that, when faced with consistent failures of a system to reach it’s goal, we begin to challenge the goal itself, not the strategy to reach the goal. In single loop learning, if we fail, we “try-try again”. What if the current mode of thinking that draws us to this goal is fundamentally flawed?

A concrete example might go like this: IT is a service provider. We continue to be the best service provider and pay close attention to our customers needs. Whenever they ask us to deliver, we do it. We don’t ask questions and we don’t say no. And in doing so, we are fulfilling our primary purpose.

In this scenario, we have a belief system that says “we do what the customer wants”. What happens if we continue to try and make this model work, but it never does? Instead of coming up with another strategy to “deliver what they asked for”, maybe we should question the fundamental paradigm. Why does our IT organization exist?

1. Power to transcend paradigms
Transcending paradigms may go beyond challenging fundamental assumptions, into the realm of changing the values and priorities that lead to the assumptions, and being able to choose among value sets at will.

Many today see IT as a stock of resources to be converted to organizational services. Some firms believe that looking at IT as people that have needs, dreams, expectations, and a yearning to be challenged . These views are incompatible, but perhaps another viewpoint could incorporate them both, along with others. In essence, to keep yourself unattached, flexible, and to realize that no paradigm is “true”. Even the one that shapes your own world view is incredibly limited, almost laughable understanding of the true complexity.

I enjoyed Donella’s position, and I loved going through this exercise. It’s helped me organize my thoughts, and in a way, is something to come back to when I need to challenge myself. I will leave you with one final thought from her paper:

“Magical leverage points are not easily accessible, even if we know where they are and what direction to push on them. There are no cheap tickets to mastery. You have to work at it, whether that means rigorously analayzing a system, or rigorously casting off your own paradigms and throwing yourself into the humility of “not knowing”. In the end, it seems that power has less to do with leverage points than it does with strategically, profoundly, madly letting go.”

Dear Reader,

I came across a nifty little infographic and thought enough of it to post it to my site. I think this gives some really simple, but useful advice and data on how to recognize and reduce anxiety and stress (all from thesimpledollar.com) Enjoy!
6 Ways to Avoid Burnout

Have you ever heard this: “How could you possibly use stickies? How in the world would you ever know if something’s been on your board too long?”

I have. And here’s the answer.

My new friend Mike Burrows (@asplake) is toying with a new concept he calls DOTS – “Dots On The Stickies”. That has a nice fractal-ring to it, don’t you think? I can’t wait for his new DOTS Theory to be published. The basics of the technique have been used, more or less, since Kanban’s domination by 3M. Teams are simply trying to determine how long a stickie has been “Blocked” (typically) or in a particular queue where they want to measure aging. The basic premise is you simply put a dot on the stickie every daily standup to show visually that its aging. (Measuring those DOTS across the entire board is where Mike’s theory starts)

…And that’s great for queues, but how do you tell if it’s been in the entire value stream too long?

Enter the Stickie Half-Life Theory. If your stickie no longer “sticks”, it’s been on the board too long. …Whoa! Mind explosion, right? My theory is that a stickie’s efficacy (meaning it still sticks) is around 8 weeks and it’s half-life is the point where it’s likely been there too long. The exponential rate of stickie decay means that at four weeks (stickie half-life), the stickie will begin to fall off the board regularly. It is at this point we should begin to worry about a stickies age in the value stream.

Discuss.

We. Are. Drowning.

We are drowning in email, and we are drowning in meetings.

EMAIL:
An email inbox has been aptly described as the to-do list that anyone in the world can add an item to. If you’re not careful, it can gobble up most of your working week. Then you’ve become a reactive robot responding to other people’s requests, instead of a proactive agent addressing your own true priorities. This is not good.

CALENDAR:
The problem with calendars is that they are additive rather than subtractive. They approach your time as something to add to rather than subtract from. Adding a meeting is innocuous. You’re acting on a calendar. A calendar isn’t a person. It isn’t even a thing. It’s an abstraction. But subtracting an hour from the life of another human being isn’t to be taken lightly. It’s almost violent. It’s certainly invasive. Shared calendars are vessels you fill by taking things away from other people. “I’m adding a meeting” should really be “I’m subtracting an hour from your life.”

As an homage to your continuous improvement mantra, I would like to suggest a full reboot. I want to challenge the notion that your work happens, in large part, through Outlook. It doesn’t have to be that way, and is clearly not optimal. You need thought leadership and mutual agreement to break the cycle. I suggest you do something interesting. Namely, you agree to improve!

Some simple steps to get you started:

• Use any excuse you can think of to purge and prune your calendars of the “dead wood”. Then Model Behavior.
• Revise your meeting strategy to include, mainly, working meetings that deliver value as opposed to planning value. (careful not to undermine your need for a collaborative culture)
• Encourage face to face, “unplanned” discussions when needed, versus standing or recurring meetings (not to be confused with the real value of a 10 minute stand-up)
• Encourage 25 minute meetings as the “new normal” versus 1 hour. 25 minutes to meet and 5 minutes to get on the “hush puppy express” (in other words, 5 minutes to walk to where you’re going)
• Encourage ending on time, or before time! There’s a novel idea!
• Encourage reasonable agendas for planned sessions and the tactical meeting format from “Death by Meeting” for tactical discussions.
• Encourage team members to sign the email charter at http://emailcharter.org and agree to its content
• Encourage team members to add the email charter to their email signatures
• Encourage leaders to proactively “design” team meetings, stand-ups, and All Team Meetings to occur in tight sequences
• Encourage blocks of “working time” as acceptable placeholders for your thought workers

To be clear, I think there are many ways to take control of calendars and email. These are simple ideas that won’t take much effort, but will constitute a powerful change in team and individual behavior.