The essence of strategy is choosing what not to do.

- Michael E. Porter

It’s a good quote, but there’s a better one that cuts more to the heart of the matter:

No.

Attempting to say no and actually saying no are what many of us spend our lives doing.  When you often get in trouble, it’s because you said yes.

You said yes to a feature that turned out more complicated than you thought.  Now you’re working overtime to complete it.  What if you had said no?  How much would users care?

You said yes that you’d attend the meeting because someone asked you, but you learned nothing.  What work could you have done if you had said no?

The scenarios are endless.

No is the best response in many places, although sometimes the word no isn’t said at all.

I didn’t have time to write you a short letter, so I wrote you a long one instead.

- Attributed to Mark Twain, but there is debate about that.

What if you had said no to something else, so you had time to write that short letter?

Omit needless words.

- Strunk and White

Omit needless code.

- Kevlin Henney

Omit needless features

- Paraphrase of Steve Jobs.

The actually quote from Steve Jobs:

I know you have a thousand ideas for all the cool features iTunes could have.  So do we.  But we don’t want a thousand features. That would be ugly.  Innovation is not about saying yes to everything.  It’s about saying NO to all but the most crucial features.

- Steve Jobs

You hear this advice all the time.  If saying no is the way to go, then why  are we all so bad at it?

We’re like cats: the shiny new object always holds allure over the old and dull.  I can interest my cat with balls and bells, until the moment the laser pointer comes out.  The balls and bells are forgotten because the shiny non-catchable dot has appeared.

We’re all chasing laser pointers instead of balls and bells.  The ephemeral laser pointer promises a better future, whereas the balls and bells represent the solid here and now.

I recently tweeted this:

Let’s get something straight: no feature is ever “must have”.

Here are some of the replies:

Disagree.  Just need to understand context.

There are some features that are must-have, though not nearly as many as we think. I’m certainly guilty of this.

Both are a failure to say no.  We all fail to say no at times.  Think about this: what if we didn’t have that feature?  What’s the worst that happens?  Things stay as they are.  The world doesn’t end.

If you can’t say no, you end up thinking business software is messy and ugly.  Features accumulate and code spaghetties.  Technical debt piles on.  It’s a world of trouble, all of which results from not saying no.

Switching from business software to the personal, there’s a piece of advice oft repeated: follow your passion.

It’s clear by now where I’m going with this.  Follow your passion is another way of telling us to say no.  How do you follow your passion without saying no to everything else that might interfere?  If you don’t say no, you’ll find there’s little time left to say yes to what you want to do.

No is one of the simplest words in the English language.  It’s one of the first words that native English speakers learn to say.  Yet no is the hardest word in the English language to say to someone.

Knowing this, I challenge you: say no to someone and see what results.  Maybe saying no will become a habit for you.  As a result, the world will become a better place.

No

Moving recklessly leads to forgettable and bad experiences.   Functionality may be made available more quickly, but at what cost?  The interaction and interface, as well as the communication around the feature, have to be at least adequately completed, or else the new functionality will flop.

Customers remember bad experiences more readily than they remember good ones.  Bad experiences color perceptions of the company, which has ripple effects.  A customer becomes less likely to choose the company for business.  The company has also now created a greater barrier that they will have to overcome to win back the customer.  Not only does the company have to get their name back on the customer’s radar, they have to convince the customer that they will not have a repeat negative experience.  Easier said than done.

How is your company moving: quickly, or recklessly?

The Color of Recklessness

Transparency Kills Apathy

- Clay Johnson

While Clay’s quote is in relation to government transparency, it applies to all aspects of life, including business.  So often in business, management hides information from employees, when doing the opposite would be better.

Transparency allows everyone to see the inner workings and to invest themselves in the process.  It makes all motivations clear and allows workers to motivate themselves.  It fosters trust, not mistrust.

Is there a chance that being transparent might hurt?  Sure, if you’re being unfair.  Transparency might drive those away who don’t agree with you, but it will attract those who do.  Transparency will strengthen the team and morale.  Transparency will improve the final product.

Hiding information is easy.  Openning up is more difficult, but brings with it more rewards.

As Clay said, transparency kills apathy.

Transparency Kills Apathy

Teams with healthy idea life cycles are easy to spot: ideas flow between people easily and in large volumes.

Teams that innovate are great places for ideas to live – like happy pets, they’re treated well, get lots of attention, and are shared among people who care deeply about them.

The life of ideas is the responsibility of whoever is in charge.  He defines it by his responses and behavior, especially when he’s challenged by someone else’s ideas.

