The interwebs offers three definitions of the term friction:

  1. The resistance that one surface or object encounters when moving over another.

  2. The action of one surface or object rubbing against another.

  3. Conflict or animosity caused by a clash of wills, temperaments, or opinions.

I want to rephrase and examine it as the base term of “resistance to fluid motion” and apply it at an organizational level. Are we aware of it, what strategies can we apply to it and why it may exist.

What brought me to this topic? Very simple. Home repair.

My better half asked me to disassemble something for removal to the dump. Tools in hand I approached the task only to find that the bolts with which the item was put together had become rather fused through years of usage (and possibly over tightening to begin with). So I struggled. I strained. I tried to focus the inner superhero inside of myself to well up enough adrenaline to move this immobile object.

Nothing. I tried and tried and made no headway. I dropped tools, I cursed the item and even began to question and lament my own physical strength to being the reason I could not get this task done. I was exacerbated, exhausted, frustrated and felt the task was not only ridiculous but even a little resentment for being asked to even do this. In a huff of lack of progress, I walked away from this activity to sulk over the lack of progress.

My wife, being caring and trying to be supportive asked me “how’s it coming”?

A status report? Really? That was not the best time as you can imagine. This resulting in a re-telling of the epic battle of “man vs. bolt” in which the end result was man was laid to waste in the shadow of the all-mighty power of the impenetrable bolt. This story was told with the flair of a new Star Wars movie complete with arm gestures, sound effects and emotions ending with a culmination of “I suck at tools”.

Continuing to be supportive she listened patiently and allowed me to regale her with the tale of the mighty bolt to which she said encouragingly, “I know you. You’ll figure it out”.

I shrugged, grabbed an ice cold refreshment and sat in my chair to mull over my defeat.

As I sat, I began to think more and more about the situation. What would my dad have done? He was the consummate master of all things tool and repair related. If you needed a tool, he had it. If you were unsure how to approach a problem, he could envision the solution. It always seemed like he just “did it” with far more ease than I could ever do.

One thing he taught me about tools (although a lot did not stick) was “son, always have the right tool to get the job done”. I had the right physical tools. But I recalled a similar situation when we were working to replace an alternator on a car. He reached on the shelf and grabbed something and BAM the bolt magically loosened. I remembered him telling me that “sometimes when you hit bolt resistance, they just need a little lubricant”.

Eureka! I sprang from chair, grabbed the can I had in the garage, sprayed the bolt and within 30 minutes the item was disassembled. I strutted proudly back into the office announcing “all done” to which I received the adulation of the conquering hero of the dreaded bolt! But what did I really do? I applied the same tools and the same strategy as before but with one difference, I reduced the amount of resistance. I eased the friction and as a result, I saw immediate value.

This got me to thinking … what is that magic spray that I might be able to apply to organizational stickage or organizational friction?

Friction within Organizations

The prior story took a long way to get us here, however, I wanted to share the levels of physical and emotional impact that the inability to overcome this simple case of resistance took on me personally.

Organizational friction is not unsimilar. When we as a member of an organization hit a point that impedes our progress to an end goal, we almost immediately (as we are wired by the human condition) enter a “fight or flight” mode. We either become frustrated and angry at the process/person that is stopping the progress or we back away in frustration to brood/complain to others or just sulk about the situation. We experience feelings not uncommon to the same way I felt when I encountered the physical resistance of that bolt.

I think if you can stop for a moment, you can probably easily identify your own areas of “organizational friction”. As I sat and thought about this, I identified a few broad areas that seemed to be good indicators for a potential for organizational friction:

  • Exchanges between siloed functional areas that although they may work together are relatively autonomous in their process and function.
  • Exchanges between groups that have deeply ingrained and conflicting work culture or deeply defined organizational missions, sometimes in opposition.
  • Interactions between groups that typically work together and therefore have processes and or policies that may be heavy to one another.

Can’t you just loosen the processes?

This seems a natural “kneejerk” reaction when one encounters something they feel is stringent. However, this like my first experience cooking with natural ginger root. I just cut off a block to season my dish and in the end it was all I could taste. The key is remaining “value focused” and applying just the right amount to meet the need (just like ginger root) when approaching adjustments due to friction. And just like my cooking experience, you can make one’s self “gun shy” to the experience if a bad outcome is had in your first experiment.

Using the historical perspective of a “moment in time” bad experience often means we can end up creating process around a “people problem” as opposed to a “process problem”.

A natural “knee jerk” reaction is to shun all process as we believe that is the core issue to the problem at hand. Sometimes a process can actually be problematic but I am a fan of always inspecting how you work s opposed to abandoning something merely because and . Sometimes abandonment is the right thing to do as circumstances have changed or the world around us has shifted.

Too many times I see people stop asking if the new and progressive process that they created still works for the organization at hand. They lie dormant on a shelf only to be pulled out and dusted off to clarify a situation.

Couldn’t it be more productive for review of these things and see where improvements can be made and ensure that we are not optimizing the past for the sake of having a process in place? I guess my opinion is that as often painful as it is to implement a process change, doing so without regular intervals of effectiveness creates future pain.

The “invisible process”

I worked for a company once that when I asked about a specific situation or implementation, I received the same canned response “that’s our policy”. I recall receiving this response over and over again when inquiring about everything from organizational change to aesthetics of page design. So one day, being the curious sort I am, I asked “may I see these policies and processes”?

This was met with a lot of back peddling at which time I was told these were “accepted practice” of the business. I pressed on this issue and asked how we held employees accountable to these ideals if they were not available for them to be aware. I was told that each employee was deeply versed in these when hired (which struck me as odd as most of the requests were based upon questions I received from a team for which I was the lead).

But what the organization had done had insulated itself by creating these invisible processes and calling them “standard practice”. This allowed them to deflect items in which they sought not to address through their quote as needed. I worked very hard with this organization to see the value of the transparency of these processes and utilize the strength and creativity of their staff to determine which invisible practices may actually be hurting them either through overall credibility or staff confusion.

