Ideas happen all the time.  Statistically, we'll hear some bad ones.  At least we think they're bad.  How can we best hear and react to these bad ideas?



## Ideas Have Value

First, a basic foundation for ideas:  Ideas come from people's thoughts.  People's ideas are the catalyst for innovation -- things to try, explore, and from which real progress can spring.  Progress is important.  People are even more important.  There is value in each.

## Hearing and Learning

Some ideas elicit a strong response from us.  Let's talk about the negative type of response.  Perhaps there's something in our background or perspective that may make us revile at just hearing certain ideas.  If we revile, the conversation will be over.  That one idea will die.  That may be what we want in the end.  But focusing on just the short term consequence of disposing of a bad idea may blind us to other side effects we may cause in immediately, strongly, or without tact opposing a bad idea.  

Let's explore some alternatives:  Listen.  Just take it in.  Keep your composure.  Don't even hint at your dislike of this idea.  Ask clarifying questions.  Ask about how this person got this idea.  Ask about how this idea and any implementations so far have helped them.  Here we're trying to get basic understanding, background information, and gathering any evidence of good that might exist.

Ask about any pitfalls they've experienced.  You don't have any specific lines of thinking at this point but are just inquiring generally.  Now ask about pitfalls that you see.  Don't state that these are fact.  Just ask if the person thinks these one or two pitfalls might apply.  Ask if there are any adjustments they'd make to the idea or implementation to account for these.  Here we're trying to expose in a non-threatening way the real drawbacks that may exist in the idea.

Now if you're feeling composed and generous enough, go a step further in your learning.  Congratulate them on the good things happening to them relative to this idea.  Then ask this person to describe how he thinks this idea might potentially be helpful to you.  Is it a generally useful idea?  Or in what contexts?  You may be surprised with some thoughts this person shares with you that you have not yet thought of.  You may be surprised at their generosity and desire to help you.

## Graceful Disagreement

Even after hearing and learning, you may be unmoved in your opinion.  Or maybe you want to give yourself time to consider what you've heard and learned.  But in the end, you don't have to accept what you think is a bad idea.  It's essential to realize that your hearing and learning do not imply your acceptance.  You are not forced to agree.  By listening you are not stating or even intimating that you agree.

You can give your own opinion or perspective on the idea.  You should be honest to the opinion you hold in your expression.  You also don't have to shove it in this person's face that you think the idea is terrible.  You may not mean to make your disagreement personal.  Do one better than that, and try not to let it be *perceived* as personal.

Remember that what you share as a counter-idea or fresh alternative is another idea in itself.  If you're down-voting an idea, it's good to have an alternative anyway.  You can state plainly that you'd rather not use this idea for you, your context, or your team.  State the specific pitfalls that you don't want to happen to you.  Remember that your relationship with people is more important than a problem to be solved or a task to be finished.  Keep the channels of collaboration and communication open.

The next time you hear an idea you think is bad: hear, learn, be graceful, be honest.

Is this hard for you sometimes?  What helps you avoid the initial bad reaction and inquire more honestly about what you're hearing?

The next time you hear an idea you think is bad: hear, learn, be graceful, be honest.

Hearing Bad Ideas

An estuary is where the sea meets the river.  Here, there is a mix of fresh water and salt water, sediment from the rivers and marine life from the sea.  The effects of both sea and river are seen in many ways.  It's a swirl -- there's no upstream or downstream.  It's considered to be one of the most nutrient-rich, productive ecosystems on the planet.  So really, who *wouldn't* want to make software in an estuary?



## The Traditional Production Flow

Here's a software production flow with disciplines and responsibilities represented:

1. Company leadership - develops a strategy and business model
2. Product management - identifies customers and products that could realize the business model
3. Design - visualizes information, interfaces, and flows for the product
4. Project management - manages a team in execution of production
5. Engineering - implements the design for the product
6. Quality assurance - verifies the correctness of the implementation
7. Operations - release and maintains the finished product

This is a simplified, constricted view -- a bit on purpose.  More or less, the traditional production flow is there.  It's very structured.  It feels like a factory assembly line.  I can imagine a lot of wall-throwing.  There are lots silos.  There's a lot of specialization.  The streams do not cross.  It does not feel like an estuary.

## No More Strangers, Upstream and Downstream

In the traditional production flow, there are specific orders and directions.  Arrows flow between neat boxes.  It might feel like a spotless production facility, clean and robotic.  It may even be really efficient.  But you likely have some uneasiness considering such a creative endeavor as software production being made in such an environment.

I think we should not think of ourselves as being in an upstream or downstream position, sitting somewhere in this traditional flow.  Rather, we are a full participant at any and all points.  We shouldn't think of our contributions in terms of our titles.  We should think of what we can offer of substance and then offer it.  In the estuary, things are messy, and we like it because of what we trust will be a better experience in the end.

It might be worth asking yourself if you really believe in the power of collaboration.  As in, are you really ready to participate in such a mix of people, ideas, and varied contributions?  It might be worth considering:

#### When previously downstream...

- Did it ever feel like you were expected to just do what you were told, completing your well-defined job on the assembly line?
- Did you ever lack an understanding of why you were making what you were being asked to make?

#### When downstream comes to the estuary...

- Do you feel comfortable deviating from and adjusting the plan?
- Are you ready to feel uncomfortable and contribute outside your wheelhouse?
- Are you ready to have your work critiqued and changed?

#### When previously upstream...

- Did you ever feel like you were the one mainly responsible for the thinking on the project?
- Did you ever feel like those downstream from you weren't being responsive enough to your ideas or instructions?
- Did you ever feel like you were in command and control mode all the time?

#### When upstream comes to the estuary...

- Are you ready for others to contribute to or push back on ideas that you create?
- Are you ready to relinquish some control on "your ideas"?
- Are you ready to stay engaged for the entirety of the project and care about the production experience end-to-end?

## Good People Required

Collaboration in the estuary isn't easy.  Work done here is done at a different level than work done on a pristine factory production floor.  It's more engaging, creative, demanding, evolving, and innovative.

Good people are required.  Self esteem from all is required.  Courage to potentially look stupid is required when you ask fundamental questions, question why, or challenge the status quo.  Courage to get something wrong means that you're contributing even if there's someone who might be "better" at a particular activity than you most of the time.  Humility is required to allow space for others to influence your work and defer to those who don't share your title or field of expertise.  Trust is required when others want to take part in something that you see as very important.

## The Medici Effect

The Medici Effect is named for the family living in Italy in the 14th century who had a great effect on the area and history.  They invited many experts from diverse disciplines and had the effect of making Florence, Italy a center of advancement and innovation, catapulting forward the Italian Renaissance.  The same effect of new and more ideas can be seen by us as we bring many disciplines together in a common cause.  What can we do to encourage our cross-functional teams really cross functions?

People have different tastes and exposures.  Associative thinking is making connections between different ideas.  Naturally, people of different backgrounds and trainings will be more able to make more and varied associations.  New, fun, and unusual combinations will result.

Steve Jobs often expressed that his passions lived at the intersection of the arts and technology.  That sounds like a cool estuary.  Now think of the intersection of the passions, knowledge, and abilities of entire teams really working together.

So swim in the estuary.  It's a great way to make software.  Don't think of your roles in terms of upstream and downstream disciplines.  You can have a rich, productive team and a better product by truly working together, not just being on the same team in name, location, or project.  Pay the price of the messiness of collaboration.  It's challenging, of course.  But who doesn't want to do great work with people of courage, humility, and trust?

Make software in the estuary, in a mix of disciplines, training, and collaboration

Make Software in the Estuary

The Agile method of software creation contains many principles of development that will help create good software.  Some of my most successful projects have had as a key feature an agile designer.  As Jobs said, design *is* how it works, and that means that to really deliver well in an agile environment, design *and* development have to be on the agile train together.



## K-man Keeps it Alive

I work with a fantastic designer, the one and only [Kendall Chadwick](http://www.composition3.com/).  He has many great qualities of an agile designer:

1. **He's available** - He lives with the cross-functional team.  He is there to participate in discussions.  It's not hard to get a hold of him, so answers to questions flow more freely.
2. **He listens** - He asks a lot of questions.  He's not stuffy about his design sense.  He realizes that many needs are represented in a project and product.  He attends discussion meetings not necessarily focused on design but on the details of the product or process.
3. **He's fully engaged** - He knows his task doesn't end when he clicks save in Photoshop.  He owns his designs and ideas all the way through the project, helping evolve them as we go. One of the most important things a software team member can do is remain fully engaged right up until the product ships.

## Agile Experience Design

I just finished a book called "[Agile Experience Design](http://www.amazon.com/Agile-Experience-Design-Designers-Continuous/dp/0321804813)" by Lindsay Ratcliffe and Marc McNeill.  I've read a fair bit on agile methods and currently live in a quasi-agile (hehe, let's actually call it mini-waterfalls) shop.  This book was intriguing as its authors are speaking to designers as they try to integrate better in an agile environment.

Of note was their Agile Design Manifesto:

Agile experience design is
Inclusive rather than elitist
Emergent with direction rather than up front
Integrated and collborative rather than handed over the fence
Considerate of customer, business, and technology needs rather than biased toward a single factor.

As a passing review:  The book won't provide too much that is new to someone familiar with agile.  It speaks in terms that I suppose are probably more well related to by designers.  It's a somewhat lengthy and dense book.  At times, it was hard to maintain reading momentum.  The book is beautiful -- perhaps it had some real designers laying it out?

## The Power of Design

It's amazing how much depends on solid design.  The design will define the users' experience with the software.  It will never not matter.  To a great design in a software product is a difficult thing.  Good people in the design discipline who are fully engaged in adapting to the changing landscape of software creation are invaluable.  Agile designers rock.  Find one and figure out how to get him on your project.

What have your best designers done to make great software on your teams?