Teams with scorched deserts where creative jungles should be usually have the manager to blame.

– Selected quotes from pages 101-102, The Myths of Innovation: Chapter 7; Your boss knows more about innovation than you

Here’s another quote, that I’m sure you’ve heard: If you don’t have time to do it right, when will you have time to do it over?

Companies these days claim they want innovation.  IBM jumps to mind because of their commercials.  I’m reminded of the one of the guy in the super hero suit who runs around talking about ideation.  Unfortunately, this often doesn’t seem to be far from the truth.  Innovation is expected to happen at the snap of a finger, or during an hour long brainstorming meeting.

If innovation happens this way, how come our best ideas often come to us after we’ve slept on it or when we’re in the shower?

Companies don’t want to put in the time to do it right, so they’re often failing and hoping they have the time to do it over.

Innovation takes cultivation.  It doesn’t come overnight, it comes from a sustained culture that welcomes ideas.  It is that simple.  The more ideas, the more likely someone is going to find the magical combination that leads to the next great thing.

A corollary is that you can’t have innovation without experimentation.  I may offer you all the great ideas in the world, but if you never let me act on them, why am I going to keep offering up ideas?  You don’t have to indulge every idea I have.  I just need the occasional chance to explore further.  It doesn’t have to result in a final product or even a prototype.  It just needs to be enough exploration to see if the idea is viable.  That little show of confidence, that you have faith in me to let me pursue an idea for a bit, is enough to keep my intrinsic motivation charged, so I’ll keep suggesting ideas.

If you want innovation from me, treat me like a child. Let me play. It doesn’t have to be every day, or every week.  However, if you let me play, I’ll invent things you didn’t imagine, and we’ll be the richer for it.

For Innovation, Treat Me Like A Child

What are the implications of a culture like this?  For one, it means everything has to be open.  All communication.  The fiefdoms that frequently come up in corporations couldn’t be allowed to exist, because as soon as they did, the culture would be destroyed.

More interesting though is that in such a culture everyone would have to be accountable.  No one could hide behind empty words or blame someone else.  Each person would be responsible for their failures as well as any team failures.  It brings to mind the motto of the Three Musketeers: “One for all, and all for one”.

Taken to it’s logical conclusion, what does accountability in a culture of trust mean?  It means that at any time if someone betrays the collective trust or avoids accountability they should be fired.

They should be fired.

Think about that.  I think everyone of us is used to feeling that we have job security.  Even if we slack off and perform poorly, it usually takes an act of God to get fired.  In a corporation that had a true culture of trust, this wouldn’t be the case.  There would be a revolving door as new people who failed to grasp the culture where let go.

However, those who embrace trust and accountability would have great job security.  They’re an asset to the corporation, so there’s no need to let them go.

Do any cultures like this exist today?  I suspect Google might be close, but I’m sure even they have their problems.  I agree with Scott Berkun that we suck at holding people accountable.  No one wants to be left as the person blamed for a failure.  In a culture of trust, having a failure on your resume wouldn’t be seen as an evil, so long as you accepted the failure and understood why it occurred.

Are we ready for this kind of culture?  Everyone’s knee jerk reaction is to say yes, but reconsider for a minute.  To be placed in such a culture would be stressful.  I’m not sure if people are ready to give up the stability of today’s general management structure for the more volatile one of a culture of trust.

A culture of trust would lead to more innovation and greater creativity; the rewards would be great.  It would rock if corporations made the switch.

Does any one know of a company that already has such a culture?  What other implications are there to a culture of trust?

A Culture of Trust

For example, the other night I cooked Tuscan ravioli stew for my wife and myself.  Dinner was fun.  I imagined that the ravioli were flying saucers and referenced the movie Close Encounters of the Third Kind, which had been playing on TV earlier.  It made my wife laugh and made me smile.  I’m sure if we had children they would have enjoyed it too.

Strange?  Perhaps, although I doubt I’m the only one who does things like this.  Everyone has their quirks.  Mine is that I love to imagine, all the time, even at times when it seems silly.  I’m lucky in that my wife loves this about me and lets me do it.  I’m looking forward to the day I have a child and can share this fun with them.

If you’re my manager, do you know this about me?  Do you know that I love work that’s creative and challenging?  If you give me a task that I don’t know the answer to, that isn’t rote, that isn’t menial, I’ll let my imagination work until I have an answer.

If you’re my manger and you don’t know this about me, how are you going to figure this out?  How are you going to determine what makes me tick, what motivates me?  How are you going to make sure that I’m not just an average programmer but a great developer?