If you find that your organization has “accepted practice”, increase the visibility. Communicate them so that they can be inspected like any other process. There is absolutely nothing wrong with having a way in which you work but doing so without a mechanism to communicate understanding internally and externally can be problematic.

So how do I combat organizational friction?

  1. Realize it potentially exists. An organization is a complex system of moving parts and as so local edicts which may impact those outside the group may result in friction. Don’t bury your head into the sand over this fact.
  2. Be as transparent as possible. Shy away from not having a communication channel in the way you work. In the book Traction, one mechanism is indicated as creating your organizational “way” of how you conduct the function you do. But be mindful here. These cannot live in a vacuum, you must regular revisit this to know if you are a) working as you state you do for organizational accountability and b)ensure you are effectively communicating how things change over time.
  3. Make a cultural shift to being one of a problem solving organization. Create a culture in which across your organization you get the affected people in the room so you can 1) ensure that there is good alignment between affected groups and they shift from a culture of “doing my part” to one of seeing the end goal as a whole and 2) create a culture of “shared understanding” which develops people to not necessarily understand the depth of another domain but gives them context to the pains and end goals of the various groups involved.
  4. If you need a process for guidance, make it as lean as possible and instill mechanisms to review on a regular horizon. Remember the natural reaction for anyone when encountered by an obstacle is to seek to get around it. So if you have optimized your process for a single group without understanding impact or ongoing effectiveness, you may find people finding creative ways to avoid it altogether.
  5. Work to reduce risk and friction by making room for recurrent small horizon activities. By making things at a more micro level you can a) have a much more manageable level of work, put in place more timely rollback plans in the case of failure for recovery and ensure that the system in place remains light to better encourage people to “follow the rules” in place.
  6. Create a mechanism and bandwidth for regular feedback upon which you can take action when friction occurs. Receiving feedback decoupled from any way to make actionable changes discourages people to even raise an issue of where friction may be occurring.
  7. Realize that some processes may be cumbersome. Really dig into them for the end core value. Visualize the workflow and why each step and the surrounding rituals and artifacts are needed. Be open to challenge and eliminate areas built up around historical mistrust and reflect on how it’s actually working.

And last, don’t try and eat the elephant all at once. Find a small collection of things to review and potentially improve. Put in the mechanisms to monitor the changes (can be a simple as a retro to as “better/worse/fiasco”) to see if you are still on track. Avoid bending to the LVITR (“Loudest voice in the room”) syndrome through facilitation and ensure that the right people are there and give input of the impact of friction, trust the people doing the work and encourage them to solve the problems and make their work even better.

Hope everyone has a great upcoming holiday! Stay Agile!


Team Icebreakers

I am a big fan of using small team exercises to just people out of their “head space” for a moment before refocusing back to the area of work. Sometimes it can be a physical (just stand and stretch, take a team stroll) or be just a small thing to let people begin talking about non work focus items to just relax for a moment. I also appreciate, as does my team culture, the value that humor affords in work.

A great way to start teams talking before a daily stand-up or retrospective is with an icebreaker. I have come across a few simple ones (some I have used in the past) that I think is a great way to just stimulate spontaneous response and to allow the teams to loosen up and get ready  to communicate.

One Second Trivia

Prep Time: 5 minutes or less dependent on how quickly a scrum master thinks on their feet. Questions can be prepared on index cards or scrum master can make them up on the spot.

Run Time: 1-2 turns per team member

Goal: To just relax people with potential humor and “prime the communication pipeline”.

Rules: Only 2.

  1. You must provide an answer within one second.
  2. There is no wrong answer in this game.


As each team member a question and allow them to give an immediate response (much harder within one second than you think),


  • “What can you not grow in a garden”?
  • “Why did you borrow $20.00”?
  • (Fill in the blank) “You superpower is …”
  • “What is a vegetable that should not exist”?
  • “What is Beyonce’s middle name”?
  • (Fill in the blank) “The code word for this product is …”
  • “Where are you keeping that candy bar”?

The objective is just to get the team relaxed and ready to connect. Often time hilarity will ensue as coming up with answers for these in one second typically results in whatever pops into your mind.

You can change things up by allowing team members to run the game and prepare their own questions. It does not take very long and it engages them.

Yes. And …

Prep Time: No real prep time needed, just the ability to seed a conversation.

Run Time: 1-2 turns per team member

Goal: To help team members develop engagement and listening skills with one another as well as reinforce being value additive.

Rules: The objective is to listen to the statement made by the previous team member and continue the story by adding “Yes, and …”


Seed the conversation to start with a topic or lead-in. Examples:

  • “Yesterday, we went to the zoo …”
  • “When I was preparing for my career as an astronaut I went to Walmart”
  • “Today began as the worst day ever”
  • “I came home last night and decided to bake a cake”
  • “I met my evil twin yesterday in a coffee shop.”

Power Animals

Prep Time: 5 minutes or less. Requires either drawing animals on index cards or finding small pictures to tape on cards, etc so that they can be placed into something to draw from by each team member.

Run Time: 1 turn per team pic member

Goal: To just relax people with potential humor and “prime the communication pipeline”.


  1. Respond as quickly as possible.
  2. There is no wrong answer in this game.


Set the stage – “This is the power animal game. In this (bowl/box/hat) are many types of exotic and amazing animals (make a lot of them really odd or very mundane animals). This animal has specifically selected you to be able to channel some of their special abilities in any time of need.

The goal of this game is for you to relay to the team why this animal picked you specifically to be your power animal and what power(s) did they grant you.

  • Have each team member reach into a shoebox or bowl and draw out a picture of an animal and respond. It’s often not only humorous but can often be insightful into gifts that a team member has or wishes they possessed. Good information for strengthening team member connections with one another and with the scrum master.

