Evolving Web

Failure is an Option-Collaberwocky Episode 4

The Lean Startup movement has focused considerable energy in the message that we learn from failures. Small, easily recoverable, failures can be invaluable in the success of a company. However, many ignore failure and focus on success.

Since success is a rarity and failure much more common, we limit our learning opportunities by that success focus.

However, many also do not understand how the scientific process actually works. We therefore tend to build experiments that are invalid.

In Episode 4 of Collaberwocky, Corey Ladas, Jabe Bloom, and I discuss thoughtful failure.

Speaking from Power in an Uncertain World–Collaberwocky Episode 3

Are you a manager trying to get by in a flat or agile company?

Do you find the role of manager repeatedly maligned?

This is more than just “It’s lonely in the middle.” There are significant positive shifts in making the workplace more productive, efficient and effective. However, each of these shifts has been accompanied by changes in roles – and these changes are rarely clearly spelled out.

In Episode 3 of Collaberwocky, Jabe Bloom, Corey Ladas, and I discuss how to speak from power in this new uncertain world.

The Language of Management–Collaberwocky Episode 2

In this episode of Collaberwocky, Jabe Bloom, Corey Ladas and I discuss “The Language of Management.”

It seems that different rungs of the corporate ladder come with different perspectives. None are complete and all have their own biases and areas of focus.

Further, many management theories give rise to a sort of class warfare between the different rungs. “My manager doesn’t understand me.” “The C-Level suite are out of touch.” “The people who work for me are idiots.”

Far too often, this causes the rungs to appear so far apart that people cannot even fathom having productive conversations. Corey, Jabe and I mull over these issues.

We recommend you watch this video full screen.

Reading is (Still) Fundamental

 

I recently tweeted this after mulling over the differences I’ve seen while working with various clients. Some of them have practically been begging people to slow down, finish less with higher quality, and to take time out to read. Others are so scared that they don’t produce enough, that people are running in every direction trying to get something done, while finishing practically nothing, and learning even less than nothing in the process.

Of course, the first tweet I received in response was from JB Brown, at Nordstrom’s Innovation Lab. Since “Innovation” is well, what they do, they like to read a lot and… apparently…are fond of statistics:

To me, the benefits of giving teams the time to read is self-evident. But I thought I’d let the people actually giving their staff the time time to read speak for themselves.

Simon Marcus: COO of the Library Corporation

I encourage people to read at work for the same reason that I encourage them to write things down. Reading and writing give you time and room to think. Mostly at work people think they are supposed to be DOING ALL THE TIME. But if they aren't thinking, the result of all that doing can be a whole lot of nothing.

I love when I am reading and stumble on a word or a phrase that sends me spinning off into one of my own real world problems or opportunities. I love it even more when it happens to other people, but the long range value of reading at work is that it slows people down and makes them more thoughtful and intentional about their work.

Lastly, a word about why we encourage people to read AT work (instead of just expecting them to read on their own time). If I think that something is important enough to ask people to do it, I owe it to them to give them time to attend to it. This is part of the larger effort we make to respect people's time AT work. Reading is Work in Progress (WIP), just like everything else we ask people to do. We try to avoid making work WIP slip over into people's home life. All of that isn't to say that I don't love it when I find out that people have gotten the reading bug and are reading on their own time too. I find that the reading bug can be contagious. Eventually, about one out of three people who we encourage to read at work seem to start reading more on their own time. When I hear that someone who "never reads" has started reading, it makes me smile from ear to ear.

Jabe Bloom - CTO of the Library Corporation:

I have 2 general concepts for why reading is important at work.

1) Technical Knowledge is more valuable the earlier you can apply it. For many of my developers ensuring that they are constantly retooled is one my most critical tasks. Encouraging them to read helps them to maintain a “landscape” view of the technologies they are using so they have a better chance of “finding” the right tool at the right time. Exposing developers to a wide range of new and interesting thoughts is a good way to inoculate them against complacency and “I have a hammer-and-everything-is-a-nail-itus”.

