The Black Liszt

The Dimension of Software Automation Breadth Examples

One of the major ways software evolves is by increasing along the dimension of automation breadth. A domain can be dominated by products at a given breadth of automation, and suddenly a existing or new competitor starts winning by increasing its breadth of automation, offering its customers more value for less effort and money. It's a classic move and a good way for new entrants to disrupt a market.

One of the most frequently given pieces of advice, including by me, is to “focus,” i.e. basically solve fewer problems, try to satisfy a narrower range of customers, etc. While this advice is applicable more often than not, the natural and recurring progression of products through the spectrum of “automation breadth” makes it clear that, sometimes, when the conditions are right, the winning strategy is to be among the first to increase the breadth of automation that you incorporate into your product.

Example: Athena Health

A clear example of this is shown by the story of AthenaHealth. At the time the founders started the company, a wide variety of products were already available to run physician offices, from small single-office practices to extended medical groups. These products generally ran on inexpensive machines that the practice would keep in some back room, and would support multiple users via a LAN or terminals. Most of the products were sold by license, so that the office had to pay only a modest price for the license, and then annual maintenance.

Along comes little Athenahealth, with a better way of doing things. Athena had a cool new practice management system (PMS). Unlike all PMS’s at the time, it was built using internet technologies, so that it could be operated as a service, with people at the office accessing the system using machines with browsers and internet connections. Athena took care of the computers, relieving the medical office of a burden it basically didn’t want.     

But they ran into a little problem: the people in charge of medical practices are doctors, and doctors really don’t care about PMS’s – they care about patients and medicine. A PMS is a necessary evil, something you should buy for as little as you can get away with and ignore until things get so bad you are forced to buy a new one. Money spent on the PMS is just money out of the doctors’ pockets, as far as they’re concerned. Oh, you have a “better” one, do you, whatever that means? Stop wasting my time.

The folks at Athena noticed that one little thing the PMS does is produce bills and claims, the purpose of which is to get patients and insurance companies to send them money. No claim, no money. Unfortunately, merely producing the claims rarely proves to be sufficient to get the money flowing. People are required to do special things to the claims, provide additional information, harass the payers, etc. This is so specialized and time-consuming that it either consumes the time of a number of people at the office, or is outsourced to a “billing service.”

The Athena folks went on to notice additional important things: (1) the chances of getting paid are a direct reflection of the quality and appropriateness of the information on the claim; (2) the PMS and how it is used is the main source of this information; (3) by actually performing the billing service, you can learn how to produce a better PMS that produces better claims, increasing the effectiveness of the billing service while reducing the cost of running it at the same time. Finally, they found out that there is something the doctors who run medical practices care about other than medicine – surprise, surprise, that something is money.

So Athena introduced an outsourced billing service, but required practices that use it to also use their practice management system – at no additional cost! And they got so good at collecting the money that doctors could essentially get more money and a really cool, state-of-the-art PMS (like they cared…) for free!

This is a nice story for Athena, but the point of telling it here is that it illustrates the principle of product automation breadth evolution. While products are evolving within a “level” of automation breadth (i.e., how many of an organization’s functions it automates), it is normally a good idea to maintain discipline, avoid distractions, and concentrate on automating that function. But at a certain point in the evolution of each product category, pretty much everyone in a space has automated everything within that function, and everyone is reduced to concentrating on sales strategies and niggling little details. At that point, and PMS’s were at that point when Athena came along, it makes sense to do what you’re normally supposed to avoid – look for another function inside the organization to automate, particularly if there are synergies in implementing the two functions within a single framework, as there certainly were in this case.

Example: Bank and Retail Credit Cards

In 1983 a small company called CCS (Credit Card Software, later called Paysys) released a body of COBOL code that would enable a bank to process credit cards. A number of small and regional banks bought copies of the code and ran it successfully. The code was enhanced over the years.

A major retailer, Michael's Jewelers, approached CCS and asked if they could make a version of the bank software that could handle purchases from their stores, including a variety of payment plans and financing options offered by the store that were not supported by bank card software.

The company's programmers quickly gave up on the idea of modifying the bank code to handle the problem. Many aspects of bank card processing, such as the difference between issuing and acquiring, were irrelevant to retail. In addition, the many financing options supported by retailers went far beyond anything banks did. So they borrowed from the bank code to the extent that it helped and ended up creating a separate body of software called Vision 21. Once it was available, it proved to be a big success in the market, and was quickly enhanced by customer demand to include all the options desired by retailers Before long it supported the needs of retailers in other countries as diverse as Japan and South Aftrica.

Finally, there was very large processor, Household International, that was running multiple copies of both products, separate because they had been customized for a variety of reasons, for example to support methods of credit that were unique to a market (for example “hire-purchase” in South Africa). While CCS, now called Paysys, had failed to create a generic bank/retail product when confronted with an example of the generic problem, unifying multiple bodies of related code into a single, highly parameterized code base proved to be a far more tractable problem, particularly with a single important customer who insisted that these variations were the only ones to worry about.

The industry quickly rallied to this new product, called Vision PLUS, that could be directed at so many different problems with such relative ease. For example, it enabled retailers to issue co-branded cards that worked like regular bank cards, except when used in the issuer's retail store, when it acted like a classic store card with features like "90 days same as cash" options that bank cards don't support. While “parameterized product” may sound like an abstract concept, it translates directly into business advantage compared to more primitive product types, by enabling the product to be customized, installed, upgraded and maintained with less labor, less time and lower risk of error.

The company that built Vision PLUS was bought by First Data, a major card processor. The reason is interesting: in spite of having thousands of programmers (Paysys had only dozens), First Data was unable to modify their US-centric code base to handle processing in Japan. At the time of the sale, Vision PLUS was processing about 150 million cards world-wide. The code lives on and currently runs over 600 million cards.

Conclusion

These are two examples of companies growing by broadening their focus -- in a strategic way, driven by just a couple of representative customers. In neither case did they address a whole new market at the beginning, though that was the eventual goal. They took their existing software along with a cooperative customer and met that customer's needs. Athena started with just one specialty in one state with a single payer. Paysys started with a single existing customer. In each case they grew the broadening of their focus a step at a time, making each customer happy as they went. As they grew, word got around in the industry, and they shifted to saying "no" to the vast majority of inquiries in order to maintain the step-wise customer success they were building.

This is a classic pattern of focus broadening that can bring transformative success to companies when handled well.

 

How to Pay Down Technical Debt

When we look at a body of software, how do we judge it? Clearly, there are strong opinions on this subject – but there is no general consensus on the standards by which a body of code should be judged! This is shocking and unacceptable!

For most normal people, i.e., people who aren’t software developers, software is “good” if is doesn’t crash and pretty much does what you want most of the time. What more could anyone want? Well, how about changing the software. This is one of the BIG things that makes software different from pretty much anything else in our experience. How often do you try to make changes to your car in the same sense that you change software? The answer is never.

There are standards for nearly everything in life, certainly for things that are built by engineers and other technical people. How is it that, not only are there NO standards for what constitutes “good” software, but the fact that there are no such standards is not decried, and no one appears to be sheepish or unapologetic about admitting it – because they’re never asked to admit it. The subject never comes up – not only in “polite company” but even in “impolite company,” i.e., among programmers talking quietly among themselves.

“Ya know,” someone might say, “we tell them there’s technical debt. Sounds fancy, right? Anyone ever been asked what it means? They seem to think that WE know what it means, and that’s good enough for them. I wonder how much longer we’re going to be able to get away with it?” Someone else says, “Forever, man. This has been going on since before we were BORN, ya know? Unless word somehow gets out, and how could it, we’ll die without anyone being the wiser. Good thing.”

I wish programmers did have quiet dialog among themselves like the one I made up above. But they don’t, at least that I’ve ever heard. There’s nearly always someone who has strong opinions about what software should look like internally, and of course the current body of software doesn’t measure up. So there is agitation and there are threats about the awful future consequences of failing to rein in the spreading disease – soon! RIGHT AWAY!! – unless the transformation is authorized.

Then the re-writing death march starts off, with various sections of the code slated for repair, renewal or even flat-out re-write. What is the target? It varies. Favorite criticisms include that the code is spaghetti, it’s a monolith, it’s not structured according to some set of object-oriented principles, it’s written in some obviously inferior language, there aren’t components, there are no services, micro or otherwise, and on and on. The solution is obvious to the converted, and value to be achieved by the solution is so obvious that it’s hardly worth stating.