Capacity and Performance

“Your capacity to say no determines your capacity to say yes to greater things”        – E. Stanley Jones

This is something in business we all struggle with in my assessment. How to sequence “just the right amount of work” to deliver value and still all the desired ability of an organization to remain responsive to shifting value needs. My organization has struggled with it as I feel confident many of you have as well.

There are a lot of techniques, both agile and not, to determine capacity and we’ll look at a few and I will express my own opinions here and what effects poor capacity planning can have on teams and organizations.

Somebody call 911!

A lot of us live in a world of “firefighting” as an organization. Not literally, but what I mean is that we become reactionary as an organization as opposed to responsive.  Organizations often confuse responsiveness as the ability to handle each fire as it occurs when it reality this is chaos at its core. Often, these organizations are so busy fighting the blaze that they never take the time once the situation has passed to ask why the fire actually started in the first place or they confuse every flare up on the same level as the entire city in flames. This is not responsive, it’s reactionary and although you may be defined as the “hero of the day” in the moment, it eventually raises much deeper problems that can become exposed and have to be addressed.

Being a reactionary environment is inefficient. It means that there is a significant amount of waste happening waiting for the disastrous event or worse yet it is a sign that work is improperly sequenced to allow a balance of responsiveness and performance. Signs of this are often team member turnover, sick time increases, increased deep policy to attempt to be preventive (the “ban all matches” approach) or just a general negative outlook to solving a problem. Be vigilant in observation for these types of issues as one you define yourself as this type of an organization, it is often very painful to change.

Capacity, Performance and the myth of being busy

One of the things that I have always believed is “do less better”. Ensure that you are meeting the highest value items for an organization but in the face of emergent needs you have to deliberately create slack within your work capacity for numerous reasons. Things like actually being responsive to the emergent pet project that comes up, capacity to nurture your teams and team members to allow them to grow and give back to the organization in doing so and generally to improve performance throughput

Basically capacity boils down to “how much something will hold” from a true math reference bt in our terms it means how much time and work can we consider and remain effective in our performance. Finding area and volume of a given shape to determine capacity is a relatively simple formula but when it comes to people and time, it often gets tougher (although I know many PMP folks who would explain to me formulas of resource management, resource being a word I strongly detest when referring to “people”).

A general rule of thumb is that you will never receive the maximum capacity of a given person or team. Accept this. If a person works an 10 hour day, the best you can hope for us 70%-80% which is roughly 7-8 hours at the high ends. The reason for this is that people are social creatures and have needs like going to the restroom, checking emails, diverting their attention after prolonged focus, casual conversation, meetings, etc.

If there are CIOs/CFOs/COOs/CEOs reading this in awe and shock, welcome to the reality of people. And it is even possible that 10% of your overall workforce is performing suboptimal based on lack of skills, poor work ethic, sickness, burnout or whatever reason. So how do you handle this and still maintain a level of performance without remaining in a constant hiring frenzy of cycling burnout workers?

First, accept your reasonable capacity levels and plan strategically. If you do, you will find that you optimize the flow of delivery within that capacity and you often see higher percentages executed (which can be a different topic to watch for … “dark work” that has no visibility and creates strain but as things are delivered on time no one questions).

If you think more bodies are the answer. You’re wrong. Read the Mythical Man Month. As you increase complexity to any systems you fragment pathways making performance degrade. Think of a small intimate dinner gathering and how conversation can flow well between 2 couples (as they can keep up with topics or break into smaller sub groups and still reflect to the group). Now introduce 2 more, and 2 more, and 2 more. Make it a large dinner party and afterward come home to discuss the topics of conversation. The pathways are too complex. You cannot keep everyone in the loop on all of the conversation occurring.

The same thing occurs with software development. As you introduce more and more staff you increase the complexity in the forms or handoffs, communication pipelines, individual or small group decisions that get made, etc which make it slower as rediscussion, rework and deeper changes are often a result. This is often why I prefer product feature teams as opposed to component teams whenever possible.

Secondly, if you want to be responsive; be deliberate in building in slack to your approach. Let’s take 3 examples; road networks, servers and teams.

Road Networks:

You are driving to work. There are 30%-50% of other cars on the road. You make your commute in a reasonable amount of time. But we are not utilizing all of the capacity of the road! So let’s crank it up to 100% and make that same commute. What is the expected result? Traffic jams, delays due to accidents, road rage. We actually decreased our performance by trying to fill all of our capacity.


This is a little tougher as in the day of invisible scalability of cloud networks it may seem a poor example, however, if a server capacity is maximized to 100%, performance degrades; it is a given. It results in unneeded swapping just to meet all requests. It may seem negligible but if you have ever been frustrated waiting for a web page to load, you may have been experiencing exceeded capacity.


Filling a team capacity to the brim can result in whiplash when trying to meet those emergent needs With that allowed focus, you have teams that maximum their throughput through selection, self-organization and a regular cadence. If they have other responsibilities (support, meetings, etc) not building in that capacity that is aware of these things will result in feelings of being high performing but in fact often degrade performance and hide a lot of work being done on an employee’s own time (which can result in a whole host of issues).

But we have to keep people busy

Do we? Did we hire the individual with a specialized set of skills to ensure they remained “busy” or did we hire them to ensure that we had the necessary skills to realize the end result of value?

If a manager pops into a team room and a team is relaxed, having a conversation about Dr. Who or some world event is that ok? Sure it is. If they are personally making their commitments and failing to deliver value, then you might sense a problem which could be everything from they are sandbagging to they are being disrupted externally for other work to the guidance they are receiving is creating deep and counter productive conversations at the time of delivery from a lack of understanding. It could be lots of things.