2) I think.. more critically... Having an open environment at work where individuals can be SEEN reading, activates the social space as a learning environment.

More and more studies of cognitive science support a concept of ritualized changes in thinking patterns... transforming from one way of thinking to another.. I think that having people read at work, helps them to think in a “learning activated” mindset.

3) Encouraging employees to read AT WORK, sends a clear message that we EXPECT and VALUE learning in the work environment. Employees aren’t expected to keep up on changes to the industry on “their own time.”  Our encouragement of reading at work has seen an increase in;

1) Teams’ abilities to communicate internally and with other teams via shared vocabulary

2) Increase in individuals sharing learnings and source materials.

3) Decrease in defect rates, especially escaped defects.

Jason Montague, the Director for Application Development at RW Baird:

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

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

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

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

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

 

You Mean I Can’t Even Estimate? The Planning Fallacy in Action

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

We like to estimate things. “I’ll be there in 5 minutes!" “I will have that report to you in an hour!” “We can do the entire project in 24 days!”

Yet our estimates always make us nervous. They leave us ill-at-ease. We always know things won’t go exactly as we foresee, there will be things that should go right but don’t, there will be unexpected snafus. We know, the moment we create it, our estimate is wrong.

“Plans never survive contact with the enemy” – von Clausewitz

But we hold on to our estimation as necessary. We hold on to our plans as bibles. We hold on to contracts as … well … contracts. And we are surprised when things don’t go according to plan.

“Plans are useless, planning is indispensible.” – Eisenhower

We are running into two problems here. (1) There is variation is every activity and the world is sure to remind you of that. (2) The Planning Fallacy – which is a cognitive bias that shows that human beings tend to underestimate a given task even if they’ve done that task many times before.

The planning fallacy is one nasty little bugger. Already, we undervalue the role of variation in our work and believe we can ascribe one number to a particular task. Beyond that … we actually are predisposed to underestimate even that erroneous number.

Researchers have tested this many times and find a few things.

• People tend to underestimate their own completion times the most
• People tend to underestimate even more when others are present
• People can deliberately underestimate to garner favor or win contracts

These added together create some shaky ground when asking other people for an estimate of time. Some people glibly say, “Well, when they give me an estimate, I double it and that takes care of it.” But this doesn’t solve the core problem – people honestly did not know the variation in their work to begin with.

At a recent client, they compared their estimates to actual hours across a series of projects.  What they found was, if a task was estimated at one hour, there would be four times that estimate was correct, and three that it was not. The incorrect estimates would range between 2 and 6 hours.

For two hour tasks, it was similar. Three times they were correct, four times not – ranging between 3 and 9 hours.

Three hour tasks, a very similar spread.

When they visualized those tasks – they suddenly were able to see the variation in their work. And they were upset!

“We have to get rid of those major outliers,” they said.

But what they were really seeing was the variation in their work. The uncontrollable variation inherent in knowledge work that makes Hofstadter's Law a law and makes the Planning Fallacy a very common occurrence.

Understanding the variation statistically … that gives the team real power. With that they can choose any number of estimation strategies, based on real numbers with real spreads. There will never be one “right” number – because that is prediction and not estimation.

Combine this with Eisenhower’s advice, and we stop planning up front – when these errors and biases will be the most pronounced because of have the least information -and instead re-evaluate plans throughout a project. We make course corrections. We constantly re-adjust. So Hofstadter will still be right, but he’ll be less right than before.

Photo by Mr. Asthma Helper

Don’t Slow Down, Just Get It Done

My colleague and I were four days into a field exercise for an environmental impact statement or EIS. An EIS is a document every public project must complete to show what the short and long-term impacts would be if it were completed. They tend to be large and expensive. This particular project was very large and the impacts many.

Given that the project was underway and had a definite deadline, no one was willing to slow it down or change its scope. This particular task was supposed to take the two of us about a week to complete.

Four days into this particular task, we found the data we had been given was poor, the people to contact with better data were unavailable, and that the massaging of the new data we couldn’t even get would take weeks.