Is there any value to be gained by the clean-up of “technical debt?” Maybe. But often, nothing really changes except a lot of time has been spent with no improvement to the business. No one can point to a proof or a study or a clear historic pattern demonstrating the effort is worth making.

This is a shame, because there is a clear pattern of success for a method of organizing and/or re-organizing code for business benefit.

Let’s start from the business benefit. Of all the ways a piece of software could be written that performs the same function, which is the best in business terms? I’m assuming here roughly the same level of performance, etc.

Tick, tick, tick… Think about it!

When you come right down to it, no one cares about today’s software doing today’s things for today’s customers – so long as it works and performs reasonably well. What matters is simple, and everyone knows it: it’s the next request by an important existing customer, and more important, the next potential customer who is balking about things they need that aren’t there, the time, cost and risk to implement the software, etc. In other words, what matters about today’s software is TOMORROW’s changes, whatever they may be – we can suspect, but we won’t know until we know them!

Software people have talked forever about things like “architecting for change” and various fantasies that mostly go poof when the harsh wind of reality rushes at them.

There are exactly two rarely-discussed aspects of code that position it optimally for the widest possible range of unanticipated changes and the needs of installation:

• A minimum of redundancy in the code – anything you want to change can be changed by going to one place
• To the largest extent possible, particular things the application does are defined in meta-data instead of code, with the result that the code is smaller and more abstract with minimal redundancy -- and that any change can more likely be made by changing meta-data, which is quicker and safer than changing code.
  

That’s it! See this for more.

How to Build Applications that can be Changed Quickly

Nearly everyone who talks about fast and reliable application building seems to talk about the process (Agile etc.) and/or a couple architectural things (object-oriented, micro-services, etc.). From what I can tell, these haven’t led to any break-throughs in application velocity or predictability. However, it’s clear that there are methods for high-velocity application growth. A wide variety of small, motivated groups have re-invented them over the years. I have had the privilege of observing these groups and their methods, and seen the impact when they add or drop velocity-aiding methods.

Here is an overview of some of the methods I’ve seen used. The improvements can range from cutting time in half to whole number factors, things like turning weeks into days or in some cases hours.

Forget requirements, focus on change

The normal requirements process starts with the often non-technical people who have a need. The need can be expressed directly, or through refusal to buy/use a product, which gets the attention of sales and marketing people. There then ensues a process of requirements gathering and refinement. Wire-frame UI’s may be involved. Finally, the requirements are ready for engineering, and away we go on hopefully not too many “sprints.” This is an “outside-in” approach.

Speed is achieved by taking an “inside-out” approach – instead of focusing almost exclusively on requirements, center your efforts on the code and what it can do or easily be changed to do today to go in the direction of the requirements. Take steps to change and add to the existing code to meet the unmet needs. Do this in small steps, getting feedback at each step. When you’re done, go back and “clean up” the code to eliminate redundancies as much as possible, to make the next change as easy as possible.

What this does is ground the changes in the existing code, resulting in the changes and additions being smaller than they otherwise would be. As a additional benefit, it usually results in a greater uniformity of both the code and the interfaces (UI and API) to the code.

Minimize the customization and optimization of the code and UI

When product people think about a new process that has UI, they usually try to do a good job, understanding all the details and nuances involved. The result of this sophistication is often requirements that are finely adapted to the particular function being performed. What’s wrong with this, you may wonder? One problem is that this approach ends up taking longer to built and results in more code. More important is the users – the less someone has to learn to use a new feature, the more quickly and easily they’ll be able to use it. Familiarity is incredibly important. Which means, among other things, that literally using rarely changing templates to generate interfaces will both make any new interface element recognizable and easy to learn, but also lead to the least amount of code changes to get the job done.

This means that the fineness and sophistication of product people can be a problem. The more time they spend on a subject and the more they think and reflect on it, the worse the temptation is likely to get to do something other than just crank out another instance of a familiar pattern.  Resist!

Avoid planning and designing for change and future requirements

When starting a project, accomplished software professionals often insist on a period devoted to design or architecture, in which the overall technical approach to the project is determined. When things go wrong later, inadequate or insufficient up-front design is often cited as the reason. “We’re gong to insist on being able to do it right next time, so this won’t happen again.” But all too often, projects slip and slide regardless of any up-front design work.

Generally, up-front design time is actually counter-productive. The reasons are simple: you spend time “designing” when you could have been building; the result of the design is often building for anticipated change, which takes time; when the anticipated change doesn’t happen and unanticipated change arrives, the code added because of the design almost always makes things harder.

None of this happens when you build incrementally and strive toward uniformity, eliminating code redundancies and moving functionality from code into meta-data.

Wartime software

The methods I have described as wartime software maximize speed and efficiency of building new software that meets business needs. See here for details. Generally, the methods include:

• Eliminate overhead
• Avoid things resembling “project management”
• Optimize for speed instead of expectations
• Use production environments for testing instead of sand boxes
• Use comparison QA; avoid test-driven development, unit testing and test scripts
• Minimize the use of documents, meetings and other internal overhead
• The main architectural value should be speed and scale
• Avoid technical fashions

Move up the mountain of abstraction

When you think about code and methods, the main values should be the elimination of redundancy in both data definitions and code, and migrating functionality from code into meta-data. See this and this.

The other methods described here are important for moving quickly, and are complementary to this one. But moving up Abstraction Mountain is the most powerful of the methods, often yielding qualitative improvements.

Conclusion

This is a short post, and the methods are described briefly. In a different world, each topic here would be at least a course in the Computer Science curriculum, and in a couple cases multiple books. I don't claim anything I've said here is fully described. But every single item has been proven in practice by many groups over many years, in different ways, always resulting in better quality software that meets business needs being built dramatically more quickly than other methods could possibly have achieved.

My goal here is simply to provide a short list of the main methods for fast development in a single place.

The Science of Innovation Success

Most of what you read about how to innovate and how to achieve success as an entrepreneur is irrelevant at best, and a cargo cult at worst. The real success patterns are not well known. They work. If you want to be seen by the world as doing the right thing, keep doing what "everyone" says you should do. But if you want to ... win ... you may want to consider learning from the patterns that actually work.

Patterns that work in health and fitness

Let's look at a clear winning pattern in health and see if it can be applied to learning how to innovate. (Hint: it can't.)

Sometimes you're struck down by an illness that no action of yours could have prevented. HOWEVER, there are proven patterns of behavior that greatly improve your health and resistance to disease, and related patterns that clearly result in your being able to run faster, jump higher and lift more weight. While the specific advice to achieve these things varies, the principles as understood by mainstream experts are largely valid.

It's pretty simple: eat a variety of mostly un-pre-packaged foods with a minimum of additives and things like fructose, and balance exercise and eating so that you maintain a moderate weight for your body type. For fitness, it's exercise and practice.

In addition to these common-sense patterns, there other things people do that make sense. If you see someone who has achieved what you want to achieve in terms of health and fitness, it makes sense to find out how they did it and emulate their actions. In addition, it's broadly known that motivation is a key factor, along with attitude and consistent behavior.

In other words, study what the fit, healthy people do, and do it yourself. Pretty simple, at least in concept.

Applying the Observe-and-Emulate Pattern to Innovation

Most things you learn or achieve, you are doing again or for yourself something that has already been done, typically by millions of people. That's what education is all about, for example. When you get educated, you are walking down a well-trod road. What about science education? Same thing. You have to learn the facts, the concepts, the math.

What about innovation? Is it just another thing you can get educated in and learn from the teachers, who learn from the experts? No! Innovation is different. Innovation is some combination of creation, discovery and adapting. It's being the first. It's creating something that wasn't there before. It's taking something that worked in a particular time and place, and making the substantial changes required to work in entirely new circumstances.

Imagine taking a course in exploring new lands in Europe in 1480. Who were the experts? What did they teach? Who could you study and emulate? Of course, there were lots of self-styled, widely revered "experts" who knew all about it. Sure. Columbus had to do it without any help that was actually, you know, helpful!

Innovation is not like health, fitness and most everything else. It's different.

Winning Innovation Patterns

I truly hope someone will figure out if there are winning patterns for innovation and make a science out of it. Until then, from years of observation of people trying hard to innovate, I've noticed a couple of things.

• Pattern: Expert-phobia