The point is not to keep people busy. In trying to do this based on observations of social interaction as a sign of low productivity, you toss the idea of capacity out the window. For me, I want a highly motivated team that wants to come to work and deliver because they know they have a direct voice in setting and communicating reasonable expectations for feature delivery. Does this not mean that occasionally the team may not be forced to ramp up commitments to meet a deadline? Absolutely not. But if you trust the people doing the work to be reasonable and responsible in communication, transparency and of the delivery of that work; often times I find teams will rally to address the hard need.

Otherwise they are back in firefighting mode.

Seeking to ensure teams and team members are “all busy” is a false goal. It equates people with server throughput. People should be cultivated and grown if you want to create longevity of any sort in your company with employees. They will become your greatest champions and advocates if you embrace this. They will tell others of the great company they work for and they will work hard to deliver of their commitments.

I write this post today not out of any personal or professional frustration but from an observation that many organizations focus on “busy” as opposed to intentionally creating space to be responsive to emergent needs. Just like a home’s unused space get filled, professional people fill the unused space (through skill acquisition, environment improvement, idea sharing, etc). But just like a home; should you inherit your grandmother’s giant steamer trunk if you have filled all of your capacity of space it gets placed in an odd location or you “make room in the attic”.

Be honest and kind to yourself as an organization, your people and reflect a true understanding of capacity by considering more than just “delivering more” or “being busy”. Understand what other impacts that people have that impinge on capacity and to become truly responsive, be intentional in creating slack within your overall capacity.

As I always say and I will say once again … “Do less better”.


Product and Organizational Bloat

“Life’s too short to build something nobody wants” – Ash Maurya

YAGNI or “You Ain’t Gonna Need It” is a principle of the extreme programming approach created by Ron Jeffries (who coincidently also used story cards as a way to focus development on small items centered around interaction and conversation to gain understanding).

“Always implement things when you actually need them, never when you just foresee that you need them.” – Ron Jeffries

This idea was a cornerstone of a lot of approaches centered around lean product development and agile product thinking. It does not mean that you are not charged when developing a product that may wow and excite your stakeholders but it does mean that there is a real art in the balance of applying “not now” to a feature.

Steve Jobs is often referenced to have a keen intuition to this in guiding the feature sets of Apple products under his watch to often purposely avoid features that were not at a point of making the “right” impact. The iPhone and its lack of a few core features available in competitors is often referenced as an example of this. Why would you not implement features that were core to the competitor’s products on purpose? I am paraphrasing but I believe his response was often “it is less important to build every feature than to build the right ones and that by trying to do so, by the time completed; they will want different features”.

Anyone who has ever seen the Simpson’s episode in which Homer designed his own car (“The Homer“) realizes the potential consequences of doing everything that pops into your head within product development. The end result was a car that was intended to be designed for the “every man” but ultimately became the wishlist of Homer alone with a sticker price for $82,000.

In the 80’s and 90’s Microsoft was often the butt of many jokes within the development and design community for their Microsoft Word product because if every menu was turned on within the product it allowed the end user a small strip of editor window from which to work. Of course, this was a extreme issue to beat on a software leader of the time (and they did have at least 80% of the menus off by default for the most part). The idea though was that by providing all of these features it would allow the end user to control the customization of the product to their use. This is pretty much an old design approach that is far less prevalent as it was often necessary to be coupled with massive help guidance for those features which were embedded into the product at the time as well.

One example I have been tracking recently is Facebook’s feature growth strategy. They started out as a targeted social connector service that streamlined the interface to dominate the competitors in the market . It seems, however, now they are developing a “all services in one” model which may, or may not, pan out to be the right marketing strategy. Let’s look at how their features have unfolded lately:

  • Introduced Facebook Games possibly as a way to attempt to compete within the mobile application game market.
  • Introduced Messenger – Competition for base messaging services and maybe things like slack, skype, etc.
  • Introduced Facebook Live – Competition to other video sites such as Youtube, etc possibly.
  • Recently introduced Facebook marketplace as an alternative to Craigslist, etc.
  • Developed a phone OS to compete with Apple, Android, Google.

I think that this pattern outlines a platform that is in search of the next pinnacle. All of these services also are a way for them to feed a highly developed analytic engine that can determine the trends of users and try and guide them down a pathway based on interests. Not a bad gamble as the likelihood that you will find a segment of the market space dissatisfied with a service they are matching and willing to even just try it based on the familiarity with the Facebook platform is a solid gamble. In this fast pace environment, people like to do things with minimal friction (a later blog topic) so you will capture a market.

The key will be watching the numbers to determine if it is important to continue this feature, Google has been a master of this approach and has supported and abandoned entire products that had a minimal market share and I think Facebook will apply the same watchful nature to know when it is time to pivot or persevere. But only time will tell. 😉 Will the expand and rule some of this space or will they diffuse and diverge to find something else?

You may be thinking “are you telling me I should just build a simple, crappy product and not cultivate the product. How is that gonna fly”? This is not my intent.

Ideation is a Great Tool!

The Google Ventures Design Sprint outlines the following process (also seen in many Lean approaches) to validate and learn about feature impact as well as gain immediate feedback within a fixed horizon process (in their process this is typically one week).

  1. Understand
  2. Diverge
  3. Converge
  4. Prototype
  5. Test

Phase two of this process is centered around divergence after a period of gaining understanding of the problem space. What this entails in mass generation about potential solutions to the problem. The goal is to center around the largest number of potential solutions so that the design sprint team can cull/collapse and combine in the convergence phase to focus them for the prototype creation.

This idea of mass idea flow is not unsimilar to product feature ideation during product discovery. It should always be the goal of a product team to thinking about all the potential end user “wow” features or how they can present features in the best user experience. However, there is a dark side to all of this. You have to be able to do the same as a design sprint and cull the herd. It’s a necessity to explore and examine the potentiality of the product but it is also a real art to being able to refine the feature set down to a manageable level that maximizes impact, value and learning.

