Spreadsheet Parable
Early on during my time at Carlypso, the company had a lot of internal divide. Each afternoon, the marketing guys would post car ads for the next day. But the sales team didn’t know what cars were being advertised, or at what price. So people would call in and say “Hey I saw your ad for a 2012 explorer for $20k, does it have a backup cam?” and the sales guys would be like “Umm…”. We had a hundred explorers available at any given time. Sales had no idea which ones were advertised, or the prices at which they were advertised. Every customer who called in had seen a particular car advertised, but the sales team had no idea which one.
This problem was brought before the dev team. At the time, ads were posted using a few hacked-together python scripts and a lot of excel. The dev team came up with a plan to replace that with a heavily automated ad pipeline, which would record all the ads to our database before posting them. As a separate project, we planned to create a new interface for the sales team to browse our available cars, including the ability to specifically search for cars which had been advertised.
Alas, this solution involved not just one but two significant projects, and the dev team was somewhat dysfunctional on top of that. A month later, neither project had even been started.
One day our project manager, Joe, walked over to the marketing room. He sat down next to Rogue (who usually posted the ads).
“Hey”, Joe asked Rogue, “when you’re ready to post today’s cars, do you think you could copy all the data into a google doc spreadsheet and share it with me?”
“Yeah sure”, replied Rogue, “I have a spreadsheet with all the cars we’re going to post anyway, since that’s the last step before posting. I’ll just copy that into a google sheet and send you the link.”
So Rogue shared the sheet with Joe. Joe sent it along to the sales team. And the next day, the sales team knew exactly which cars had been advertised, and at what price. The sales team was ecstatic. From then on, Rogue sent the spreadsheet directly to the sales team each day. For months, that was the system. It wasn’t perfect, but it fixed 80% of the problem with five minutes of work and without writing a single line of code.
Economic Bottleneck
What is the most significant bottleneck in the modern economy?
As a first approximation, there’s an easy way to answer this question: look at what sorts of activity are worth the most money. All else equal, the most money will flow to people in very high demand and very short supply, a.k.a. people who directly address the largest economic bottlenecks.
I’ve written about this before; the general pattern is that large amounts of money go to people who solve coordination problems. Entrepreneurs, upper management, investment bankers, real estate developers… pretty much anyone who makes the big dollars is primarily in the business of coordinating people. Upper management coordinates between departments and teams within a company, or between varies parties in a supply chain. Entrepreneurs coordinate between investors, employees, suppliers, customers and regulators. Investment bankers coordinate between multiple companies, and between investors and companies. But the central pattern is the same: it’s all about coordination.
Furthermore, this applies in almost every industry. No matter where you go, the same pattern applies: it’s the coordinators who make the money.
But now let’s go back to the economic bottleneck question. If the big money goes to the people who solve coordination problems, then that strongly suggests that coordination problems are the central economic bottleneck in almost every industry today. Think of it like revealed preference: if you’re willing to pay more for steak than for chicken, then presumably you prefer steak to chicken (or at least, one more steak over one more chicken). If the economy as a whole pays dramatically more for a coordinator than practically anyone else, then presumably a coordinator is worth more. In other words, coordination problems are the central economic bottleneck.
Everyday Application
Think about what this means for everyday business. Whatever business you’re in, whatever company you’re at, the primary bottlenecks at your business are probably coordination problems.
Once you start looking for this, you see it everywhere. Consider the story above, about Joe and the spreadsheet. Joe asked Rogue to send a spreadsheet of cars advertised out to the sales team. That took five minutes of effort on Joe’s part, and solved a major business problem. It may very well have been the highest value-per-minute work which Joe ever did at Carlypso. All it took was to notice a coordination problem, and solve it in the simplest possible way.
So, if you want to add lots of value to your current company, then the natural starting place is to look around for coordination problems. Here are some starting points:
- Is there information which some people have and other people need? This is particularly relevant for software teams, since this is the main type of coordination problem which can be solved by software. There are three subtypes to this kind of problem:
- Within the company, do some people have information which other people need? This was the case with the Carlypso example.
- Is there information available from outside the company which is needed inside? In software, this is usually solved by integrating internal tools with an external API. Sometimes the problem can be solved just letting people inside the company know where to find the information.
- Does information need to move between two external parties? Often, entire companies exist solely for the purpose of collecting information from some people and presenting it to others.
When building these sort of information pipes, the first and most important step is just getting the pipe in place; that’s often an 80% solution. The other 20% is the next item...
- Are there communication difficulties? I.e., is information flowing from A to B but being presented in a way which is hard to understand/use? This problem can range from poor conversational skills, to different people using different jargon, to the entire field of user interface design. Communication difficulties are often most noticeable between people with different specializations, discussed next.
- Are different specialized groups supporting each other as needed? A couple common examples:
- Do software developers understand the needs of whatever people they’re writing software for?
- When a product or customer is passed between groups in a pipeline (i.e. lead to sales, order to fulfillment, etc), is any information lost? Is the receiving group aware of any special conditions? Is there a long wait time between groups?
One general rule: when tackling these sorts of problems, avoid playing telephone. For example, it’s tempting to have a product manager research the needs of software users, and then write up exact specs for the developers… but we’ve all played telephone before. Things ALWAYS get garbled. To avoid telephone, communicate goals rather than specs as much as possible. In the product manager example, a spec is useful, but more important is the reasoning behind the spec… if the developers know WHY the spec is designed this way, if they understand the goals driving it, then things will be much less garbled.
- Are people working toward different goals? This one is often a balancing act, since most managers instinctively want to push everyone into line, but that’s only valuable to the extent that the one line is pointing the right way. Often, it’s more valuable to have people pursue different directions, since there’s a higher probability that one of them will hit on a really good direction. That said, when different groups of specialists need to coordinate to achieve a goal, then it really is important to make sure everyone sees the same goal… you don’t want one group building a square peg and another group building a round hole.
No comments:
Post a Comment