I’ve said recently that your opinion doesn’t matter and now I’m going to add insult to injury. Not only does your opinion not matter but your ideas don’t matter either. If you think that you’re just one great idea away from becoming a tech-legend, think again. There are two reason for my statements. The first is simultaneous discovery and the second is non-disclosure agreements.

As I’ve written before about simultaneous discovery, it happens all the time. Perhaps the earliest example is farming. Sometime around the Neolithic Age (New Stone Age) about 10,000 years ago, humans separately invented farming at least three times and possibly as many as seven times. Different civilizations from Eastern Mediterranean to China to Mexico all came up with the idea of farming, presumably without sharing this knowledge in any way. More recent examples include, in 1611 the discovery of sun spots at least four different times, in 1869 both Cros and du Hauron invented color photography, and Bell, Gray, and la Cour just to name a few invented the phone at nearly the exact same time. The list of simultaneous discoveries or inventions is so extensive that William F. Ogburn and Dorothy Thomas documented over 148 of them in 1922. The likely cause of this is that inventions are built on top of other inventions which makes them “ripe” for discovery by anyone with that combination of information.

Regarding non-disclosure agreements and how they prove that your idea doesn’t matter. If you’ve ever pitched your idea to a VC you know that they don’t sign NDAs before they hear your idea. There are several reasons for this, many documented well in this post. I would sum it up into three major reasons. The first is that they are likely to hear the same (or similar) idea from several teams. Second, VC’s know that the idea doesn’t matter nearly as much as the execution of the idea. And, the third reason is that no idea stands the test of interaction with the customer, meaning if your company succeeds it is likely going to be with some offshoot idea and not the original one.

So, if your idea doesn’t matter and your opinion doesn’t matter…what does? Execution matters. That you can build a great team, provide them leadership, establish a culture of learning and deliver products to customers all matter. Don’t wait for the perfect idea. Pick an interesting problem that needs to be solved and get the solution into the hands of your customers quickly in order to learn.

Having discussed why organizations arranged along functional boundaries (e.g. production or engineering, operations, infrastructure, QA, etc) and multi-disciplinary Agile teams are often at odds and counterproductive, we now propose a method of organizing product teams more aligned with the Agile process and Agile methods.

The potential solution is really very simple.  The design goals behind the solution are: maximization of individual capabilities of any given team to quickly and efficiently create solutions and solve problems; creation of ownership of individual products (or portions of products) and the business success metrics associated with that product in order to maximize innovation; maximization of morale through a sense of ownership and delegation of decision making; and reduction in time to market through the elimination of non-value added conflict.

The solution is clear given these goals – eliminate functional organizations and align the organization to architecture specific services.   In the ideal case, each of the senior leaders of these organizations are capable of owning and leading one more complete agile teams.   The number of teams that an executive has is likely going to depend on the size of the company, the size of the engineering and product teams and the number of discrete services in the company’s product architecture.

Here we come to a very important point – it is critically important that the architecture, the process and the organization structure be aligned to reap the benefits of such a change.  If the product architecture continues to be monolithic, nothing is solved.  The solution described above will get you no further than an “agile overlay across functional organizations”.  Each division of agile teams needs to own their own services so that disputes, problems and opportunities can be resolved or capitalized within the team.  This rapid resolution starts to slow down when outside resources are necessary to resolve a problem or capitalize on an opportunity.

We readily admit that this new approach to eliminating functional organizations in favor of agile teams isn’t for everyone.  Some companies don’t have the need to segment their architectures into services as they aren’t experiencing rapid growth.  As such, they shouldn’t pay the price of re-architecting their product.  Some companies deliver to very clearly defined specifications and as a result can’t really benefit from the product discovery aspects inherent to Agile or the questionable “final dates”.  These companies are probably better off continuing to develop in a waterfall fashion.  Many companies won’t have the right skill sets at the top to have former functional executives own product sections.

This last issue sets up a topic for another post.  The question we aim to answer is “What are the qualities and attributes of the Agile Executive?”