The challenge is typically not with the ideas but the skill in which those ideas are refined, combined and reduced to maximize time to market, customer joy and lay the groundwork upon which to continue to delight.

Less is More

Often as an agile leader, I am faced with the pressure of more “wants” than capacity ever allows. The worst thing I can possibly do is to say “Yes” to everything. What are the possible consequences of this posture?

  • I set a false expectation for delivery as I do not consider the capacity of what can actually be delivered.
  • I may compromise the quality of the work through a consideration of over-commitment resulting in additional rework, staff burnout or injured morale as a result of staff over alignment.
  • I remove the ability of my organization to pivot, persevere and re-adjust to organizational needs that emerge and respond as timely as possible.
  • I add the overhead of support as a hidden cost if the same staff are used for build and run operations.
  • I disallow myself the ability to continual nurturing of the culture by having horizons to focus on self learning and innovation outside of product delivery space and therefore stand to harm accepted cultural values of my group.

What my typical stance as a leader is to “do less better”. Does this mean I am unwilling or inflexible to the needs of the organization? Of course not. What I am unwilling to do is to place the health and potential damaging impact to my unit culture as a balancing point to accomplishing what is often just a “wish list”. I try and focus a view of being reasonable and responsible to my organization in terms of their needs which should also to be to keep a happy and healthy work culture intact so that capacity is not constantly in flux resulting in the overhead of onboarding and offboarding employees, morale reduction and taking away the value of the team making commitments to delivered work and respecting the commitments they make.

Many of you are reading this now and thinking “this guy works in a fairy world” but this is far from the actual case. I am a leader inside a large scale enterprise and experience the same pressures and demands as many of you. Where our thoughts may diverge is that I have to look at not only the bottom line of the enterprise but the health of staff and adherence to values to continue to be successful. It is not enough to “deliver cool stuff” if you work/life balance or work/life integration (moreso today) is overwhelmingly in the work category to an unhealthy level. The result will be a culture in which commitments become less valuable, end results become compromised and the health of your organization suffers.

Many startups have learned the harsh lesson that after the thrill of creation is done, all of the beer taps, ping pong tables, office hammocks and cool factor can wear off. These are unsustaining items of value. They are tangible things that people are enamored with as a “great environment” but later ask “is this why I stay here”? Not to say that your environment should not facilitate the best and most productive inducing experience but if that is the level of commitment by a company, this is usually seen through by software professionals over time. They look for something else. Cool challenges will keep them for a while but when the routine work sets in, what tangible things have you offered that make them want to stay?


But I am getting off track here. Basically this idea boils down to a belief that by not putting one’s organization in a state of over-commitment, you allow yourself to consistently wow your end customers with the things that you do produce.

When targeted your features, you build in the possibility of innovative thinking spikes in creative work and give support to failure and regrouping as an option. You make quality something that is baked in and not an afterthought.

So when you think about product features and organizational commitments and bloat, are you looking through the lens of YAGNI? What would happen if you did so?

Stay Agile!

Observations and Adjustments

“One must learn by doing the thing, for though you think you know it-you have no certainty, until you try.” – Sophocles

I always thought this was an interesting quote. You cannot gain any certainty without trying … something. And even at that, you may actually fail. But if you are truly learning, you adapt and adjust and give the next experiment a fair shake of success.

From software to science, using experiential learning as a way to define an experiment, to conduct and observe the outcome to potentially learn and adapt the experiment as needed has created amazing products and scientific breakthroughs.  It works. I think we can all agree on this.

So, why do you think we don’t apply it to something like organizations?

Fear of Failure

Thomas Edison is quoted to have said “I have not failed, I have just found 100,000 ways it will not work” in relation to his research into the first lightbulb. This is a very healthy way to look at progress but very contrary to a lot of business thought. Why do you think that is? My speculation, which could be very wrong, is that for Edison there was the possibility of the realization of a dream forged from that creative spark with future potential of a product. For many businesses, the future capital earnings heavily outweigh the creation of “the thing”. Many of the successes in the world have been born from the want to capture an idea and then only become monetized later therefore reducing the fear that capital is burnt without return.

Often times, creators of these eureka products (Google and Facebook as a couple of examples) are often shaken by the idea of monetization as the creation was the core driving factor, not the end profit result.

I honestly feel that the initial introduction of the drive to capital gain often induces this fear and it creates a trickle down effect from the very top all the way to the source of creation of the product. The pressure to get to market first and capitalize of the highest money stream may cause people to become less innovative, take less risks and instill a fear of product failure even before it hits the waters.

But I contend that keeping the horizon for learning at a “just enough” level not only helps you determine a better product but it can save money from building out full features that are often unused (see the pareto principle as applied to software features) or poorly received.

Minimal Viable Product

Eric Ries of the Lean Startup approach introduced this concept (I think it had rolled around for sometime but he is connected with the idea) as producing the smallest amount of the idea to learn from. Basically a seed of a product to gauge a posture to “pivot or persevere”.

One of the most noted examples of this approach is Dropbox. The initial MVP for this product was a marketing video explaining the product and how it would work. This was launched and an accompanying form was created so that potential customers could sign-up for future information about the product or provide feedback.

This allowed them to gauge interest to know if their investment into the product in which they saw high potential value showed a reaction by their potential market. This was actually one of the most brilliant approaches I had ever seen. They were actively working on the product and seeded their base features before completion to test the market space. Had they gotten a less than exciting response, they could have targeted marketing research and determined why or pivoted their approach in some way (either the campaign or the product work).

How did this help them in proceeding this way? It allowed them to learn about the interest of their potential market and gauge feedback from customers before launch so they could consider the feedback and potentially pivot with the market. If the feedback was a “lame duck” they could have abandoned the product altogether and pivoted towards a new direction. This allowed them the potential of failure much earlier. The potential magic of all product management after this stage is having that gut feel for how long you can ride this curiosity until the product must get to market. This is why really good product owners stand out.