Successful innovators ignore the experts. They ignore (1) the experts in their field of innovation, and they ignore (2) experts on innovation itself.

Sometimes experts in a given field, even widely-acknowledges ones, are actually good. While the vast majority simply assert and defend the common view, sometimes an unusual expert will innovate or be helpful to an innovator. But this is the exception. The invention of powered flight is a great example of what usually happens; how the "expert" approach never got off the ground, and the hard-working unknowns made the key innovations. Here's my description.

Successful innovators just don't have time to waste on people who claim to be experts in "innovation" itself. They know that real knowledge is all that matters.

With all the noise about "innovation" in the air, it may seem to make sense to dive in to the "innovation" pond. I've noticed that the people who actually end up innovating with success don't go there. They've got better things to do. If they largely ignore experts in their field, why would they pay attention to experts in generic innovation?

• Pattern: Dive Deep, be the Best

The people who create innovations that work started by diving real deep into some particular area of experience or knowledge. They became real-life, on-the-ground, go-to experts in something. Not famous. Not writing books and giving talks. Just knowing more and accomplishing more in some narrow area of activity.

Knowing as much as they do, they stick their heads about water, and get dissatisfied. They see waste; or stupidity; or something that could be better or be done better. They set out to do it, from the basis of being the best at the status quo. They know how things should be done. They start by wondering how things could be done.

• Pattern: Ignore the Big Picture, Focus on the Little Picture

Most people who get known as experts spend most of their energy sharing their wisdom and broadening their knowledge. They don't innovate.

The successful innovators can be remarkably clueless about the "big picture." Not their problem. They are absorbed with the day-to-day, with what confronts them in the here-and-now. They tend to be do-ers who can think, not thinkers who pretend they could do if they really wanted to.

Often, the problems that inspire innovators are "trivial," from the big-picture point of view. It is just those problems that inspire practical, real-life innovation. Here's a description of "little picture" innovation, and here's an example of "little data" innovation.

• Pattern: Innovate as Little as Possible

Innovators like to innovate. They think of themselves as creative people. They love to solve knotty problems. This is the main problem of many creative people who fail to innovate with success. They can't stop!

People who innovate successfully innovate something that matters. Then they stop innovating, and do what they need to do to make their innovation work in the real world. They reduce their risk. They stick with proven things. Because they want their innovation to work!

• Pattern: Solve Real Problems of Real People

Everyone knows that medical records have to go digital. They've know it for a long time. There were and are loads of experts and industry committees piously pontificating about the best way to do it.

Then a programmer -- yes, a real, live software engineer -- went into the records room of a medical practice and learned how to do the job from the people who were already doing it. He did the work, not just for a couple hours, but for days on end. Long enough to see all the issues. Long enough to get bored, get annoyed, get ideas and get motivated to automate stuff.

He didn't make a plan. He didn't create a strategy. He didn't run some ideas past some people. He wrote some code. Code that would make his life in the filing room better. He tried it out. He wrote more code. The people who really worked there asked if they could use it when he wasn't there -- because it would make their jobs easier. What a concept! The code became Athena Health's highly successful clinical records management product -- a rare example of innovation taking place inside an already-successful company.

• Pattern: Apply Step Theory

Successful innovators don't tend to have carefully-thought-out strategic plans. They don't lay careful foundations. They don't create detailed plans that account for a wide range of contingencies. They know that if they don't get through today, there will be no tomorrow. They know that there may end up being 1,000 steps in their journey, but they also know that if they fail on step 1, they have failed. So step 1 is the ONLY step that matters.

This is "step theory." For more details and examples, see my book.

• Pattern: Ignore Fashion, Except for Scale-up Marketing

It's rare that people who jump on one of the fancy new bandwagons accomplish much of real value. In fact, most of the fancy new bandwagons are little but fancy new names for things that have been around, while others are fads that will fade out. Big Data? Old news. Machine learning? Been around. Blockchain? Great for Bitcoin, not much else.

Nonetheless, to the extent that the fashionable thing happens to be applicable to a narrow, real-world problem and smart, go-deep people focus on real problems and solve them with urgency, innovation can result. Then, as the innovation starts to get traction, it makes perfect sense to embrace the fashion. Why not? If that's what it takes to get people to pay attention to you, you do it.

Conclusion

Here are a few examples of real-life innovation that I'm associated with. Here is a whole book of innovation stories, taken from real life and personal experience. I hope that these patterns of successful innovation will be further explored and help inspire future innovators.

Innovation Stories

I worked at Oak Investment Partners for a long time until retiring from it at the end of 2015. Here is part of my page on the Oak website in 2015:

During that time, I had the opportunity to dive into hundreds of tech companies over many cycles, and the further opportunity to be an insider at dozens in which we invested. I learned that what most people tell you about how to be a successful entrepreneur often doesn't match up well with the winning companies I saw.

So what's a person to do?

One thing you can do is read my book. It won't tell you how to win (that's on you), but it will clearly identify some of the most important success patterns to follow, and some of the popular failure patterns to avoid. It has dozens of examples from real life to illustrate the points.

Here are some of the companies in the book and the points or patterns they illustrate.

CRM co., OpenData, Sybase: Do NOT make your execution match your strategy! If you're going to invade a country, don't attack everywhere, pick a beach.

Captura/Concur: Don't let perfection get in the way of making your product usable.

Web services company: Pick something that you can finish, well and quickly.

Smartdrive: When you think you're really focused, try making the focus even narrower.

Inktomi: Don't move on to the next battle until the current one is totally wrapped up; mostly wrapped up may not be good enough.

Workflow companies, collections: The customer defines the problem, not you.

HNC/FICO: Using a platform to attack a narrow but important problem set.

US Auto Parts: Does the customer have a problem right now?

G-Market/E-Bay: Cross-border issues are more than language.

Bank processors e.g. Fiserv: Customers aren't fond of risk.

Nextpage: Are your benefits tangible?

Fastclick: Can you deliver results quickly?

Rebelmouse: Make each step towards a vision be usable.

Athena Health: Adding a whole new service can be 1+1=3

Radisphere to Candescent Health: Giving your customers to someone else can be a great idea!

Company A: Using end-user products in a product/service can save time and money.

Video Ad Network: Sell it first, then build and deliver it seems backwards, but it beats everything else in the right situation.

Maestro Health: You don't always have to program everything; sometimes having people do some of the work is a big win.

Evident: Methods that are great in one domain maybe be failures in a different one.

The Innovator’s Dilemma book: Listening to your customers can hold you back.

Smartdrive: Picking the right group of customers to listen to is key.

TxVia, Feedzai: Building a tool and delivering an application or service with it can be an overwhelming advantage.

MobiTV: Do you have large customers? The power relationship determines the outcome.

Huffington Post: Pick a direction, go quickly, stop for nothing.

Conclusion

I'm kind of slow. It took me more than ten years to start noticing the patterns I've written about, and another ten years testing the patterns against the companies my partners looked at and/or invested in. But they've held up. I know I haven't discovered all the relevant patterns or explained the success of every company, but I also know that I don't read about the things I wrote in the book, which is why I took the trouble to write it. I hope new generations of innovators will improve their odds of success by following the path of the winners.

 

Innovation: From Startup to Success

I've recently published a book whose subtitle will soon become the title: "From Startup to Success." It's a tiny voice in the hurricane of books, conferences and attention paid to Innovation. Anyone doing something new that somehow involves computers and software would benefit by paying attention to this book. It identifies success patterns that aren't found elsewhere.

Software-fueled Innovation

We currently benefit from more than 150 year's worth of general-purpose innovation. Trains, planes, cars, phones, refrigerators, prepackaged ice cream, etc. The innovations are now a broad array of products and services offered by major organizations. You go to business school to learn how to run and staff such organizations.

A sizable fraction of today's innovation is built on and using computer hardware and software: the internet, smart phones, Amazon, Google, Facebook, Uber, and a host of others. The new generation of innovation is software-fueled innovation. It's still innovation, but it's different because of the software.

Software makes it different

Airplanes were invented by the Wright brothers, who were experts in bicycles. Anyone could see everything important about the device they built, and even basically understand it. The same holds true for all the innovations up to and including early computers: you could see the card readers, the plugs, and the vacuum tubes. But then things got tough.