We’ve done a lot of work with organizations attempting to become more Agile by implementing Agile development practices.  One common problem we see time and time again is that the “old school” way of defining organization structure starts to lose its value in an Agile world.  Here I am specifically talking about organization structures developed around functional roles such as development (or engineering), QA, Operations, Infrastructure, etc.

This old method of organizing, which resembles a Y axis split within the AKF scale cube served our industry well for a long time.  And, for many organizations, it can continue to work well.  It particularly works well in organizations that follow waterfall models as the organization structure mimics the flow and passage of work through certain gates.  The structure is also comforting in its familiarity as most long tenured managers and individual contributors have worked within similarly structured organizations their entire professional careers.

But in the Agile world, this organization structure doesn’t add as much value as in the Waterfall world.  In fact, I argue that it’s counter-productive in many ways.  The first and perhaps most benign issue is that the actual structure of the organization does not foster work-flow.  Unlike waterfall development where one group hands off a project to another in phases (development to QA, QA to operations, etc), Agile methods seek to develop and deploy seamlessly.  To be successful the Agile team needs representation from multiple stakeholders within functional groups.  As individuals now spend most of their time in cross functional teams, what value does the functional group offer?  In essence, these functional organizations become the analog to the “home room” in school.

The next problem is the inherent conflict created between the Agile team and the functional organization.  To be truly effective, the team must be empowered to some degree.  What power or responsibility does the functional leader then have?  If he or she isn’t responsible for a specific product, are they to be given some sort of veto power?  Such a notion has meaning in the waterfall world but really runs counter to the time to market and discovery objectives of Agile methods.  The resulting affective conflict simply doesn’t add value to the overall product.  In fact, as research shows, it destroys value.  Some proponents of continuing with functional organizations might indicate that the functional groups allow for more effective management and mentoring of individuals within their domain.  Given how little time managers truly spend on mentoring relative to other tasks, I highly doubt this is the case for most organizations.  Our experience is that the functional groups spend more time arguing over ownership of certain decisions (affective conflict) rather than mentoring, training and evaluating individual contributors.

Perhaps the largest problem – larger than the lack of support for work flow and the creation of conflict – is that implementing agile processes across functional organizations sub-optimizes innovation.  Research indicates that innovation happens most frequently and beneficially within groups of individuals with diverse and non-overlapping experience across a number of domains (functional and experiential diversity) and with non-redundant links to individuals outside of their organization.  By engaging in beneficial debate (cognitive conflict) on approaches to a certain problem or opportunity, the perspective and networks brought by each person widens the potential solution set.  Alas, this is the true unheralded value of agile development teams that properly incorporate multiple disciplines within the team (QA, dev, product, infrastructure).  Each of these individuals not only brings new and valuable expertise in how to develop a product, they also have contacts outside the organization unlikely to be matched by each of their peers.  Innovation quality and frequency therefore increases.  But the inherent conflict in multiple competing organizational affiliations will dampen this innovation.  So not only is there conflict and a lack of workflow, the potential major benefit is removed or at the very least diminished.

Having discussed the problems inherent to functional organizations and agile processes, we’ll next discuss how a company might “organize” around agile to be more effective.

The Paleolithic Era (Old Stone Age) lasted roughly from 2.5M to 10,000 years ago. During this time humans moved around in small bands as hunter/gatherers. Sometime around the Neolithic Age (New Stone Age) humans invented or discovered farming. While turning unedible crops like wheat into food is impressive, what’s even more impressive is that humans separately invented farming at least three times and possibly as many as seven times. Different civilizations from Eastern Mediterranean to China to Mexico all came up with the idea of farming, presumably without sharing this knowledge in any way.

While the discovery of farming might seem an evolutionary necessity for long term survival the coincidental simultaneous invention by disparate individuals is apparently not uncommon at all.  In 1611, sun spots were discovered at least four different times, in 1869 both Cros and du Hauron invented color photography, and one that you might be more familiar with the invention of the phone by Bell, Gray, and la Cour to name a few of the individuals involved.  Napier and Briggs are credited with logarithms but Burgi also invented them a few years earlier.  Another popular one is the theory of natural selection being developed independently but simultaneously by Wallace and Darwin. There are so many of these simultaneous discoveries or inventions that William F. Ogburn and Dorothy Thomas published a paper “Are Inventions Inevitable? A Note on Social Evolution” in 1922 that documented 148 of these simultaneous discoveries.