Minimal Marketable (or Lovable) product

This is another concept introduced that we see extremely frequently in the market space of software and software services. Determining only those core level services or features that get buy-in to a product for more. This means that product vision has to be solid to get these to market and feedback and seeding of new features is sought to be cadenced regularly.

The initial iPhone release is a prime example of this approach. When initially released, the iPhone lacked many features that were present in many of the competition in the marketspace (MMS messaging, apps and the ability to copy and paste). But when released it became one of the fastest selling phones in the cell phone market (competing more closely with mass volume sales of game stations like the Play Station 3). Which it did seed was a phone level OS with an SDK for developers to build upon (even though there was no store in place yet for deployment or sales mechanism). These “missing features” allowed them to gauge the market reaction as they had faith in their initial MMP to ensure the importance of future features and to allow them space to ensure that they released the best quality updates with these features sought by customers.

They released a product that seeded a way for it to grow (the iOS Phone SDK), made it available to the developer community and focused on those features of differentiation that allowed them to not only contend with the market but even under strong criticism and scrutiny release the features not initially there in a thoughtful way consistent to their brand and end goals. They essentially “hooked their customers” through thoughtful and innovative design and a stellar responsive interface (far better than competitors) which allowed them to build the features that would build a community around the product. By making the Phone OS available, they even made it possible to “jailbreak” the phone and create some of the missing features which could allow them to gauge what potential customers seemed to be drawn to use. This allowed them to strive to introduce the right features at the right time and draw from the community at large to create a learning opportunity and pivot as needed.

The Design Sprint

Another recent approach to the idea of validated product learning is the Google Ventures Design Sprint . This idea distills the idea of rapid learning through a functioning (and often simulated) prototype to gauge immediate and rapid feedback from real potential customers for a idea over a short span of time. O’Relly Media has also written an excellent book on this approach which can be found here. The idea itself has been around for sometime and often attributed to be initially used at IDEO Design as early as 2009.

The idea divides the approach optimally into a 5 day approach which breaks down to one day focused on the following events:

  • Understand – Define and unpack the problem to solve (though interviews and research)
  • Diverge – Generation of ideas to solve the outlined problem (more is better, no wrong answers)
  • Converge – Determine which ideas or pieces of ideas will be pursued for testing
  • Prototype – Build a prototype of the solution that end users can actually play with and develop testing criteria to observe
  • Testing – Validate your assumptions through observation of user interaction with prototype and providing feedback

Here are a couple of real world examples of how this has been performed

Building a new Shopping Cart (IDEO, 2009)

Savioke – Building a Room Service Robot

This approach may not work for every scenario but as a tool in your toolbox for learning, this can be a rapid way to learn what resonates with your potential market and generate immediate feedback from real-world interaction.

So, where does that leave us?

In the vein of this blog being focused towards being about agile leadership, I wanted to explore this topic to hopefully inspire those leaders to truly see the value of a targeted small experiment from which you can gain quick knowledge about your potential product from which you can pivot, persevere or abandon. The key being that failure should always be an option but seen as a mechanism for learning and focus as opposed to use as something to vilify a bad approach.

I hope this will guide you to finding tools to help you target your search for knowledge or even better be inspired to create the next approach of which I blog about.

Fail fast and stay agile!

— Todd


How can I be Agile?

“The ones that are crazy enough to think they can change the world are the ones that do.” – Albert Einstein

My organization is changing and adapting. As a leader, I am being purposeful to make this happen. I have brought in 2 managers to focus on the “day to day operations” and to continue to perpetuate both our technical and cultural growth. This has allowed me to start thinking with much more depth and breadth about the organization while ensuring that the culture that has been built continues to receive the appropriate level of care and feeding so it can be nurtured to continue to grow. Many were shocked that I did not do this sooner but, again, as a leader, I wanted everyone from the most junior level employee to the most senior level employee to initially have no obstacles directly to me. This also meant based on the levels of time approvals, performance reviews and personal coaching that I was instilling into the culture the ability to be self-organizing and self-managing. It created a “top down” support culture as opposed to a “top down” decision culture. In doing this, I think the balance has been found very well inside the culture where people feel the autonomy of teams to make good decisions and accept the responsibility of those decisions.

My colleague (amazingly customer service oriented), who handles all of the operational aspects of the business has been trying to help his group find a balance of agility in how they operate. He does not have any real champions today who “get agility” and based on the needs of the culture in place (as operations is much more enriched in a process and procedure approach than a looser framework) they understand the need but have difficulty applying it to the work. I am hoping to be able to assist them in finding the balance for themselves.

The Context of Work

Early on, I really struggled with the idea that the operational group could not adapt to becoming more agile in their approaches. I almost felt that they were not even being open to it. They went to classes, etc but never seemed to embrace it. Then I finally got it. Leadership had been asking them to “become more agile” without ensuring (or assisting) that they even knew what that meant or even where to start.

The funny thing is that this realization really hit home with me when looking for some Sriracha sauce in my refrigerator. I looked into the fridge and couldn’t see it so, as I am want to do, I asked my wife where it was. She said it was right in the door to which I replied; “where? I can’t find it”. This usually results in her coming over and pointing out the bottle right in front of my face. To which I often say “if it were a snake it would have bitten me”. It was right in front of me, I knew what I wanted yet somehow I could not secure it. This made me think about the teams and what they really may think about what “being more agile” really meant. Maybe it was right in front of their face and they just needed someone to point it out to them (like my wife was kind enough to do for me).

I also realized that perhaps why they were struggling was based on the context of the work they do itself. I believe that it was Stephen Covey who talked about trying to find rocks and ask “is this it” when taking a moment to ask what kind of rock you needed may have made this task more efficient. So, I was guessing that they understood the concepts and goals but applying it to a work context that was less about creativity and more about consistency seemed like scaling Mt. Everest.