When we presented the managers of the project with this information, we were told Don’t Slow Down, Just Get It Done.

Get it done with what?

The data you already have.

We were then expressly told not to contact anyone else or extend this particular task.

Back then, we were completely confused as to why anyone would be so totally stupid. How could these managers knowingly ignore that we were using faulty information that would result in a useless report? These weren’t Dilbert characters, they were real live human beings.

Over the years I would watch other seemingly smart people drive their high-tech startups into the ground by insisting that an initial plan or idea go forward despite ample evidence that all that lie ahead was ruin.

What cognitive biases kicked-in to destroy these endeavors?

Irrational Escalation – This is in-for-a-penny-in-for-a-pound-ism. Once people start on a project, they find it very hard to stop – even if the project is obviously doomed or the return will not cover future costs. The managers felt that the project was already underway and even using bad data was better than delaying the project and asking for new data. The bad data (not surprisingly) later resulted in obviously flawed analysis – causing even more expensive and stressful work later in the project.

Expectation Bias – This is a world-view bias. If we believe something, we pick data points that support that expectation. Further, we expect that most data will support our expectations. We had an opportunity to create a research regimen that would yield scientific results. The managers assumed this was all a formality and that any data (good or bad) would support the original plan. This was likely underscored by “experience” that showed that most data did indeed support the original plans (which were likely suffering from expectation bias).

Planning Fallacy – A central issue here is simply that we didn’t have enough time to finish our task. The expectation bias inherent in the people who wrote the initial scope gave us only a week. This led to them, and us, falling prey to the Planning Fallacy which shows that human beings have a strong tendency to underestimate task completion times. On the ground, we saw this playing out. From the manager’s desk, the plan was correct, we were at fault.

Status Quo Bias – This bias says that once we start something, we tend to want it to continue. This is why in Collaborative Management we seek to build an explicit Culture of Continuous Improvement for teams and companies. Making change and improvement the center of the culture makes change the status quo. Needless to say, this wasn’t the case with my project back then.

The upshot here is that biases can gang up on us. Our enthusiasm, belief in ourselves, and assumption that things stay pretty much the same can combine to create seemingly logical decisions that can turn deadly. My managers no doubt reasoned that the project plan took over a year to write by well-informed professionals. There was very little cause for concern that a small part of the project might derail the whole thing.

In the end, our re-work was hardly noticed because other parts of the project became late, with much higher costs. One can only guess that the same forces were at work.

I Know It When I See It (Anchoring Bias)

“I shall not today attempt further to define the kinds of material I understand to be embraced within ["hard-core pornography"]; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that.”

— Justice Potter Stewart, concurring opinion in Jacobellis v. Ohio 378 U.S. 184 (1964), regarding possible obscenity in The Lovers

I’ve used this quote a lot lately in talks about quality and completeness. There are some things that are entirely contextual and, therefore, lend themselves to ambiguity. This is the way language works. Some (few perhaps) words are very concretely defined like “five” … “five” means when something is one more than four of some state. Five years old, five batteries, five muppets singing five people in my family.

For everything else, we have different degrees of ambiguity. The current ambiguity of the week might be what “guilty” means for Casey Anthony.

A lot of that ambiguity is driven by our past experiences, which make up our “world view”. Our world view is basically a filter by which we take in information and rapidly process it. Often, this is very easy and painless. Our more-than-likely-shared-world-view says a vacuum cleaner shaped object is probably a vacuum cleaner. This lack of variability makes vacuum cleaners fairly safe for discussion.

But what other topics like religion, elected officials, education, leadership styles, international relations, HR policies, health care, road improvements, anti-trust law, … and so on have attached to them are a passel of biases. Regardless of which of many possible sides of these issues we may personally be on, the existence of bias is apparent.

We don’t shut off our biases at work either. So, today I’d like to discuss a key bias (anchor bias) and explore how it might make things easier or harder for us at the office.

Easier? Yes, easier. Many biases we set up are the result of actively training our brains to respond quickly to certain situations. If we are working with a particular system and that system has three states (A, B and C) and we know that A requires response 1, B requires response 2, and C requires response 3 – we will start to watch for those three states and quickly respond to them.