No one is really sure why this happens. Some believe in a sort of efficient-market hypothesis, which in financial markets means that information is ubiquitous and therefore you cannot consistently beat the market because everyone knows the same information almost simultaneously. Ogburn and Thomas postulated in their paper that because there are very few completely new discoveries, most inventions are inevitable.  Inventions are built on top of other inventions such as the steam boat being dependent on boats and steam engines being invented prior.

While a curiosity, you’re probably wondering how this applies to hyper growth startups. The key takeaway is that while you’re coming up with a great idea so is everyone else. The ability to iterate quickly on ideas is more critical than ever. Combine this absolute need for quick iterations with the requirement for measuring results of effort, lest it be completely wasted and you have A/B testing on features that are launched in weekly sprints. SaaS companies have no excuse for not releasing in very short sprints (if not continuously), watching user behavior to learn what works and what doesn’t, then iterating again.

Despite the plethora of articles and books to the contrary, there are very few million dollar ideas, just million dollar executions of ideas. If investors are looking for key attributes about a team that make them more likely to succeed or not, I’d suggest looking for a team that can deliver quickly and knows the importance of measuring success.

When we build products we spend a great deal of time and effort thinking through how our customers will use them. From all this effort we believe that we full understand our customer and system interaction. The reality is often that we don’t know how customers will ultimately decide to interact with our system. An example of this is how social networking sites were originally intended for people to meet and interact. Soon after the launch of Friendster people began setting up accounts for their pets. This came to the attention of Friendster’s management and they began shutting down these “fake” accounts. This, as you can imagine, upset many of these individuals who thought their pets deserved to experience social networking but the point is that customers had decided to utilize the system in a very different manner than the company planned or even approved of.

The academic research that can be used to explain this phenomenon is adaptive structuration theory (AST), adopted by DeSanctis and Poole from Anthony Giddens’ theory of structuration. AST describes structures and agents, where there is a duality of structure  that exhibit an interplay between the structures inherent to advanced technologies and those that emerge in human action with these technologies. Orlikowski also extended Giddens’ work into technology by examining how people enact structures as they interact with a technology that affect their use.

Back to our example of pets having their own accounts on social networking sites. Customers are going to adapt their usage of our technology based on our product’s design as well as their interactions with the product. Our responsibility is not only to focus on the customer during the conceptualization, design, and development phases of our products but also in the maintenance phase. Take note of how the products are really being used by our customers in order to not only support their use but leverage it for further product refinement.

By now most of us have heard concepts such as the wisdom of crowds or A/B testing but still so often we make decisions without gathering data. Admittedly not every decision we make during our busy days requires data analysis but the ones that matter such as your product’s UI redesign, a price change, or advertisements often get the same treatment as your choice of lunch sandwiches. Perhaps you or someone on your team claims such connection with customers or product expertise as to not require testing. Don’t believe this!

Allow me to share with you an antecdote from my past that shows differently. Some of the facts of this story have been obfuscated to protect intellectual property but the gist of it remains true. The company that I was working with sold a product that allowed customers who purchased it to receive a return on their investment in a variable amount of time depending on how they configured the product. When getting up to speed on the product I asked everyone from the CEO to customer account managers, many who had been working with in this field for years, which was the optimal configuration. Everyone suggested a particular configuration. Being a bit of a stats geek from my days in Six Sigma I grabbed some data and started analyzing. The initial results shocked everyone because they indicated the exact opposite of the “optimal configuration”. After a complete A/B test the company ended up building a practice and product around the new ideal configuration, a big win for customers.

Ian Ayers in his book Super Crunchers offers several examples of random testing from companies as diverse as Monster.com to Capital One that have resulted in tens of millions of dollars of increased revenue. Companies such as Offermatica and Google offer A/B or even multivariate testing. Ian actually used this same techinque through online advertisements to determine the title of his book. Tim Ferriss in his book Four Hour Work Week did something very similar and recommends this approach to quick testing with advertisements for everything from business ideas to homepage redesigns.