Eating the Elephant One Bite at a Time

Often times, our leadership team uses this phrase to talk about the decomposition of work. It has always seem to convey a universal understanding with us that it is easy to become overwhelmed by something too big but if decomposed into bite size pieces, it becomes more consumable. So, this is what I suspect I can use to approach this goal of operational agility.

When I first started, the deployment of software in my organization was a heavily document driven process with staging server folders and handoffs and low communication and high mistrust between development, operations and database that someone would do something that they should not do. So, in response to this; things were locked down in certain levels only to be touched by a master craftsman. This high speciality of skills meant that deployment became very dependent on 1-2 people with the knowledge and skills to deploy code to the production servers. This always struck me as a really bad plan. So this was one of the things I tackled first.

My first goal was to understand the concerns and needs of the involved groups.

Development wanted to get code to the stakeholder as quickly as possible and not have at to jump through hoops to have small changes made. (They wanted to control the development environment so they could be responsive).

Operations wanted consistency among server environments and guidance in what was needed to be changed in the environment to ensure that the changes did not create a supportability issue. They did not want people making server level changes without being involved. And they wanted documentation that clearly outlined the steps for deployment, the dependencies, etc.

Database was less complex. They wanted to to know if there was a precedence of order for their work in the deployment. Since they personally ran all database scripts, they would check them and ensure that they did not have a negative environmental impact.

So all of the needs and concerns were pretty much on the table to address. However, the idea of moving from a manual process to one of full automation was a large task (an elephant).

So, we started with asking operations to sit with development and if we did a build and deploy to the server share, what details would they need at that point. This allowed us to automated the code delivery mechanism and only leave manual the server deployment. Over time, we were able to work with operations to secure and work together to stand up a deployment server tool that would allow them to review the deployment, secure product owner approval via a workflow and then deploy the code and restart services at the push of a button (removing the expert dependency).

Taking this “one step at a time” approach helped us achieve higher agility and facilitated communication on both sides of the process to ensure we fully understood the needs that each group had and find a balance. Does that mean it’s done? Not by a long shot. We still have room to raise the bar but by using the core tenants of inspection and adaptation, we can retrospect on how the process works and further improve. As Mike Cohn is quoted to say “agility is not something you become, it is something you become more of” …

So what does this mean in my work context?

What this boils down to is often people focus to become textbook agile. They think it’s an application of process and procedure but they leave it devoid of the cultural shift. Take a moment (I often say this as I feel often we “do” but never take that necessary time to assess) and assess the pain points of a situation in terms of the agile principles and ask yourself the following questions:

  • How could this situation become improved through the increase in individuals and interactions? Are we relying on processes and tools as this mechanism to meet the need today? Often times taking away that face to face interaction loses the overall understanding of the need (ever had an argument over a text message thread?).
  • Are we “end goal focused” in terms of meeting the need in terms of the value of the solution?  Or are we in a “cover your ass-sets” mode that is overloaded to ensure people do not do the wrong thing? Have we allowed a historically bad situation to shape our overall approach?
  • Are we focused on collaboration as the primary way of working to create a solution and shared understanding? Have we developed a culture that is more focused on an end document than the quality of the solution? If we are using a document as a point of shared understanding, do we review it regularly to ensure that it continues to create that understanding and adjusts as needed?
  • Do we embrace the overall concept of change? Have we created mechanisms that attempt to stall or avoid change for the sake of being consistent? As painful as change is, it is a given. Things always shift.
  • Are we using fear as the driving mechanism for what we are trying to accomplish? Has our outlook been colored by a previously bad situation in which a given process was implemented in reaction to this. Any process that has been created in an attempt to ensure that “this will never happen again” is probably open to scrutiny. Given too many rigid constraints, people will work twice as hard to find ways to work around them through informal channels, relationship building and holes not yet discovered. Be open, honest and trustful to the end value and the people performing the action. Bad situations typically arise from lack of knowledge, general mistakes or incompetence. Those are all things that can be remedied. I have rarely found a situation in which someone intentionally set out to do something malicious in terms of the general process of work.


 So why did I take the time to think out loud about this?

This topic came to me as I have seen more and more people struggling with how to be “agile” in their approaches, especially when it comes outside of the context of software development (which has a lot of frameworks for guidance). I have seen managers try and apply kanban and lean and scrum in other functional work contexts without starting with the basic ideas of defining how they work, what the workflow is and with a lack of understanding to the underlying principles of agility.

Take a moment to read the agile manifesto and see how the meaning can be adjusted to better fit your work context, determine a purpose and end value proposition to the things you are striving to do and look at how you are working with wide open eyes. Include people, ask questions, understand needs of the end result and inspect and adapt within a regular horizon. Keep in mind that the cultural installation of agility allows you to adapt any process when things breakdown or in the face of shifting priorities, circumstances or needs.

Have a great week everyone and stay agile!







Ownership vs. Visibility

“You don’t currently have permission to access this folder” – Microsoft Windows

I spent some time yesterday running a coaching exercise with a group of product owners to help them start utilizing a regular retrospective to reflect on improvement as an individual product owner and as a team. I knew it would be challenging as the engagement of thi role often spans across an entire organization so it could be easy to slip from “continual improvement” of self and team to that of complaint and focus on all the pieces to which they interact. In the end, I think they did a great job to start taking a moment to allow for some self-reflection.

One thing I did try and make visible as we worked through areas of “doing well”, “needs improvement” and “abandon” was to reinforce the idea of a separation between ownership and visibility. The reason I thought this was necessary is that the items of time management and focus were identified across the group. So I asked them (after letting some debate occur at times) as they identified issues (as to keep it focused on individual and team improvement) 1 simple question:

“Is this something you can control or fix or is this something you seek to make visible”?

