In my opinion, the top three factors driving company success are:

1. Right People
2. Right Culture
3. Right Mission

in that order. The right people are the foundation of anything. It is always all about the people. Right people can operate well within a range of cultures. Great culture + wrong people doesn't work. Right people plus right culture, and I think you can do anything. Put the right mission on top of that and you are set up for maximum success.
So culture really matters. But what is culture anyway? The term was apparently first used by Cicero in the phrase 'cultura animi' meaning the 'cultivation of the soul'. Cultivation here is very much in the agricultural sense — it is all about growth. Culture is fundamentally about getting better over time, and the right culture is the fertile soil in which the right people succeed and prosper.

That ‘soil’ is the set of values and ambitions we have that we believe will make us better, that will allow us to grow and prosper. These beliefs, values, and ambitions guide our behaviors which in turn produce the successful outcomes we strive towards.

In short, culture is a shared way of being for a group of people that allows them to grow and succeed. The shared aspect of culture is central to it. It’s not a culture if one person in a group has one set of values and ambitions and the person next to them has a completely different set. Humans beings are at our best when we work together. We defend better, we hunt better, we build better, we educate better. Collaboration is in our very nature. But to do it effectively, we must be in sync with one another, and our shared culture is the best tool we have to ensure that we are in sync and working towards common purpose.

So what is that ambition we strive for? At the highest level, I believe people want to win. That is our driver. Now, different people will have a very wide range of views on what ‘winning’ means to them in their lives overall. But in a corporate setting, I would suggest there is probably a more cohesive view on what winning is: creating and delivering products and services for our industry better than anyone else, in turn delighting customers more than anyone else, and in turn being appropriately recognized and rewarded for that accomplishment. And we probably all want to feel that we are growing as individuals, feel proud that we treat other people decently, that we are making the world a better place, and having fun (enjoying what we do and the time we spend at work). So our culture should be the fertile soil that allows us to attain that form of winning.

Stay tuned for a series of posts in this blog to summarize a few core cultural themes plus some specifics about what I mean by each, with the goal (as always) of trying to incite some discussion and debate among all of you who read it...

Culture, part 2: Truth
​Culture, part 3: Excellence
Culture, part 4: Agility
Culture, part 5: Confidence
Culture, part 6: Service
Culture, part 7: Leadership
Culture, part 8: Passion
Culture, part 9: Collegiality

As buy-side and sell-side firms continually search for new ways to gain insight into the markets, they are turning to an ever-widening array of data: new forms of financial data (prices, fundamentals, etc) and also non-financial data (weather, parking lot occupancy, etc) that are financially-relevant.  I am working with a number of clients who are looking for new "alternative" sources of financial and financially-relevant data.  If you have a novel data set that you believe should be of interest to financial firms, please let me know about it.

“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.

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.