While we caution against analysis paralysis there is a middle ground. Our mantra for processes is “Right Time, Right Process” meaning you need the process that fits best today for the your team and for the task. As we state in The Art of Scalability “Each and every process must be evaluated first for general fit within the organization in terms of its rigor or repeatability and then specifically for what steps are right for your particular team in terms of complexity.” The bottom line is, for decisions that matter get the necessary amount of data to make the best decision.

I’m a huge fan of Marty Cagan’s book and blog.  His most recent post on “The Domesticated Computer” got me thinking about how and why so many products not only take too long to develop but fall so short of user expectations.

I’m convinced that we have a nasty habit of attempting to launch products in all phases of development, and especially in the initial product launch, that simply do too much.  While we’ve all heard of the Pareto Principle, it seems that we just don’t apply it to our product development efforts.  Far too often we find ourselves in product discussions that look more like congressional pork barrel politics.  Features are negotiated based largely on executive pet projects than structured methodologies like Moore’s Whole Product Concept.

As Marty C points out, the personal computer, with all of its flexibility, is still difficult to use in many respects.  In the mid 90s I ran a project at Motorola that took computer keyboards off the manufacturing floor in favor of a yes/no device.  While the activities of the manufacturing line stayed largely the same, productivity increased.   Users indicated that the system was simply easier to use.  Nothing changed in terms of keystrokes – only one was still needed.  But less was better and faster.  More was fat and impotent.

Contrast the PC with purpose built systems like the iPhone, iPod, iPad, Kindle, etc.  The latter devices all have relatively limited primary input mechanisms.  Sure some of them have keyboards – but they aren’t the primary means of interaction.  More importantly these systems are designed to accomplish a subset of tasks as compared to the computer.  This limitation in functionality allows for better interaction characteristics and less user confusion.  It’s a lot easier to design easy to use systems if the system being designed only needs to flip pages and perform searches or scroll through and play music.  As my partner Mike Fisher points out, there are probably reasons why kitchen appliances still largely do one thing rather than a combined fridge/toaster/fryer/baker/washer.

But what lesson does this have for us in designing web applications?  Less functionality leads to less confusion, easier interaction development and faster time to market.  Develop the 20% of functionality that will deliver 80% of your revenue and refine it until its perfect using multivariate (or simpler A/B) testing.  Speed and focus is so much more important in web based properties, especially in early releases, than breadth and depth of functionality.  The folks at 37 Signals say that you can always do less.   Our point is not only that you can do less, but that you SHOULD do less.  Less is faster.  Less will allow you to get the core functionality out and perfected quickly.  Less wins.

Having just read Levitt and Dubner’s SuperFreakenomics as well as Tenner’s Why Things Bite Back, I’ve been thinking lately about unintended consequences, sometimes referred to as a “law of unintended consequences”. As defined by Rob Norton, it is “that actions of people – and especially of government – always have effects that are unanticipated or unintended.”  Norton sites the reference to unintended consequences to luminary economist and social scientist such as Adam Smith, in his “invisible hand” that self regulates markets, and John Locke, in his campaign against the 1692 legislation for limiting the maximum rate of interest that could be charged.

In Tenner’s book he covers a variety of topics including environmental, medical, and technology advances that have caused unintentionally problems. He uses the term “revenge” as in these advances have taken revenge on those who initiated them. What interested me was not the “revenge” but rather just our inability to predict accurately the outcome of our actions. All of the examples appear to be complex systems, meaning that the exhibit behavior not obvious from the properties of their individual parts. As much as we understand about the human body there is at least an equal amount that we do not understand. The same goes for our environment. Argue with me if you will but when the accuracy of a 7-day weather forecast is less than 50% (using the meteorologist standard of temp predictions within 3 degrees as accurate) or 85% accurate for precipitation 1 day out, it is hard believe that we have a great understanding of the earth’s climate and weather systems. Perhaps you can make a case that on a micro-scale we’re inept but from a macro-perspective we know what we are talking about.