That surprised a lot of them initially I think, as their role itself is aligned at a very high level within our organization and they sit with the people both within the business and IT that are responsible for organizational level change. So they had never really even considered not being part of that organizational conversation in the “how things get done” on a broader scale. Plus when we identified the responsibilities of the role, it was clear that they feel highly aligned to bigger strategic goals as they sit in the forefront of items they identified. But they took to the idea well and really allowed it to help guide them along as they consider what they identified.

But this had me considering something broader, the idea of ownership vs visibility itself and the positive and negative consequences of both aspects.

Lack of Control

I don’t think that there is anyone that prefers to not control a situation and be subject to the end result. It’s not a comfortable feeling. For example, I know as a father that I have always struggled with the relationship and focus my daughter has with school. My viewpoint is that you need to take this seriously, work hard, make good grades so you can take advantage of this educational opportunity. So when she would tell me “I forgot to turn in an assignment” the dad lecture soon followed. But one day after sitting with my wife (who I often think helps me refocus) I realized, I cannot “own” her work or motivation. She has to attend the classes, she has to perform the work to the ability at which she is capable and she has to assume the responsibility to turn in the assignments. The control I have in this situation is ultimately limited. Sure, I was able to ground her for bad grades, take away privileges, etc but when it all boiled down to it, I could not go an “do” the work that she was being asked to do. I had more reactionary authority than prescriptive authority (or so I thought initially). What was definitely within my control was to make my expectations clear, indicate what would happen should she not meet them and follow through. So my span of control was to help her succeed which meant she and I had to ensure I had visibility to do so.

Can you see me now?

“What we need to do is “… How many people will catch themselves saying this today? I will if I pay enough attention. And then, how many things will we say that about in which we actually have no authority, input, responsibility or experience the consequences if it does not work out? Probably a lot of those “what we need to do” statements fall into this category. We all have opinions and often we all feel the comfort and the freedom to express them within a healthy organizational culture but what about when we express our opinion and hold onto it as more than an opinion? It’s input. We are helping you solve a problem, just listen to me! If we maintain this stance then we experience personal frustration when things do not unfold as we suggested or within our expectation of need. I’ve done it. And every single time I catch myself, I usually think “it’s really dumb for me to keep worrying about this as someone else has to implement it”.

What we are really seeking is visibility. I want you to know the pain point, the frustration, my idea, my suggestion. And that is fantastic. A culture that allows that open communication and transparency of thought is a fantastic place to be. But without separating it from the notion that other people may be responsible to make the decision and implement within the scope of a backlog of other items they have in place can end in personal frustration, lack of trust, a “time sink” of worry over the end result and a general idea that no one is listening. I get it. I have experienced it. I have felt this way too.


I used to work with a unix administrator who had a placard outside his office that read “Your emergency is not my priority”. I thought it was funny (and a little of a up yours type comment which amused me as a young tech). But as I worked beside him, I noticed that everyone that came to see him had a “critical issue”. I mean each and every issue was critical. And as I grew in the tech industry I realized that this often applied to features as well from stakeholders. I also observed it in my own life; why did I have to wait between 8-12 for the cable guy to arrive, did they not realize I needed my wireless network? Did they not hear me tell them that I worked in IT and needed service? Did they think this was providing good customer service.

I have grown quite a bit older and perhaps gained a bit more patience but even as recent as this weekend I had to catch myself and think “am I in control here of this outcome”? I recently went to a fast food restaurant drive up to get some dinner with my wife and the line was very long. Not only was the line long but we barely moved forward to get to the order area. I felt myself becoming frustrated based on the situation (and probably a need for some lunch). The longer I sat, the more frustrated I became. I began to ask myself questions in my head like:

  • “What is wrong with these people, do they not realize that we all are waiting to order”?
  • “They really should do something to be more efficient, this is ridiculous to wait this long”
  • “Are there enough people working today”?
  • “What is the problem here”?

But then like a weird sensation it hit me. You cannot control how rapidly they will serve you or how soon this line will move forward. You can control if you continue to sit and wait or choose something else for lunch. You can call the number on the door and make visible your bad experience. My span of control was to leave or move slowly forward and order the lunch I wanted and to make visible to the company my experience.

I had to let it go.  I had to allow the people responsible to solve how the restaurant was run address the problem. And, even more important, it might not be solved the next time I returned for lunch. I had to accept that. I had to embrace what my actual options could be and act on those and then allow myself to offload it to the owner of the solution.

My emergency of getting that lunch item was not their priority at the moment. I actually had no idea what might be impacting the delay in service. I could only speculate and complain about the experience, which actually did not solve anything. But I could make it visible so that someone who could solve it could do so.

You may be thinking about now, how does lunch frustrations and concerns about your daughter’s education translate to this idea in the broader context. These are just simple examples of where my initial thought of control created personal frustration, used up necessary time that I could have done something productive and allowed me to let my mind speculate on why the problem existed, offer potential solutions and not fully understanding where my span of control started and where it did not exist. These examples demonstrate how if I accepted the idea that I could make someone visible to the problem/need or expectation and extend trust of the people who owned the responsibility to solve it, I could be less frustrated, regain wasted time thinking I was solving everyone’s problems and focus on the actionable things I could do, like get a really good lunch at the end of a long wait and see my daughter turn her own grades around and attend her college graduation.

So today when you find yourself immediately thinking or saying “what we need to do is”, pause for a moment. Are you making visible a pain point/need/problem or improvement or are you mentally allowing yourself to assume ownership for this thing even if your span of control is the end result? Give yourself a moment to think about what you own and can solve yourself personally or within your team and make visible the items to others to give them ideas so that they can affect change. Be willing to be heard and allow someone to set priority and act. Communicate your need (sometimes we do have an emergency or time frame) but free up your own personal time and mental energy to solve everything. It led me to a really good hamburger and a college graduate at the end.

I’ll close with a quote I read this morning as I was thinking about this that seemed to frame this concept in a positive light: “When you let go you are creating space for something better”.