Further, if we notice over time that B happens 70% of the time, C happens 23% of the time and A only happens 2% of the time, we’ll start to assume that B is going to usually happen, C will happen sometimes, and A is rare. We will then tool ourselves and our environment to suit mostly condition B.

We develop a cognitive bias about the outcomes from the machine.

How strongly we hold onto that bias is key. We can use it as a rule of thumb: “B happens a lot, so I’m going to prep myself for B. But if it changes, I’ll just adapt.” Or we can use it as something to anchor our processes to: “We’ve seen that B happens 70% of the time, so we are going to train everyone to expect B 70% of the time and develop policies and procedures around this 70% number. It has always been 70% and always will be.”

Harder. As we get closer to that second one, we approach what is called “Anchoring Bias.” We begin to rely on that 70% number and institutionalize policies around it. If that number happens to change, neither we nor our systems can easily adjust. The 70% figure has become part of our world view. A change in that number is now no longer merely a fluxuation, it becomes a major upheaval.

Some may call anchoring bias “sacred cows” – these concepts are central to the operations of your group. We will always have core beliefs that make up the mission of our organization. Missions, by default, need to have some type of world view – and moreover a clear and well-defined world-view. But the more we add to it, the more we run risk of unhealthy anchoring bias.

Photo by Lo van den Berg

Collaboration over Process

(This is the first in a Daily Thoughts series. I used to blog every day, but during the writing of the Personal Kanban book and creation of the Personal Kanban website, I fell out of practice. This is getting back to true blogging. Fast, unedited, perhaps a little more politically incorrect here and there.)

 

The agile manifesto said "Individuals and interactions over processes and tools".  For years, I did not question that principle.

Now, however, I would replace this with "Collaboration over process."  Here’s why:

What's happened with agile is that the rhetoric is so team empowering that it transforms teams into heroes. Like individual heroes, this divides them from the rest of the org. It turns them into inward focusing groups that are optimized for their own product and have a well constructed but ill-fitting interface into the rest of the organization. While it was team collaborative and was more collaborative with outside stakeholders, the rhetoric still focused on the teams.

But the teams are made up of individuals. And the team operates within an organization. And the team has outside resources. And the team has clients. There’s a lot going on with those outside interactions that need to be explicit.

I really took the Agile manifesto seriously. Like many, it was pinned on my office wall. I could bludgeon uncooperative employees or clients with it. I could wax eloquent about it. For me, finding its shortcomings was a painful and lengthy process. I slowly came to the realization that, as it had aged, Agile had codified, ossified, solidified into something you could easily do wrong and that was nearly impossible to do right. The words in the manifesto no longer represented what was happening in practice.

So, I began to strip away some of the trappings of over-loaded agile at my company. We replaced sprints with release cycles. We destroyed the product owner for a fully collaborative relationship with clients. When we started with kanban, it was game-on. In 2005, when we ran our first kanban driven project, we had a very different view of kanban - but even then visualization of flow almost immediately started to change how we worked.

Our process evolved rapidly during that project. At every standup people had a suggestion of how to make it better. There was a collaborative spirit not just for creating the software, but also for how the project was managed. We were no longer following a rule-book of best practices. We were building something that worked for that particular team building that particular software for that particular client.

In other words, the team had the freedom to truly optimize.

Don’t let anyone say you are doing a process “wrong" – find what your “right” is.

Image by @gavintech and shared by Venessa Miemis

 

 

 
--

Spechetti

When coders have crazy unreadable code its referred to as “spaghetti code.” Single strands of code are impossible to trace through the tangled masses coders can weave. When this happens, it becomes incredibly difficult to understand the original intent of the code, the order in which changes were made, and how to go about making things better. This creates something known as “technical debt”. As time goes on, the difficulty in interpreting the code makes it time consuming and expensive to expand upon or to fix bugs.