When we add to our Software as a Service or Web 2.0 sites our human customers then I believe our systems start to take on attributes of complex systems. If we could accurately predict the human-computer interaction of our system then we would find all the bugs in our next release in QA. Unfortunately time and time again we learn of bugs or unintended consequences such as a huge drop off rate in sign-ups only after the release after it goes live and real people start interacting with it.

Why we fail at predicting human behavior or weather patterns or any number of other subjects is too broad for a post. However, with the knowledge that we will fail, we can take actions to minimize the impact of the results. The way to achieve this is through A/B testing or split-testing. If you approach changes in your releases as if you’re just as likely to reduce some desired behavior as you are to improve it, you’ll want to have a way to test the results in the real world before committing to them. In our practice we often tell clients that they should have an A/B testing framework or a wire-on/wire-off framework for a variety of reasons including risk mitigation for new features. In today’s world where there are free services that can help with this such as Google’s website optimizer, here is a great case study of how to use it, there really is no excuse for not having this ability within your site or service.

In a recent post Marty talked about false urgency being terrible for the performance, morale, and well being of a company. I’d like to add to this the wasted time, energy, and money on “initiatives”. Similar to how creating a false sense of urgency leaves the employees unmotivated and ridiculing the project, initiatives that do not support the mission of the company produce the same effect.

As an example of what I mean by “initiative” let me relate a project that was undertaken recently by a large corporation. In a cost reduction effort someone was assigned to walk around and patrol the office area for plugged in electronics and appliances. In my mind this is just ludicrous. First, the company has hired people they trust to build their product or systems.  If the company wants to initiate a cost reduction plan to reduce the electric bill, send a note out to the employees asking for their help. A much better approach is to demonstrate that you trust that they will help with reducing costs. Second, my bet is that the time wasted by this person patrolling the area, some manager monitoring and reviewing the patrols, and the other employees making fun of this cost the company more than it was able to reduce. And third, the company should weigh the cost of possibly having to replace a single great employee against the cost savings of such initiatives.

This example provided seems to be pushing to an extreme the silliness boundary of what someone can dream up under the guise of cost reduction but fails to interpret the further ramifications. Looking at just the balance sheet or income statement fails to take into account the wasted time by employees and aggravation over such imposed bureaucracy. Another clear sign to me of a company that is focused on the wrong things is when purchases must be performed through a centralized acquisitions organization. I understand and agree that there is no need for every department to negotiate a cell phone plan but when the IT department must involve a non-technical purchasing agent to whom they have to justify the purchase and allow that person to negotiate with the vendor, things have gone overboard. There is no reason that managers shouldn’t be given authorization for purchases up to various amounts and escalations going, not outside of their department, but just to their boss.

If you’re in an organization that has implemented these initiatives you should take the true pulse of the organization and see if you don’t come to the same conclusion. Working on these bureaucratic initiatives are likely costing you more in productivity, creativity, and deliverables than whatever amount you are saving.

We’ve all heard that saying “perception is reality” but do we really believe it applies to us? We all probably think we’re competent at our jobs but being so is only half the journey. We need to demonstrate that competency to our peers, employees, bosses, and customers in order for it to matter.

In good counseling sessions we should receive some praise for what we’ve done well and some feedback for areas that we need to improve. My advice to people receiving feedback is first determine if it is factual. Do you really write poor quality code? Are you actually tough to work with? If you believe the feedback is not factually correct, don’t become defensive and try to refute it because the blame is still yours! Even if the facts are incorrect but your peers, boss, or customers perceive them to be correct, you own this perception.

People usually hate to hear this and think they should just have to focus on their skills and everything will work out but the reality is that you need to own people’s perception of you. The same goes for customers. You cannot just focus on building a good product and assume customers will flock to you. You have to own your customers perceptions, which means you have to consider not only the quality of the product but how you introduce the product, how you roll out the code, how you perform maintenance on it. All of these ultimately result in your customer’s perception of the product, not just the number of bugs.