I don’t want to make ravioli.  I want to make space ships.  How are you going to help me do this, help me to blast some pasta into space or to take a program from an idea to a perfect implementation?

The Things You Don’t See

Management and Twitter face the same scaling problems.

This thought is directly related to agile practices.  We’ve all known the traditional management style, the command hierarchy, where everything flows from the top down, with lateral communication only happening at equal levels on the tree.

This style fits with waterfall development nicely.  However, given the rise of agile, the communication structure has changed.

Instead of one way communication, communication now flows along a continuous loop.  Each person, instead of reporting to one node in the system, now reports to multiple nodes.  Each person may still only report to one node explicitly, but implicitly, for the system to work, each person must report to each other.

The total system depends on the free flow of information and the flexibility of each node.

Think of this in terms of Twitter.  If you’ve followed the news about (or used) Twitter, you know there was a time when Twitter seemed to fail almost every other day.  Eran Hammer-Lahav wrote an excellent series of posts on the challenges facing Twitter.  Eran points out that what Twitter is attempting to do isn’t a problem that has been solved before: how do you give updates to one person about multiple people that all operate independently?

Let’s make that a little less abstract.  I want to know what my friends are up to, so I log onto Twitter.  Now Twitter has to find all the most recent updates on my friends.  But how does it do this?  It has to query each of the people I follow, finding all the recent updates for each person, and then determine which of those are the most recent overall and should be displayed.  It ends up being a very expensive query.  Now factor in database sharding on the back end and everything goes to hell in a hand basket pretty quickly.

As Eran notes:

“Current database and caching solutions are simply unable to handle a complex network of multiple relationship [sic] between objects.”

So it goes with management.

Agile is a system with multiple independent nodes that are expected to report information to each other while fluidly adapting to the situation at hand.  It’s an expensive human query, the same type faced by Twitter on a technical level.

The solution to scaling agile beyond relatively small teams hasn’t been found, especially when multiple managers are involved.  This is why so many companies claim to be agile but then fail to implement truly agile processes.  The cost of implementing agile processes in a large organization are expensive and scaling agile goes against what the current management paradigm has been optimized for.  Until the solution to scaling agile is found and disseminated throughout the industry, management is going to continue to give lip service to agile while experiencing its own fail whale.

That’s how it always is with something new.

I’d like to thank John for creating the images used in this post.

Management’s Fail Whale

My answer is this:

To put the right people in place with the necessary resources to lead the company.

If a restructuring takes place and that doesn’t happen, all you’ve done is make a feel good move.  If after a restructuring the same people are still leading the same people but with slightly different department names, then the chance for long term change is not great.  After a short time, the good feelings will wear off, and since nothing fundamentally changed, the status quo will continue.

It’s akin to holding lots of meetings to feel like you’re making progress.

While a restructuring might make sense, it isn’t the answer.  The answer is going to come from people and their willingness to carry out change.

Purpose of Restructuring

The argument goes that open is good, because then everyone can communicate easier.  I agree that this is true, but at the same time it leads to easier distraction, leading to increased context switching and loss of productivity.  In this regard, I agree with Joel on the subject.  Does the increased communication offset the lose of productivity due to context switching?  I would argue no.  Even Bob Martin, a signer of the Agile Manifesto, while he advocates for an open setting, qualifies his advocacy by saying that developers also need a quiet place to retreat to to complete work without distraction.

Science backs up the fact that as humans, we need privacy to work effectively.  Recently I came across this article: Tough Choices: How Making Decisions Tires Your Brain.  What I extrapolate from it is that for each context switch a developer faces in a day, their brain tires a bit and their work suffers.

I’ll let the article speak for itself:

Why is making a determination so taxing? Evidence implicates two important components: commitment and tradeoff resolution. The first is predicated on the notion that committing to a given course requires switching from a state of deliberation to one of implementation. In other words, you have to make a transition from thinking about options to actually following through on a decision. This switch, according to Vohs, requires executive resources. In a parallel investigation, Yale University professor Nathan Novemsky and his colleagues suggest that the mere act of resolving tradeoffs may be depleting. For example, in one study, the scientists show that people who had to rate the attractiveness of different options were much less depleted than those who had to actually make choices between the very same options.

So let developers have some privacy to go along with agile development practices.  A little bit of both will lead to productivity gains.  The science doesn’t lie.

Why Programmers Need Privacy

That’s my take from Steve McConnell’s latest post and I completely agree with him.

Being Agile