Once complex circuits could be built on a chip, you could see the chip, but not the millions of electronic devices on it. Even worse, you can't see the software that may process billions of instructions on the way to getting something done. You can view the "source code" of a piece of software, but how many people can read it with understanding? Software has piled up over the years, so that today, new software is built on the foundation of millions of lines of code that is in older software, the foundation without which the new software could not operate. Even most modern software "experts" have never seen that code that's "under the surface" of what they write. They don't understand it and couldn't write it themselves.

Software is a new world, invisible to the majority of normal people, and only partly visible to the vast majority of people who call themselves programmers. Software is a new world, and startups that are fueled with software have new rules for success. Well, not entirely new rules. But they're different enough that most startups don't understand them. Why?  No one is teaching the rules of success for software-fueled startups -- least of all business schools!

That's why I wrote the book. I don't know all the answers. But I have figured out a bunch of them from twenty years of closely examining software-fueled startups, partly as a programmer, but mostly as a technically-oriented investor.

Applied common sense

Many of the things I point out in the book sound like simple common sense. But it's not common at all. For example, "solve a problem a customer knows he has" sounds like the dumbest of not-needed advice. But in practice, it's one of the least-commonly-followed dicta you can imagine! Here's an excerpt from the book on that subject.

Solve a problem the customer knows he has

This one is so obvious it may sound like a joke; why would a company try to sell a solution to a problem a customer doesn’t know he has? It sounds insane! But it happens over and over again.

People who come up with new things are often pretty smart. They tend to be imaginative, and see past the here-and-now. They can create abstractions easily, and find the commonalities among apparently unrelated things. They’ll see an obstacle or limitation in a business, or a way to make it much better. They’ll put together a way to remove the obstacle, overcome the limitation or implement the enhancement. They will typically be pretty excited about what they’ve accomplished. Then they’ll try to sell it, get frustrated, and before long they’ll be venting about stupid customers who can’t see past their noses, who will refuse an offer to pay a dollar to get five in return and who are otherwise mentally damaged. This is the typical result of solving a problem a customer does not know he has.

The problem and the solution may be clear to you, with your skills and ability, and having walked the path of analysis and understanding that you have. But is it clear to the average customer, without either injecting him with brain-enhancing drugs or putting him through a multi-week education course?

Should you be smarter than your customers? Maybe. But if you are so far "ahead" of them that you insist on selling them a scratching service for an itch they don't feel, maybe you're "too smart," and should get over it.

This is one of the dozens of things that are obvious in theory, but hard to get in practice. The book has lots more.

Common sense that doesn't work

On the other hand, there are some widely accepted practices that are sure-fire ways to fail at a startup. Here are a couple that are described in detail in the book:

• Understand the market. Bad idea. The "market" is what is there today. You're building something new.
• Make your tactics match your strategy. One of the worst commonly-accepted notions. It seems to make sense, but it leads to failure.
  
• Assure that you have a sound strategy. "Strategy" is a time sink that sucks valuable resources away from the effort to win. "Step Theory" (read the book) explains why.
  

Conclusion

I've had an insider's view of hundreds of software-fueled startups over multiple technology cycles. One of the most striking things I've learned is the winners do things the "wrong" way in the eyes of most experts. That's how they win! Of course, it's got to be the right "wrong" way that wins, not just any old wrong way; there are plenty of wrong ways that are losers...

Software Business and Product Strategy Book

My book on Software Business and Product Strategy is now available, in Kindle and  paperback formats.

It went through dozens of drafts as two separate private circulation papers on the way to its current form. Here's the front cover:

Here's the back cover:

It's the fifth book in the on-going Building Better Software Better series of books. Here is a description of the origins of the series, and here is a description of each of the earlier books, with links to blog posts with highlights.

Most of my experience is with computer-based businesses, but there's a rumor, to which I give credence, that the principles described apply to all kinds of small business.

I recognize that there are piles and piles of books on building businesses and creating product strategies. You can get degrees in it from eminent tenured professors at fancy schools who have publications and honors trailing after them. You can participate in all sorts of programs that teach "innovation" and provide fledgling innovators with access to all sorts of seasoned help. So why another book?

Pretty much for the same reason that I wrote the earlier books in the Building Better Software Better series: the vast majority of the books and articles I read tell you to do one thing, and the people I see who start and build software-based businesses to success do something different!

I spent a couple decades creating or working for young, innovative software-based businesses. I have spent a couple more decades investigating, following and investing in software-based businesses -- hundreds of them! In multiple technical and business domains. I've worked closely with the leaders of these companies, and with many of the techies in them. I knew and they knew what you're supposed to do, and what's supposed to work. As time went on, I began to notice how the usual "success" rhetoric played out in reality. Patterns began to emerge.

One of the patterns I describe as "Step Theory." It's a core pattern that is highly correlated with success. There are vertical steps and steps to the side that are often cornerstones of success. Among the dozens of examples I use are Athena Health and Huffington Post.

Another important pattern is the relationship between strategic positioning and tactical execution, which I illustrate with a CRM company, a beach umbrella service and the invasion of Europe.

A few other points, each illustrated in the book with examples, are:

• everyone knows they have to "focus," but knowing how to actually do it is rare
• everyone knows how important strategy is, but trying to make tactics match strategy screws things up
• everyone wants to foster creativity and be creative themselves, but it's often too much creativity that sends young ventures off the tracks
• paying attention to what "the market" tells you frequently dilutes your efforts and prevents success
• starting a great new business requires looking into the future; but unless you then concentrate on what's in front of your nose and ignore the future, you're doomed.
• simple things like minimizing customer risk and delivering fast, hard-dollar benefits are crucial
• shifting company strategy while following success patterns is often crucial to success
• feedback loops and continuous improvement beat "perfect" plans every time
• listening to the "wrong" customers can be as bad as listening to none of them
• ...and lots more!

Each major point in the book is a general pattern I've noticed. Most of the points are not generally talked about in places that are supposed to teach these things. Each has been reinforced in my mind by some of the amazing entrepreneurs I've had the pleasure of working with over the years. Each of the patterns is illustrated by examples I've encountered in real life, sometimes by people who just did the right thing, or by groups that encountered issues and responded by doing the right thing.

To everyone in the book and everyone else I've worked with, please know that you have my gratitude. It is in part to thank you for teaching me that I have tried to put your lessons into this book, lessons I hope will help others on their path to making the world a better and more productive place.

 

Uber’s Evolution from the inside

Uber is a great success; you can tell because competition has sprung from all corners, and scads of new companies say they’re going to be “the Uber of X.” Along with great success comes great myths, which inform a set of assumptions about how Uber got to be Uber. The myths are all derivatives of the broadly accepted narrative of how tech companies start and grow. In every case I’ve examined, fact-based history contradicts these myths and explodes what “everyone knows” about Uber and every other tech company. I’ve explored this theme in a couple of cases, and I’ve just had the opportunity to question an early Uber driver, whose story provides fascinating insight on just a small part of what really happened.

Recruiting the first drivers

My driver was one of the first handful of drivers in the New York City area. Uber is a network-effect company, i.e., customers need access to a large pool of drivers, while drivers need business from a large pool of customers. How do you get that started? Of course I don’t know the whole story, but I did hear how my driver informant was recruited.

He was sitting in his car near Madison Square Park in Manhattan with a half hour to go before his ride would appear. Someone knocked on his window. He rolled it down, and it was two people who wanted to talk with him about a new way to get rides. It started to rain, and he invited the people to sit in his car, for which they were very grateful. He ended up signing up for their service, encouraged by a $1,000 signing bonus, and further encouraged by being paid $35 an hour just for keeping the app on his phone. He was then paid $1,000 for each additional driver he referred who signed up, and a further $1,000 when that driver took their first ride. That’s how a critical mass of drivers was recruited even when there was little work for them to do.

Here’s the part of the story I found most impressive: the two people who recruited him were … the head of Uber NYC and Travis Kalanich, the co-founder and CEO of Uber.
Yes, the big boss himself, personally walking the streets of NYC and hitting on strangers. Wow. For every 1,000 bosses who puts up one of those stupid pyramid-on-its-head charts
during a company talk to say how he’s just there to serve the important people on the front lines, there might be a couple like Mr. Kalanich who act on it and get into the trenches themselves.

Recruiting the first customers

