John Siracusa handicaps the players in the mobile industry based on their dependencies on other companies. This is an interesting basis for analysis that could be applied widely.
I generally find the way stocks are priced to be a joke, and press coverage of the stock market to be an even bigger joke. My favorite recent example is today’s New York Times’ Common Sense column, which talks about herd mentality in analysts rating Apple’s stock as a Strong Buy right up until the shares fell off a cliff recently.
Notice the lack of coverage of Apple’s business fundamentals — the discussion is of the performance of the stock compared to the predictions. That’s topped off by extensive quoting of an analyst who did pick against Apple, without any kind of data-founded discussion of his performance overall. He was right about Apple’s recent share value, but we have no idea whether he’s right or wrong about anything else.
Corporate management at public companies is judged based on stock performance, but except in extreme cases, both stock prices and the coverage of them is almost completely divorced from the actual performance of these businesses.
I think a more interesting column would take a more data-centric approach. How does Apple’s share price compare to its financial results? How does that compare to other companies in the same business? How have the various analysts discussed in the article performed over time in terms of stock predictions? The column asks low quality questions and thus yields uninteresting answers.
Matthew Yglesias writes about the fact that Android is massively successful and yet loses money for Google. This reminds me a lot of Sun and Java. Java is one of the most successful programming languages ever introduced, and indeed practically spawned an industry unto itself. Furthermore, many, many companies have made money using Java in all kinds of ways. The funny thing was that Sun never really made any money with Java. It didn’t enable them to sell hardware, or server software, or development tools. It’ll be interesting to see what Google does with Android in the long term.
Update: From the comments, Horace Dediu breaks down Android as if it were an independent company. As a business unit, it is profitable.
China has deployed its own aircraft carrier. The vessel is a rehabilitated Ukrainian carrier that China purchased in 1998. Unfortunately, China does not have pilots who have practiced landing a plane on an aircraft carrier, nor do they have any planes that are capable of landing on an aircraft carrier.
What’s the point? That it’s a lot more difficult to develop a capability than it is to build something. The obvious recent example from technology is the launch of Apple’s Maps application. Apple developed an iOS app that has all of the features one would expect from a cutting edge mapping application but they lack the capability to keep their own set of world maps accurate and up to date. For more on this, check out David Talbot’s article on the challenges involved in building a legitimate mapping application. As it turns out, most of the work is in building that capability.
The United States has been working on aircraft carriers for over 100 years. Not only can we build aircraft carriers, but we can also build the right planes, train the pilots, and train the rest of the crew of the aircraft carriers, many of whom also have very specialized skills. The US Navy also has the logistical capability to send an aircraft carrier most anywhere in the world along with the attendant fleet of ships to support and protect it. (For more, see the Wikipedia article on carrier strike groups.) China may have an aircraft carrier, but how long will it be before they have the equipment and expertise to conduct a pitching deck exercise?
From a software development perspective, it’s worth thinking about capabilities when you’re talking about projects. As I mentioned the other day, I’m currently working on analytics. It’s easy enough to set up Google Analytics on your Web site, but developing the capability to understand the reports and incorporate the analysis into your product plans is much more difficult.
That’s only the tip of the iceberg. There are other, specialized third party analytics tools, and from there, custom analytics software and data analysis. Beyond that, there’s the statistical math required to draw accurate and useful conclusions from the data you’re gathering, and spreading an understanding of how the math applies throughout the organization. There’s also the task of changing people’s approach so that they rely on data rather than anecdotal evidence when making business decisions.
Often it’s the case that the larger (or older) an organization is, the tougher it is to add a capability in the first place. It’s harder to teach 100 developers to use Test Driven Development and rely on continuous integration rather than traditional QA testing than it is to teach 5. It’s also harder for larger, older, or more conservative organizations to rely on a new capability that has been developed. It often happens that organizations put a lot of work into developing a new capability but they never really get comfortable enough to let it replace an old one.
If nothing else, when you’re discussing projects, it’s worthwhile to ask yourself whether the project leverages an existing capability or requires developing a new one, and planning accordingly. If a new capability is required, both the effort and the risk of failure rise significantly. I’d be willing to bet that Chinese aircraft carrier is never put into active deployment.
Why can’t companies like Google, Apple, and Microsoft find ways to spend the tens of billions of dollars they have in the bank? That’s the question Peter Thiel asked of Eric Schmidt at a recent event. The fact that these huge sums of money are being parked by the biggest companies in technology is a problem for US productivity and employment and it’s a sign that the pace of innovation in tech is not where it needs to be.
That said, even if good ideas abounded, it would be difficult to put the money that’s already in the bank to use quickly. Even $1 billion is a lot of money to spend. You could use it to hire more than 5,000 engineers for a year. What would you put them to work on? How would you even scale up such a team if you had a project? There just aren’t that many shovel-ready projects available.
Apple put another $7.2 billion in the bank this quarter. That’s a symptom of something.
I, like many people, thought that when Ron Johnson left his job running Apple’s retail operation to take over JC Penney, he’d turn things around completely. Not long after he took the job, he promised to completely remake the department store experience. One of the biggest experiments he tried was completely bucking the industry trend when it comes to pricing.
In January, the New York Time ran an article explaining Johnson’s plan, which involved simplifying the pricing structure and eliminating most large sales and promotions relating to those sales. This sounded like a great idea to me. The idea of going into a store and buying things without wondering whether I could get a better discount later by gaming the system seemed like a relief.
Based on the early results, I was completely wrong. JC Penney’s since they changed their pricing model have been incredibly bad. MSNBC’s Bob Sullivan explains why, in an article about price shrouding. In short, people feel like they get a better deal when they’re playing the game. The open question remains whether JC Penney is suffering poor results now but will rebound once consumers better understand what they’re doing. I wouldn’t count on it.
I think the lesson here for any product designer is that we have to really understand human behavior when we’re making decisions that depend on it. The Apple Store sells products that cannot be purchased more cheaply anywhere else. Furthermore, Apple’s profits are roughly the same whether you buy an iPod at an Apple Store or you buy that iPod at Best Buy. JC Penney does not retain either of those advantages.
Stephen O’Grady has a piece today, Software is the New On Base Percentage, which proposes that effective use of software is no longer a way for a business to gain a competitive advantage, but rather the price of entry for being a viable market participant.
It begs the question, how does a company gain a competitive advantage these days? My argument would be that the most effective approach is to recruit and retain creative people, and to free them to do their best work. I think this is the real lesson for any business in the Valve employee handbook. Yes, I’m talking about it again.
Valve’s employee handbook is, as much as anything, a recruiting tool. It’s a promise that if you have good ideas, nobody at at the company is going to stand in your way. That’s a great pitch.
At Etsy, we find that the people who are the easiest to recruit are the ones who read the company’s engineering blog, Code as Craft, tried to apply things they learned at their own company, and eventually gave up and just looked for a job at Etsy instead.
Companies that put obstacles in the way of people solving problems find that the first rate employees look for other jobs, and that second rate employees devote their time to using Facebook rather than looking for ways to make things better.
The most effective way to gain a competitive advantage at a company is to create a culture where employees are free to use as much of their brain as they want to build value for the company.
I’m just going to keep posting stuff about Valve until I get tired of it.
Did you read the Valve employee handbook? If not, you should. To catch you up, at Valve, the corporate structure is completely flat. They have no managers, and everyone decides what to work on for themselves. The handbook explains what is expected of Valve employees and how people should adapt to that corporate structure.I’m sure some people find it intriguing and others terrifying.
Succeeding at Valve depends on two things, the application of one’s judgement and influence. Employees use their judgement to decide where they can add the most value for Valve. They use their influence to recruit other people to help them build the things that they have decided are valuable. Find a problem to work on, convince other people to help you solve it. Nobody is empowered to order anybody to do anything.
What occurred to me after reading the Valve handbook is that you or I can work in the Valve style regardless of where we work. If you work anywhere but Valve, you probably have a manager and you may have people who you manage as well. Within the constraints of your job, though, you should be relying on judgement and influence rather than hierarchy in your work, just like a Valve employee does.
If, in your judgement, there’s something more valuable you could be working on, you should be convincing people (like your boss) that your time could be better spent working on that other thing. Just be sure that you’re open-minded enough to accept that your judgement could be mistaken. If you’re right, though, it ought to be easy to convince people that your time could be better spent on a more valuable project.
At the same time, rely on influence rather than authority to get the help you need to get your work done. People generally do better work if they believe in the project they’re working on, and the ability to recruit volunteers is a good sign that whatever you’re working on is worth doing. People sometimes mistake interesting for valuable, but it’s always better to work with enthusiastic volunteers than with people who are doing something just because someone told them to do it.
Obviously if you work on an oil rig or at Burger King, this approach may not work. However, the field I understand best is software development, and if you’re working on software, you should the Valve philosophy to heart. Use your judgement and influence to make sure you’re adding as much value as possible at your job. If that gets you into trouble, maybe it’s time to use your judgement and influence to land a job more suited to your talents.
We’ve heard that other companies have people allocate a percentage of their time to self-directed projects. At Valve, that percentage is 100.
Very much worth reading.
Lane Becker and Thor Muller have a new book out about the importance of harnessing serendipity — making your own luck. Becker explains why startups are better positioned to do so than established businesses in an interview with the New York Times’ Nick Bilton:
It’s a problem for start-ups as they grow and become a traditional business, because most businesses succeed through repetition, process and routine. But all of those things are designed for rote predictability. So we engineer our businesses to squash the role of serendipity inside their organizations. Even start-ups, when they get big, and they stop listening to your users, fall into a process of repetition.
I was struck by this explanation because today I also read Michael Abrash’s blog post on what it’s like to work at the game company Valve. It sounds like Valve is structured to cultivate serendipity in exactly the way Becker describes:
If most of the value is now in the initial creative act, there’s little benefit to traditional hierarchical organization that’s designed to deliver the same thing over and over, making only incremental changes over time. What matters is being first and bootstrapping your product into a positive feedback spiral with a constant stream of creative innovation. Hierarchical management doesn’t help with that, because it bottlenecks innovation through the people at the top of the hierarchy, and there’s no reason to expect that those people would be particularly creative about coming up with new products that are dramatically different from existing ones – quite the opposite, in fact. So Valve was designed as a company that would attract the sort of people capable of taking the initial creative step, leave them free to do creative work, and make them want to stay. Consequently, Valve has no formal management or hierarchy at all.
It’s brilliant when it works. I think that Becker is wrong, though, when he says that repetition, process, and routine are the enemies of serendipity. Building the wrong kinds of structures and processes have been responsible for crushing serendipity in many organizations, but the right kinds of processes (or if you prefer, habits) are necessary parts of maintaining the possibility for serendipity as a company grows.
For example, from an engineering standpoint, Etsy’s core practice is continuous deployment. Regardless of whatever else is going on, developers are always testing code, checking it in, and pushing it to production, many, many times a day. It’s that process that enables the company to continue to rapidly iterate even though the engineering team is growing. The process for pushing code is rigid and everyone follows it every single time they need to deploy something. It’s that process, though, that liberates people to be creative as individuals.
I’d be willing to bet that Valve has any number of processes or ingrained habits that serve the same purpose. People there obviously understand how to form teams without being told what to do. They have a common understanding of how Valve writes software that enables them to contribute to any project that the company is working on. Valve creates software that ships in big monolithic releases — engineers there clearly understand what’s expected at each phase of the project so that they can ship.
Of course, I’m responding to one short paragraph from the interview — I haven’t read the book. I think, though, that from a distance people look at creative companies like Valve or GitHub (which I plan on writing about some other time) and think mostly about the liberties people are allowed to take. My guess is that in large part, their success derives from the adherence to norms that are deeply embedded in the cultures of those organizations. Because the team members voluntarily adhere to those norms, they don’t stifle individual creativity.
If this sort of thing interests you, check out the book — Get Lucky.