It strikes me that this is very similar to the specifications that I have seen through the years. At project conception, one person might sit down and write a spec. Between conception and the start of coding, any number of people might edit that spec, introducing, editing, or removing features from the project. As the project begins and progresses, the spec is altered even more. Change orders occur. Off-line detailed conversations are hastily added to the spec or worse yet, included as an addendum. Soon we have spechetti - a document that has been through the hands of many, with differing intents, reflecting dozens of unrecorded conversations.

Spechetti creates a type of “legal debt.” Teams are required to satisfy difficult-to-decipher legal code that can be easily interpreted differently by others. Conflicts grow as interpretations diverge. Interpretations diverge the more granular (and difficult to find) operational clarity is in the spec. This makes the product time consuming and expensive to finalize.

The goal for projects should therefore not be to create a comprehensive spec that can be argued about at completion, but to create a legal and management system that actually drives agreement, clarity, and good business decisions while the project is in-flight. To do this, emphasis is placed on contracting for operational imperatives and not implementation specifics.

Existing contracting mechanisms create legal debt as a matter of course. We need a new kind of collaborative, non-punitive contracting system that replaces mounting legal debt with a mechanism that actually creates social, creative, and business capital.

Well, that sounds easy doesn’t it?

Tune in next time for what will kick off a series on Agile Contracting.

Portfolio Careers / Portfolio Lives

My friend and microbusiness partner Jeremy is a well-rounded guy. He has a few consulting clients that give him the income he needs to get by and maybe a little more. But that doesn't take up all his time. In his spare time he's also dancer, and with his wife and a few friends is opening a Montessori school. But that doesn't take up all his time, so he worked with two other guys and myself to create iKan, the Personal Kanban iPhone app. But that doesn't take up all his time either, so he got together with a bunch of other guys and created Crowdmap an awesome shared mind mapping tool for the iPad.

So Jeremy is, as I said, my microbusiness partner. iKan is a microbusiness. The application has helped many people take their Personal Kanban with them when they are away from their home or office. But it's also only $4.99. With four partners, it would take a very long time for any of us to become wealthy from it.

But what I'm noticing is this: The new entrepeneurs the media  keeps touting are not out building companies with just sweat equity. That is nothing new and completely misses the point of the transformation that is taking place.

The previous career models of "I'm going to get a stable job and go to the office every day" or "I'm going to launch a startup and we're going to become huge and make millions" are increasingly viewed as the self-defeating, zero-sum games that they are. People are recognizing that full time-work is fleeting; that at-will employment means you have no job security. And hopping from job to job is stressful and forces you to give up all self-control.

Instead, people are collecting portfolio projects with residuals that, over time, will result in reliable income streams. This is a vital distinction, because when you have a huge time-sucking job with no hope of residuals, every hour you spend working is worth a set amount – regardless of how much effort you put in or how much value you create. 

This means that trade-offs between the rest of your life and work will always fall in favor of work. If your boss tells you to work until midnight during your daughter’s recital, you need to work. If you don’t, the zero-sum game means you lose disproportionately to the cost of the action. Going to the recital will always lose to not having a job and health insurance. But the action that night at work compared to your daughter’s recital? That individual trade off was likely in favor of your daughter.

Building a portfolio of microbusinesses with an underpinning of paid project work means you are building both good short and long term income opportunities. For a portfolio holder, the option of working that evening or spending quality time with your daughter will, appropriately, come down on the side of the daughter – and if it doesn’t, it will be because the trade-off was really worth it.

So Jeremy and others I know are placing themselves in a position where they can exercise life’s options with the least amount of external costs. This allows them to build not only a portfolio of projects they have worked on, but also greatly expands the portfolio of projects they can work on. In doing this, Jeremy and others have bought themselves a great deal of freedom.

The next time you think about work/life balance, consider this: have I placed myself in a position where I pay a penalty for choosing activities outside of work? Have I placed a tariff on my own happiness? Have I left myself unable to work on projects that will make me money, expand my capabilities, and provide an interesting challenge? How many of my options have I closed off?

The original image can be found here by TheAlieness GiselaGiardino²³