Uber today is an easy way to use an app to call for an on-demand car service. It’s all “get me a ride now. As in, now.” At the start, it wasn’t that way at all! It was mostly for really long rides, like from NYC to Boston or Philadelphia, and the rides were often round trips with a big wait in the middle. This is a tiny minority of all rides, but one that was typically arranged way in advance by phone. With Uber, you could get someone to pick you up in half an hour or less, which was great compared to the alternatives. It also meant that having just dozens of drivers available was OK.

It was only as the population of drivers and customers grew that shorter trips with shorter lead times made sense – and the long-trip buyers were an ideal starting population as customers for that, so it evolved naturally.

Evolution of the service

Here are some tidbits about how the service has evolved.

At the beginning, drivers were screened thoroughly. For example, every candidate was shown a map of Manhattan with no street names. A pin was placed on the map, and the driver had to name the streets. If you didn’t get them, you were out. The screening has gone way down over time.

The cut taken by Uber has ratcheted up sharply. It started at just 10%, moved in a few steps and is now up to 38%. A huge difference.

As the number of drivers and customers grew, Uber provided a “heat map” in the driver’s app to show where drivers were needed and where there was an excess, which helped drivers position their cars to best effect. A subsequent version of the app dropped this feature and replaced it with congestion pricing. My driver misses it, and thinks a new version is coming out with the heat map restored.

The policies and standards for drivers have evolved quite a bit, something which is also visible to customers with the addition of Uber-X and evaluations of drivers – I learned that drivers can also evaluate customers! My informant says the evaluations are on the whole helpful – one incident reminded him he always has to inspect the passenger seat when someone leaves, for example, something he had been neglecting.

In spite of all the changes, my driver/informant loves Uber. The main reason is he has control. He can start and stop any time. He can work more and make more money, or take time off any time he needs to, without asking anyone’s permission.

Observations

It appears that Uber did a very smart thing I have seen other companies do: pick a sub-market in which they could get traction, and then evolve into the actual, larger market they probably had in mind all along. The sub-market enabled them to get to a critical mass of drivers and riders with less friction.

It's easy to focus on Uber as enabled by an app, or Uber as a marketplace. Those things are true. I think of them as being good choices (the app) and reasonable thoughts (marketplace), but somehow not essential.

For the consumer, Uber provides the convenience of hailing a cab (no advance planning, scheduling, committing) with cars that you can't see. It would work just as well if you used your phone to dial a number, gave your location, and then were told how long you'd have to wait for the driver. An on-demand car service.

For the driver, Uber provides control over time and money, as my informant made clear. When you drive a cab, you sign up for a shift. With a car service, someone schedules you. With Uber, the driver can opt in and opt out whenever it meets his needs, whatever those may be. Whether he got rides from an app or from someone calling him, the result would be the same.

Conclusion

Every company has a different story. Uber is no different. Even a narrow and limited glimpse into the factual history of Uber reminds us that every company ends up having a myth-based story that explains its success, and that if you’re going to learn something useful from their success, you have to find and pay attention to the facts. AND, the facts of similar companies that failed.

Facebook's Software Quality: the Implications

I have pointed out Facebook's lack of desire or ability (who cares which?) to deliver software that actually works. I've pointed out that they're hardly alone in this respect. It's important to accept this observation as true, so that you can change behaviors that may have been unconsciously predicated on the supposition that Facebook delivers great software, effectively and efficiently. They don't. So don't hire their people and expect great things to happen, and don't mindlessly emulate their methods or use their tools!

The Unspoken Assumption

Facebook is a wildly successful company, worth over $200 billion. I'd like my company to be worth even 1% of Facebook. So I better find out what Facebook did, and learn from it. Facebook is a software company, so their engineers must be smart and effective. I better get some of them in so they can teach us the "Facebook way." And their tools -- wow. If Facebook uses something, what an endorsement that is. My guys had better have a real good reason to use something else; I look at what FB's worth and what we're worth -- don't we want to be like them? If a tool or method is good enough for FB, it should be plenty good enough for us.

The role played by software in FB's success

Here's the logic:

FB is wildly successful.

FB is built on software.

Therefore, FB software must be wildly excellent.

We already know by examining the quality of FB software that it's crappy. So we have reason to suspect that the virtues of FB software may NOT be a driver of FB's success. Consider this thought: What if FB is wildly successful IN SPITE OF its crappy software? If that's true, the LAST thing you'd want to do would be to infect your reasonably healthy engineers with disease vectors from FB.

Explaining FB's Success

There are lots of reasons software companies can become very successful other than having great software. In fact, by the time a company gets large, bureaucracy and mediocrity normally take over, and any great qualities in the software are normally eliminated. The most common reason a software company gets and stays successful is the network effect, the self-validating notion that "everyone" is using the software, therefore I should too.

The network effect becomes even more powerful when there's a marketplace. E-Bay is a great example. If you're a seller, you want to sell in the place that has the most buyers. If you're a buyer, you want the greatest choice of things to buy. Similarly, if FB is where all your friends are, you'd better sign up -- which makes the network effect even stronger.

FB, by chance or plan, leveraged the network effect for growth brilliantly. Harvard already had a physical book with everyone's pictures in it, called the Facebook by students. The basic education and promotion problem was solved out of the gate: Harvard students knew what a "facebook" was; they all had a physical one, and used it, if only because their own information was there. For example, here's me in the 1968 edition:
However straight-laced those Harvard freshman looked, a fair number of them were hackers and troublemakers. Here's the very last page of the 1968 FB. Look at the last guy listed.

There's a similar entry, with a different photo, at the start of the book.

Zuckerberg was solidly in the long-standing Harvard hacker tradition. He had already illictly grabbed student photos for a prior application, which both got him in trouble and made him famous on campus. So when he launched "thefacebook," of course all the Harvard students would check it out. He did this in January. It was used by about half of all Harvard undergrads within a month.

His next smart move was to open it just to students at a couple more elite schools, and then Ivy League schools. Once established there, he expanded. He did NOT open the doors and let anyone join -- he moved from one natural community to the next, letting the network effect do its magic before moving on. Finally, alumni were allowed to join, but only if they had a .edu address proving their affiliation. That's when I joined. Only after a whole generation of students had made it the standard did FB allow their parents to join.

The quality of the software had nothing to do with this. If people had to pay for it, FB would have flopped. Feature after feature came pouring out of the self-declared brilliant minds of the top people at FB, many of them flops, mixed in with scary experiments with privacy. But it was "good enough" most of the time, it's free, it's where your friends are, what can you do?

The conclusion is clear: FB grew to be a huge success IN SPITE OF having rotten software quality and development methods that are just horrible.

The FB environment and yours

Facebook software development methods and tools are NOT something a small, fast-moving, high-quality software shop should want to emulate. Their quality methods in particular are not only trashed by their users, but also by a fair number of ex-employees. The same thing goes for the computing and server environment.

If you find a talented ex-FB-er, by means hire him or her -- but only after verifying that they're sick of how things are done at FB and want to work at a high-quality place.

Above all, don't emulate the actions of FB's leadership. It's the network-effect flywheel that continues to bring eyeballs to their applications, NOT their great software.

And think about this: if they're so brilliant and such great developers, why have they done about 50 acquisitions in their short life, a couple of which are important to their growth?

Innovation with Computers and Slow Things

People have theories about innovation. Increasingly, they think it's important to innovate. Fine. I'm all for it. Given a choice between "innovation" (whatever that is) and the alternative, which I assume is something like "sitting and rotting," I'll take some of the former, thanks very much.

