“Vision without action is a daydream. Action without vision is a nightmare.” -- Japanese Proverb
During my career, I've had the good fortune to run a number of businesses. I've brought a variety of products to market and have managed countless projects. Through all these activities, I've learned that success fundamentally boils down to two main, interlocking, things: vision and execution. You need both to succeed. Vision is a crisp and clear understanding of what it is you are trying to do. Everyone on the team needs to be clear on what the vision for the business, the product, or the project is, and they need to be in agreement about it. If the vision isn't clear or compelling enough to get everyone on the bus, then you will fail. Execution is making the vision reality. It needs to be constantly guided by the vision, constantly moving towards it without getting pulled off track by side-shows and distractions.
0 Comments
Channeling Thoreau, the poet Mario Quintana wrote, "Don't waste your time chasing butterflies. Mend your garden, and the butterflies will come". Likewise it can said that success (of any variety) is the natural consequence of creating the right environment. It is not something you can go at directly. For example: if you become someone who is obsessed with providing delightful products and services, you will provide delightful products and services. If you provide delightful products and services, then you will delight customers. If you delight customers, they will buy more from you and your revenues go up. If your revenues go up, your stock price will go up. Focus on what you need to be, and the butterfly will come to you. We’ve all had the experience of thinking about all the things we need to get done, spinning through them in our heads, wondering how we’ll get them done and making headway on none.
We’ve also all had the experience of making to-do lists and cranking through the items one by one, satisfyingly checking them off the list as we complete them. When we get in a flow, we move quickly and fluidly from one item to the next, and feel sooo productive, with so much progress to show. The second scenario is a lot better. When in doubt, do something. The second scenario was better because we prioritized what we were going to do, based on urgency, easiness, bigness, you name it. Point is we prioritized and then started to make immediate tangible progress. You can’t do everything at the same time, so you have to choose what to do first, what to do second, etc. If you don’t make those choices, you don’t get things done. This is true of everything we do, including developing software. The way to be truly productive is to have a clear priority order of what you need to get done, tackle the first project, deliver it, tackle the next, deliver it, and so on. This is the heart of Lean: limit the work in progress to match the actual capacity of the team (or factory), and deliver small batches completely to the customer before moving on to the next. Not only does breaking things down into small batches (that are delivered completely) measurably improve productivity, but it feels good too. In addition to prioritizing the projects we need to deliver, we need to prioritize the goals we are working towards with the project. In project management, there is a concept called the Iron Triangle that states that you can choose to fix any two of the three corners of the triangle and the third must be allowed to flex, capturing the uncertainty of the project. Some people say the three sides of the triangle are Resources (people working on the project), Scope (set of features to be delivered), and Schedule (time to deliver), taking Quality as a fixed. Others say they are Quality, Scope, and Schedule, taking Resources as fixed. I think this discord shows that it should actually be an Iron Rectangle, with Resources, Quality, Scope, and Schedule as the 4 corners. Whether triangle or rectangle, I believe that we should take resources as fixed, for a couple reasons. The Mythical Man Month showed us that there is an optimal resource set for each project. Too many resources actually slows a project down. Too few also slows it down and will violate the Lean principle of limiting work in progress because the extra resources will start on another project and we’ll have two projects that are half-baked, instead of one that is awesome. The other reason I want to treat resources as fixed is that the concept is complex, resources themselves having several dimensions: team size, skills mix, talent/experience level, team dynamics, co-location, etc. I firmly believe that every project should be optimally resourced with a 'dream team' of the right size skills mix, experience, etc, to match the needs of the project. Having a sub-optimal team size will not only affect Schedule, but will also affect Quality, as teams that are too small tend to cut corners, and teams that are too large tend to introduce fragilizing complexity. Of course resources will not be literally completely fixed as we may discover in the course of a project an unanticipated skill and need to add that to the mix, for example. So, given fixed resources, we have Quality, Schedule, and Scope as the corners of our triangle, and we have to choose which ones to put most emphasis on, and which to let flex. My view on this is that the ranking should be: 1. Quality — Quality is job one, and without it, nothing else matters. Quality needs to be well defined for each project so that the team can treat it as a binary: they hit the bar or they didn’t. 2. Schedule — Schedule comes next, because we should be delivering small completed batches all the way to customers as frequently as we can. If we let schedule slip, we risk a project that never gets out the door and ultimately fails. Schedule slipping makes a project vulnerable to scope creep, and we get a vicious cycle of non-delivery and frustration. 3. Scope — Scope is the one we should let flex. If we can’t hit our quality or our schedule with the scope we have, then best to hold some features back, deliver what we have -- excellently -- and then get the extra features in the next cycle/sprint. There is a fallacy, called “Sunk Cost”, that people — probably most all of us at one time or another — fall prey to: that is to make decisions about the future based on past investment. I am amazed how often I hear people say something like 'Well, option A would be the best, but we’ve already invested so much in option B that we should just stick with it'. No! Your investment in option B is gone. The past is past. That cost is sunk. You can’t get it back, no matter what you do. If option A is truly the right decision from this point, then you should pursue option A, right away. Pursuing option B at this point is just “throwing good money after bad”. In my post, Platforms and Leverage, I mentioned the concept of optionality. Optionality is the essential quality of options, something I have spent a good part of my career thinking about and writing software to value and analyze.
Very basic review: in the financial world, options are contracts which pay off in some circumstances and pay nothing in other circumstances. The simplest option contract might be the lottery ticket, which is a kind of digital option that pays a fixed sum if you ‘win' (i.e. a certain random event takes place) and pays nothing otherwise. Of course, there is no free lunch, so you have to pay for that chance of winning. The value of a lottery ticket is simply the chance of winning x the payoff amount. Of course, lottery tickets are generally worth far less than the government changes for them, which is why governments make a lot of money off lotteries. Another common form of option is insurance, which pays off when something bad happens. Since you have to lose something in order to get the payoff (i.e. insurance is a ‘hedge'), it does not generally feel like winning to get that payoff. In the trading world, the most common types of options contracts are called (Vanilla) Calls and Puts. They give the owner of the option the right but not the obligation to buy (in the case of a Call) or sell (in the case of a Put) an asset at a predetermined price (called the Strike Price). Lets say you own a Call and at the end of the option’s life (the Expiration Date), the asset is worth more than the Strike Price (it’s ‘in the money’). Then you will exercise the option to buy the asset cheaply and can then sell the asset in the open market at the higher going rate, pocketing the difference. If, on the other hand, the asset price is less than the Strike at the Expiration Date (‘out of the money’), then you do nothing and let the option expire worthless. The option may have some value, potentially unlimited value, if the asset price goes up, and no value if the asset price goes down. Of course you have to pay for this chance of gaining value while taking no risk, and this upfront payment is called the Premium. Like the lottery ticket above, the Premium exactly equals the expected value of the option (but is rather more complex to calculate given the variable upside payoff amount). So the payoff is asymmetrical. Unlimited upside with downside limited to the fixed Premium you pay upfront. The fact that the upside return is unlimited, in exchange for a fixed investment, means that there is tremendous leverage in the upside. This asymmetry means that options become more valuable in risky situations. With only upside and no downside, the chances of a big payoff grow as volatility in the market increases, while the payoff of the downside risk remains flat (limited to the Premium you paid). That is why options are inherently antifragile — they gain from chaos (hence their use as insurance). They may be the purest expression of antifragility that exists. Options are more than financial contracts. They are a concept that we can use to help us understand situations. Being long (owning) options is good. They give us asymmetrical returns and make us antifragile. But you never get something for nothing -- you have to pay the Premium to get into that situation. I previously pointed out that investing in a platform and successfully attracting an ecosystem of partners to participate in that platform, gives us positive optionality: potentially unlimited leveraged upside with fixed downside (our investment). If you believe that you the chance of gaining the upside does not equal or exceed the value of the Premium you pay, then you should not buy an option. Lottery tickets are overpriced, given your actual chance of winning, and thus make no financial sense to buy. In Extreme Programming, Kent Beck says 'don’t buy options’, meaning: don’t invest in overgeneralizing your software unless you are confident you will leverage that generality (e.g. you are building a platform). Then you are paying Premium for nothing. For every buyer, there is a seller, and the seller faces a situation that is the exact opposite of the buyer, of course. The seller of an option collects the Premium (fixed upside) but faces potentially unlimited downside. The seller hopes that the option expires worthless and they simply pocket the Premium and move on. If the option ends up in the money, then the seller has to supply the asset at a price far below market rates. You sometimes 'sell options’ in business as well as buy them. For example, when you outsource, you are effectively selling an option to the outsourcer. You collect some form of savings (Premium) from the outsourcer. The outsourcer now ‘owns’ an option which will pay off if they can deliver the service for even lower cost than they are charging for it. The lower their costs, the more their upside. Generally, outsourcers are betting that their scale, industry trends, and innovation will allow them to achieve this and they’ll get their payoff. As sellers, you give up (sell) the ability to gain from scale, industry trends, or innovation. These are just a couple examples of being long (buying) and short (selling) options in business. In general, you should be on the lookout for situations that naturally make you long options and give an asymmetrical (‘unfair') advantage -- as long as the Premium investment is worth it. Selling options makes sense when the Premium you receive outweighs the likely expected downside (for example the government overcharging for lottery tickets), but keep in mind that you bear potentially unlimited risk when you sell an option (no matter what it might feel like at the time). "How do you eat an elephant?" the familiar saying goes. "One bite at a time." For the record, I am against eating any kind of endangered species :) but the wisdom of the saying is sound. We can only tackle large challenges by breaking them down into small, manageable bites and chewing those bites individually. We cannot let ourselves get overwhelmed by the immensity of the overall challenge.
In my start-ups, we tackled new software projects in this way: identify the hardest, nastiest little nugget in the project. Really boil it down to the smallest possible piece that encompasses the hard stuff. What do we think is going be the toughest nut to crack? Then we'd start building there. Just mock up a potential solution for that small tough nugget. This would be done by 1-3 people, so very focused. Basically, the project would start as an experiment to figure out how we'd tackle that really tough piece. It might take a couple tries to get it right. But it would be so focused that we'd literally see results in a couple days and iterate quickly. Once that part was done to our satisfaction, we'd define nice APIs around it, wrap it up in unit tests, and then move on. If the project had a couple of really hard pieces, we'd tackle each of them before moving onto anything else. Once we had all the really hard pieces done, we could build out from them. Since the hard parts were already done, the rest would usually be pretty straightforward solid. On a large project, you can parcel out all the tough pieces to separate small focused teams and have them work in parallel and then develop the "connective tissue" to link the nuggets together. In this way, I have seen complex products appear to magically emerge from the ether. It is a bottom-up approach to building, but to be successfull, it needs to be guided by a well-thought-through top- down vision of the project and possibly the high-level architecture, but the implementation is tackled in very small bites with a scrappy attitude and willingness to experiment to find the right solution I'm sure many of you are familiar with the concept of Read-Only Memory (ROM), where data is stored once but then accessed (read) many times. The converse of ROM is WOM, Write-Only Memory. This is when you spend time gathering data and storing it somewhere, only to ignore it, fail to look at it again, or take any action on it. This is pernicious and happens far too often. "Management reports" are a good example of something that people can spend a lot of time and effort on with no ROI. In my first start-up we coined the phrase "Write-Only Memory" and would use it as a watch-word with each other when we felt we were falling into the WOM trap in some way. Something to be on the lookout for and avoid.
In my post on 21st Century Software, I talk about "Platforms, not apps". What is the business advantage of building platforms? In a word: leverage.
Leverage allows you to maximize returns on minimized investment. But there’s never a free lunch, as they say. You have to make an investment of capital, time, or risk in order to gain the advantages of leverage. Leverage often involves getting help from others, and you usually have to do something in return for that. In financial investing that means borrowing capital from someone else to invest more in an asset than you can afford to on your own (mortgages on our houses are the most familiar form of this), but of course you have to pay interest for that capital in return. With a product platform, the leverage works like this: you make an upfront investment in building the platform and in exchange get outsized returns for marginal incremental investment. The product platform allows you to add new capabilities to delight customers more, or to start to delight new types of customers, at much lower cost -- in money and time -- than if you build and operate a brand new separate product to bring those additional capabilities to market. With decreased need for incremental investment, you can try new things out much more quickly, frequently, and cheaply, and the consequences of failure of any of these individual things goes down. Since trying things out lies at the heart of innovation, your ability to innovate goes up. With an open platform, you can get help from others. Customers and partners add value to your platform (for example, by integrating their content and building their apps on the platform), driving increased sales and stickiness for the platform, in exchange for making it cheaper and easier for those partners to innovate and to bring their capabilities to market. Others take the innovation risk and put in the work. And since innovation is powered by trying things out, your platform can benefit at another level by having multiple partners doing similar things and letting the Darwinian forces of the market reward the best one. That moves beyond leverage to something even more powerful: optionality. It costs more (requires more investment) of course, but optionality gives you leverage on the upside plus protection on the downside. It creates an asymmetrical ("unfair") advantage. So if you want to generate outsized returns for low incremental investment, build a platform. If you want to maximize that leverage, go all in on it. And if you want to harness the help of others to increase leverage even further and decrease risk, make your platform open. I was reading some of the Greek classics for a high school literature class when our teacher made us look hard at the notions of good pride (Megalopsuchia) and bad pride (Hubris), which we referred to as "pridefulness" in that class.
Basically: Pride = good. Being proud of your accomplishments is caring, and caring is the foundation of quality. Pride is the just reward for a job well done. Pridefulness = bad. Being prideful is being arrogant and closed minded and putting yourself above others. In the Greek tragedies, it leads inexorably to an act of folly (Atë) which brings about destruction (Nemesis). In business, the critical values of professionalism, collaboration, openness, and collegiality are not compatible with pridefulness. The antidote to pridefulness is humility. So be proud of the good work you do, the way you do it, and the results you achieve. Celebrate success with enthusiasm. But be always humble. In the 15 years or so, our interaction with -- and feeling towards -- consumer software has changed dramatically. If we look at what firms like Apple, Google, Amazon, Facebook and others have given us, it is a very far cry from the gray, gorpy Microsoft applications of old. There has been a sea-change in personal technology.
Some of the characteristics of this 21st century software are:
|
AuthorPhilip Brittan is the General Partner of Crazy Peak LLC Archives
February 2021
Categories |
Copyright (c) 2016 Crazy Peak LLC |