Whatever people end up saying "innovation" is (which kinda doesn't matter, because before long it will fade away, eclipsed by the next fashionable thing), it's clear to me that there is a huge difference between innovation that is based on using computers (which evolve quickly) and all other kinds of innovation.

For purposes of this post, I'll define innovation simply: innovation is doing something differently than you did before.

Physical Innovation

Physical innovation is hard. It doesn't happen very often. The reason is simple: over time, everyone pretty much figures out the best way to do things, and figuring out something new is hard and rare. A typical example of this is the gradual shift from wrought iron to steel.

Here is the famous iron pillar at Qtub Minar in Delhi, as it was when I visited it a few years ago.

This pillar was created no less than 1,000 years ago, and perhaps longer than 1,500 years. Wrought iron was created in many parts of the world, from China:

to Europe.

Steel is closely related, but different in important ways. The very earliest steel is about 4,000 years old. A form of steel, Wootz steel, was made in India more than 2,000 years ago. This steel was shipped to the Middle East, where it became the raw material for Damascus steel swords. But none of it was a practical innovation over wrought iron until the introduction of the Bessemer Process in the 1850's.
Then and only then could we have wonderful modern things like steel cables, structural steel for buildings and bridges and many other things.

Physical innovation, like the replacement of wrought iron by modern steel, is tough and long, punctuated by invention while still requiring endless baby-step innovations.

Process innovation

Process innovation is a whole different animal. Process is what the concerned human beings agree it should be, even if a bunch of machines are involved. The only limit is concepts. Opportunities for process innovation are all around us. In all too many cases, it seems more appropriate to call a process innovation something more like "stop doing it the obviously stupid way."

Here's an example. Not long ago, a delayed flight I was waiting for at JFK airport was finally cancelled at 1am. A whole lot of people went to the terminal entrance and got in the roped-off line for cabs. I waited about 20 minutes to get to the front of the line, and there were loads of people still waiting after me. "It's real late," I thought, "I guess most of the cabbies were sensible and are home sleeping in bed." Nope! There was a looooong line of cabs waiting to pick up the loooooong line of exhausted rejected passengers.
What was the problem? Process, of course. There was a single person who had to find out where you were going and give you the right piece of official paper before you could get into a cab.
And instead of walking up the line of waiting people, the "dispatcher" insisted on performing his duty as you were getting into the cab, which serialized the whole process.

Process "innovation" is, more often than not, simply "stupidity elimination."

Conceptual innovation

Conceptual innovation is a pretty big deal. It is limited only by the powers of the human mind. One of my favorite examples is one I encountered around the time I graduated from high school, George Danzig's Simplex algorithm for solving a linear programming (as in math programming, not software programming) problem. It's cool; it's been called one of the top ten algorithms of last century.

Computer Innovation

I know there's lots of physical innovation involved in creating the unprecedented, awesome speed with which computers evolve. There has been nothing comparable to it in human history. It also know it's accompanied by and partly enabled by lots of true conceptual innovation and some process innovation. But let's take all that as a given. What do we have?

We have a set of tools that can control, automate and communicate faster than anything in history, and that improve at a hard-to-comprehend rate. As soon as we get something working with one generation of the things -- BOOOM! -- everything concerned has just gotten better by 2X or more in speed, cost and size.

Steel took over from wrought iron when the process of making it got faster and cheaper, and when the results were superior. It took decades. Well, that happens every year or two with computers -- the question is, how are you going to take advantage of the improvement?

That's computer innovation. What's possible now that wasn't a year ago? What can I do now to create a product or service that, on next year's devices and networks, will make sense? The people who jump on this and make it happen are the innovators.

The themes are clear: we move from slow transmission of small amounts of data to big, expensive devices (think teletype) to near-instant transmission of huge amounts of data to small, affordable devices (think smart phones). This happened in small steps. Each step was a massive technology and business disruption. Fortunes were made and lost at each step. Fortunes will continue to be made (and lost) as some people see the possibilities and take advantage of them, while most learn the current state of computing and networking, and -- amazingly -- act as though it won't change. That's actually what the vast majority of people and companies do!!

Computer innovation is different than the other kinds -- not better, just different. If you understand the rules and act accordingly, you can accomplish amazing things. It almost feels like cheating to call it "innovation," but technically it is, so let's go with it.

When is Software Development "Done?"

Almost any activity you can think of, from building a road to composing a symphony, gets to a point where it's done. If not, something awful has happened, and you declare failure and move on. Software projects seem to be different, for no obvious reason. Quite frequently, software isn't a throw-it-out failure, but then it's not done either. What's going on here?

Building a house

Why can't software be like building a house? My uncle built a house for himself back in the 1950's. First came the foundation:

He did a great deal of the work himself, as much as he could:

All the way up to finishing the chimney for the fireplace and furnace:

And then it was done! He and his wife could enjoy a nice time with their nephews in front of the fireplace of the completed house:

Which actually was completed, unlike all those software projects, which drag on and on, refusing to get completed or to die. Perhaps this is why books and movies about zombies have become so popular!?

If houses were like software...

If houses were like software, instead of actually being done with them, they'd all be like the house built by Sarah Winchester, who bought an unfinished farm house in 1884, and spent the 38 years from then until her death having it worked on and expanded continuously, all day and all night. Here's a clip about it from an old magazine:

Building Software

Frequently, software projects are just failures. In spite of the traditional massive padding of estimates, things take even longer than projected. After the usual remedies (denial, punishing the innocent, rewarding the guilty, etc.) are exhausted, more money and resources are thrown at the project to "rescue" it. This inevitably has the effect of adding to the mountain of evidence supporting the thesis advanced by Fred Brooks in his classic "Mythical Man-Month" that adding resources to a late project makes it even later. Finally, the project is declared to be a "success" and promptly put on the shelf, never to be mentioned in polite company again, or the project in rare cases is declared a failure so that blame can be put onto the innocent target of some politically powerful person's agenda.

However, there are exceptions. I see such exceptions constantly in the growing, innovative companies I work with. These companies don't just grow. They learn, experiment, evolve, extend and sometimes take great leaps. As modern companies, they do this in close collaboration with their software, and frequently software is all or a major part of the service they provide.

Instead of thinking of the software as a house that needs to be designed and built, it's more appropriate to think of these companies as starting out with baby software that needs to keep growing and becoming stronger and more independent, like an infant grows to be a toddler and so on. If you stop developing software in this context, you guarantee the demise of the business. With a static business, it's appropriate to think of "finish or fail" as the relevant choices for software. With an innovative, growing business, it's appropriate to think of "evolve or die" as the relevant choices for software.

Conclusion

Everyone wants software to be like everything else: figure out what you want, build it, declare completion or failure, and move on. But when software is the engine that runs your business and you're trying to get on track to be a big success, the rules are different. In that case, the rules for software are: make the most important changes, figure out what is most important next, do it, clean up the software a bit, run some experiments, refine the winning approach, and keep evolving. Work fast, work accurate, be responsive, always learn, and keep learning. That's how you win with software.

 

Process and Substance in Software Development

High among the concerns of software management are questions of organization and process. While these are reasonable concerns to have, I generally find that paying attention to substance is more productive. If you think of your organization as being like a software factory (a line of thought I generally discourage), this means you should pay more attention to the widgets that come out than the organization of the shop floor.

Process

It is easy to be totally consumed by process, organization and people. Everyone wants to know who's their boss. When there are disputes, who has the deciding vote? Many people want to know their "next step" in the organization, the path to greater responsibility, power and pay. Such concerns tend to be greater in the minds of the people on the upper part of the ladder, not to mention the top, since they usually had to work at getting where they are.

Process and organizational structure are tightly tied. Is QA a separate group with its own head? Or are there QA people as part of each small group of developers? If QA is distributed, what is the reporting structure? This is complicated by the myriad of process fashions that sweep through the industry -- there are literally dozens of them in play at any given time, things like Agile and Extreme, with Lean coming up fast.

Substance

Substance is embodied in the code that is produced. Given a set of general requirements, the substance of what is produced can differ wildly. Suppose you're extending your application to mobile. Do you use HTML 5? How do you bridge to the details of the local device? Do you write in Objective C (the native language for the Apple devices)? How much do you store locally, and how do you communicate with the servers? What about all the Android devices?

And I'm just talking about the simplest questions here. Real substance is contained in the details of how the code is written in the chosen environment. For example, the code can be pretty "straight," it can have loads of parameters, it can be layered to varying extents, it can be driven to varying extents by meta-data, etc. These choices have a huge impact on the outcome.

Process vs. Substance

Dilbert illustrates the point nicely, as he often does. In the cartoon below, the pointy-haired boss focusses, as you would expect, on process. He is concerned about dates and whether Wally has met expectations that have been set, completely ignorant of the substance.

Wally, crafty as ever, claims to have created a disastrous substance. The pointy-haired boss, unable to determine whether Wally's claims about substance are true, and unwilling to risk that they may be true, gives in.

Conclusion

Don't be Wally -- but also don't be the pointy-haired boss. Pay attention to substance. Make it your business to understand it. Your attention will provide an example to your group, telling them what's important to you. Your attention to substance will be like a chef who cares that the diners love the food that comes out of the kitchen, and does so by -- what an idea -- paying attention to the food itself.

CTO + CFO = CFBCO

The CTO and the CFO aren't natural best friends in any organization. They are typically separated by a huge gulf of perspective; neither understands or appreciates what the other thinks or does. The best thing for any organization is when the two of them can truly take the other's perspective, and change what they do as a result.

CTO

What's the Chief Technology Officer (CTO) about? He or she had better be the best technical person in your organization. The one who understands the details, the big picture and everything in between. The one who actually understands all those computer acronyms, can sling them with the best, can pick the best and harness them for the good of your organization. At best, the CTO can rally the tech nerd employees to the cause and also convince the suits that everything is good.

CFO

What's the Chief Financial Officer (CFO) about? He or she had better be the best financial person in your organization.The one who understands every line of every statement and report, what's behind it, what led to it and where it's going. The one who understands how all that mass of detail relates to company tactics and strategy, and plays a key role it making them align. At best, the CFO can handle the big picture and the details, issues and people inside and outside the company, all to advance the company towards its goals.

CTO vs. CFO

When not at their absolute best, the CFO and CTO can have a chilly relationship.

The last thing the CTO wants is for some nosy bean-counter to mess with his stuff. Even simple questions are suspect: why is he asking? what's he looking to cut? Go away! Most CFO's seem like clueless idiots to even average CTO's. All they can possibly do is waste time and, through crass stupidity, make things even harder than they already are.

CFO's often see the whole tech group and the CTO in particular as being a bunch of whiney, spoiled, self-absorbed brats. They're anti-social, talk among themselves in their private language, get huffy or all-too-patient in response to even the simplest of common-sense questions, and seem perversely intent at avoiding anything that increases revenues or profits. They're perpetually late, reluctant to commit to anything, always complaining about lack of support, but still manage to have an attitude about pretty much everything.

CTO Fundamentals

Most of the thoughts I've had about computing that are worth anything took me years, often decades, longer than they should have to penetrate my thick skull. But one of the earliest realizations I had remains both true and rarely discussed: to the extent that computers are applied well, they cut jobs, and therefore (usually) costs.

This isn't the pretty way to put it. Most people prefer to think about how computers enhance people's efforts. And they do -- meaning you can get the same job done with fewer people. Or you can deliver more with the same people -- to deliver more without computers, you would have had to hire more people. Any way you cut it, the more widely and effectively computers are used, the fewer people you need to get a given job done.

Put all the gobble-de-gook aside, and what computers come down to is simple: cut costs, do more with less, get it done faster, etc.

Now what does this sound like? Could it, perhaps, sound like the kind of thing CFO's are supposed to worry about? Hmmmm....

The CFBCO

Maybe there's some middle ground here. At the heart of the matter, there is no skill set in an organization better suited to helping a CFO meet his goals than the CTO's. And when a CTO who is really good in nerd terms wakes up and realizes what his job is really about, there is no person better suited to be a company-maker than a bottom-line-oriented CTO.

Put in the most basic terms, a good CTO can make things happen:

• Faster
• Better, and
• Cheaper.

Faster, better, cheaper. That's computing in a nutshell, and when computing is applied to an organization to greatest effect, that's what happens to the organization. It does what it does faster, it does it better, and it does it cheaper. FBC. Wouldn't it be nice if we could have a Chief Faster-Better-Cheaper Officer?

Conclusion

In most organizations, there is a spectrum of leadership. At one end of the spectrum is the nerdy CTO. At the other end is the what's-your-handicap CFO. If you're very lucky and very deserving, maybe you have someone at the center of that spectrum who combines the best of both extremes in a single individual. The CFBCO. The CFBCO combines ultimate nerd-power with dollars-driven vision and insight, and makes the relevant numbers better in a way that even the dullest and most distracted board of directors can understand and appreciate.

Better Software Lets You Compete Against Giants and Win

There are lots of personal and emotional characteristics that help winners build terrific new companies. They're important. But when it's a software company, guess what? The software really matters!

There are a number of elements that contribute to success, including concentrating your forces, targeting poorly defended or new territory, and rapid iterations in response to new knowledge and changing conditions. However, there's nothing like superior weapons to help your cause.

Your competitors are typically GIANTS compared to you, so giant that they darken the sky...

Darkening the sky is bad enough, but what's really scary is when they notice you, pay attention to you, and get in your face...

Now you have one choice and one choice only -- pull out your weapons. If your weapons (software) are truly, fundamentally superior (and you don't screw up the other things too badly), then you've got a good chance of vanquishing a larger, established, well-equipped foe...

Which feels awfully good and definitely deserves raising your arms in victory.

Conclusion

If giant competitors cover the sky with dirigibles, you had better be dive-bombing them with powered, fixed-wing airplanes. When invading a place that is well-defended by armies with swords and war horses, you'd better have guns and armor. When the giants in your industry dominate with a kind of software, your software had better have the same advantage that guns have over swords and airplanes have over balloons...and that smart little girls have over giant adults.

 

From Start-up to Success: Costs and Planning

Your start-up has started up -- the engine is cranking, revenues are substantial and growing, things are working. It's exciting! Now it's time to conduct some wild experiments and screw things up royally!!...

... no, sorry, I don't know what came over me there ... really, now is the time to plan and measure our new initiatives. We don't want to screw things up; so we'll put a process in place, and we'll only approve projects that meet all our criteria, including budgeting, cost and revenue projections, etc. This is the perfect complement to the general growing-up process we've started.

It's hard to argue against this logic. It sounds like you're being impulsive and childish if you try. Doesn't it make sense to grow up?

Yes, growing up is a good idea. But the question is, what kind of adult are you going to be?

Should your organization mimic the "best practices" of the slothful old organizations whose cluelessness gave you the opening to start, grow and thrive?

Strangely enoughly, that's exactly what vigorous organizations tend to do when they try to "grow up." I used to find it shocking, but now I just expect it. The net effect is simply awful. The practices they attempt to mimic are, after all, bad practices -- and the aspiring organization typically executes them badly. So what's that? Bad squared?  

There are ways to "grow up" and avoid disaster without losing your soul. I'll just mention a couple of the key ideas.

Cost tracking

Yes, cost accounting. Sounds old-fashioned, doesn't it? But time after time, when organizations find out how much money they spent last month on exactly what, there is shock and awe: you mean I spent that HUGE sum on THAT??; and one of our supposedly most important initiatives got THAT paltry effort?? Actually knowing where the money is going often has an amazingly salutary effect. Simple but effective.

Planning: broad goals, lots of feedback, iterations

An effective planning process in an agile organization does not lay out what you're going to get, when you're going to get it and exactly how much it will cost before the "real" work starts. In fact, as I've been known to say, dates are evil. An effective, light-weight planning process is one that:

• Has broad goals. The goals include measures of success so we can tell how we're progressing, but a minimum of predictions. Instead of predictions, we have the simple edict: as fast, well and inexpensively as possible. And success isn't measured by how good people feel about the effort, but by the numbers.
• Incorporates lots of feedback. The feedback should be from both inside and outside the organization. If possible, it should be a combination of asking people what they think and having trials so you can see what they do. The feedback should be continuous, and should apply to every step of the effort.
• Has lots of small iterations. This is the key to replacing the old heavy-weight planning process. Mistakes are catastrophic if they are long and expensive. If they are short and cheap, they are simply part of how you learn. You don't have to be perfect if you have loads of small trials, which means the trials can be quick. It's not like a slow march across an open field; it's like running the ball in a sport, in which success is a combination of speed and effective reaction to changing conditions and sudden challenges.

Growing with Cost Control and Real-time Planning

It is important to grow up in business and get past the startup phase. But what do you grow into exactly? Knowing where your money is going and having a planning process that emphasizes speed, agility and feedback are two critical factors in becoming a vigorous adult organization, and avoiding the sclerosis that can so easily lead to an early demise.

 

From Start-up to Real Success

Start-ups are exciting. There are passionate people in hot pursuit of a new, under-appreciated opportunity. There is the uncertainty of success and long odds, along with a compelling vision and the thought that this could really happen!

Start-ups find themselves snaking their way through dense thickets and up narrow paths, perilously clinging to the edge of steep hills. There are obstacles and dangers in every direction, many of them only avoided by quick reactions and decisive actions.

The pioneers of a start-up are, well, pioneering. They're discovering new territory every day. They learn to be creative, because if they fail to embrace the new, their venture fails.

It's all about going where people haven't gone before. Your theme song had better feature words like quick, new and creative. Slow, careful and conservative had better be attributes of other groups.

Most start-ups never really get started-up. Or they take off and fizzle quickly. Or something happens; in any case, it doesn't really work out.

Things aren't even all in the clear for the few start-ups that manage to get real traction in the market. All too often, the people who discover a wonderful new field of gold...

...find in retrospect that all their efforts amounted to building big neon signs with blinking arrows, signs that say: "Attention established companies: There is gold right over here!" Having discovered gold and brought everyone's attention to it, the start-up is unceremoniously elbowed aside as the established companies, with their organizations and big machines, move in and actually mine the gold.

And then there are the real winners. Part of the outside world starts to give them respect and another part (the part that feels threatened) says nasty things about them. They have real revenues and real customers. The market recognizes that they have something new and different, and a substantial and growing part of the market wants that new and different thing.

You might think that at this stage, everyone can breathe a sign of relief. We're on easy street now! It's true that the odds of ultimate success are way higher than they were before. But there are some HUGE mistakes that are made all too often at this point. In particular, there are important behavior and focus changes that need to happen in order to continue on the path to success.

Here are a couple of the most frequent things that go wrong:

Innovation Scope and Focus

When your venture has built up a head of steam, when it's really barreling down the tracks, the worse thing that can happen is to go off the tracks! But this can happen really easily if you haven't changed your innovation focus from "we're in the woods; there are lots of scary animals and danger on all sides; let's look everywhere and innovate about everything" to "we're on a roll; we've got customers and momentum; let's focus on the track ahead and confine our innovation to rolling down this track more effectively."

If you're not focused on the track ahead and concentrating your innovation on it, chances are you'll go off track.

Innovation Process

When you're small and don't have much to lose, your team communicates closely and changes focus quickly. If you've got an opportunity, it makes sense at this stage for everyone to drop what they're doing and jump on the new thing that could put you on the map.

But now that you've built up a real herd of cattle and more people are involved, things are tougher.

You've got to set up a system that allows you encourage pioneers, but assures that their efforts are mostly productive. You've got to encourage fresh thinking, but somehow assure that an unfortunate innovation doesn't blow up on you and cause the cattle to stampede. You can't (and don't want to) control everything, but you've got to introduce a form of light-weight process that enables a larger group to continue to innovate freely, while guarding against disaster and minimizing waste.  

Customer Focus

When you're getting started, your focus is naturally on the great sea of people out there who aren't your customers but could be. You're all about new customer acquisition (if your business is a web site, this means building UV's as you concentrate on SEO and SEM). When you've got traction of the kind we're talking about, you've got quite a number of people who already are your customers (for a web site, this means people who don't arrive via search or a link from another site). This is great, it's what you wanted.

What you should do at this point is gradually shift your focus to the people who are already your customers. Instead of putting all your effort into looking for new fertile fields, recognize that you've got some really fertile fields, and your job is to cultivate those fields.

It's true that pioneering and hunting got you where you are. But now that you've actually arrived in the promised land you were searching for, isn't it time to shift gears, gather and cultivate?

Summary

You've gotten to where you are by concentrating the efforts of a small team on no-holds-barred innovation to discover and build a customer base. You've got a bigger team now and lots of customers who like what you are already giving them. Make it your first priority to keep what you've got, adding "preserve and protect" to your vocabulary. Your business now depends on the customers you've already won -- their needs (in most cases) come before the needs of customers you don't yet have!

You've found the pirates' gold. Do you ALL need to rush off in search of more gold? Can't you manage to guard what you've got, not to mention invest and grow it?

Success with New Technology and Mouse Madness

You’ve got a wonderful new technology. It works. Customers benefit from it. Game over, right?

Wrong.

Sadly (for you), the world does not revolve around you. The world is not on constant alert waiting for better mousetraps to appear somewhere so that the world can beat a path to your door.

Let’s take the B-to-B case. If you’re a big technology buyer, you’ve got better things to do than constantly flirt with new vendors. To the contrary, you want to find ways to cut the number of vendors you work with. If your existing vendors aren’t screwing up, if their products are good enough and their price is good enough, chances are you’ll save time and stress and feed them more orders as you grow. You may take meetings from wanna-be’s, mostly for your general education; it’s a waste of the wanna-be’s time, but that’s not your problem.

The reality is that most big technology buyers have a barn of designated winners, all of whom are “approved vendors.” The vendors  have won the design competition, and are now baked in to the buyers’ expansion plans.

The only thing that is likely to change this situation is a combination of buyer pain and incumbent supplier inadequacy. While some technology buyers are motivated by opportunity, most consider a vendor change only when they feel pain. The pain is nearly always driven by a need to reduce costs. In order to reduce costs, the vendor needs to do X, and if it can do X, it needs to be able to do it for a particular price.

Since this sounds abstract, let me illustrate it with a real example from Xiotech, my favorite storage vendor.

Xiotech has invented a new mousetrap, the storage blade, which delivers storage in better ways than existing storage products, sometimes dramatically better. Is it really, objectively better? Yes. Can buyers get more done and spend less money? Yes. Does that matter to most buyers? Do storage buyers beat a path to Xiotech’s door? By now, the VP of Sales at Xiotech has accepted the fact that they do not. Having hoped for the easy life of taking orders, he is resigned to having to go out and sell stuff. The world feels cruel and unjust, but that’s how it is.

Xiotech has a better storage mousetrap, and the world has reacted the way it always reacts to better mousetraps. So what does Xiotech do?

It’s pretty simple, actually. If you had a mousetrap that was really and truly better than the other guys’, wouldn’t it make sense for you to find places that were totally, horribly overrun by mice? Not just places that have mice – places where the mice are in charge; places where the mice start trying to invent “peopletraps” because they think they’re infested. Places, in other words, where the inadequacies of the best existing mousetrap technology have been put to the test and come up short – miles short.

No one expects the incumbent mousetrap vendors to walk away from the business that has served them so well for so many years. They are bold and shameless, and will come up with all sorts of arguments. They will argue that if you have a mouse problem, you obviously haven’t bought nearly enough of their wonderful traps; the solution is to buy more! If that doesn’t work, they will wave their arms furiously about the new trap that is about to come out, avoiding any mention of the increase in maintenance charges for existing traps. Meanwhile, you walk around and see the mice dancing on the existing vendor’s obviously ineffective traps.

If you’ve really got a better mousetrap and are looking for motivated buyers, the place with the super-sized, invasion-from-Mars MOUSE problem is your candidate. Most people buy the same mousetraps they’ve always bought. They may be lousy traps, but they just don’t care. It doesn’t matter enough. But the guy with the MOUSE problem, HE CARES. He pays attention to mousetrap technology, because he knows he’s got a whole pile of mice that need catching REAL BAD.

The cruel fact of life for inventors of better mousetraps is that, if you can’t find anybody with SERIOUS mouse invasions, you are hosed. Your superior trap will do nothing but waste the time and money of everyone involved. But even if you can find places where the mice are dancing in the halls with impunity, your mousetrap had better be SERIOUSLY better than the incumbent. If the incumbent knocks off a mouse or two but leaves dozens aspiring for a spot on Dancing with the Stars, while yours knocks off two or three or four but still leaves most of the mice dreaming about skimpy costumes and getting “ten’s” from the judges, you may as well hang it up now. To make a long story short, you had better:

• Find a truly worthy mouse problem.
• Solve it. Really solve it. No kidding, nail it!
• Solve it for a reasonable price. If you’re too expensive, you may sell to a few desperate buyers, but you’ll never become the industry-standard mousetrap.

Back to Xiotech storage. Xiotech is focusing on buyers who have the kind of problems that Xiotech storage, with its high performance and linearly scalability at a reasonable price, is uniquely positioned to solve. Just as mousetrap guys look for places with too many mice, Xiotech looks for places that can’t get at their storage. Just as the incumbent mousetrap guys boldly say “just buy more of my [crummy] mousetraps,” the incumbent storage vendors say “just buy more of my [slow] storage [that gets even slower as you fill it up].” In spite of such incumbent resistance, smart buyers with mouse madness buy better mousetraps, and smart buyers with storage bottlenecks buy better storage.

Success with new technology is usually only achieved when:

• there are pockets of buyers who have SERIOUS pain;
• the pain is worth serious money;
• you can find the people with the pain;
• you can address their pain;
• your technology can really make the pain go away;
• ideally without charging more money.

Failing this, I guess you could try waiting and hoping that the world will beat a path to your door…