Archive for the ‘Business’ Category

h1

Tools, Not Rules: How Not to Use Business Cases

02/11/13

ImageA few months ago, some friends were waxing poetically about the virtues of Apple’s business model as described in Inside Apple. (I swear this is the last Apple-related post for a while.)  All work is done by small teams, with a directly responsible individual for each project. Apple works in great secrecy–even from other Apple employees–in order to surprise the public. In order to keep focus on the core products, Apple has only one P&L. Clearly, Apple had cracked the code on running a business correctly, and the proof was in the products.

But there was a dissenting voice. Ray Girn, the CEO of LePort Schools and one of the most extensive business book readers I know, said that he could cite examples from other businesses where the opposite was the key to their massive success: large and inclusive teams, transparency, multiple P&Ls. I asked Ray what he thought was the right way to run a business, and he said that he thought LePort had gotten some things right but he was still figuring that out.

Aside from that question, I basically stayed silent through the conversation. Which is sort of awkward when your job is to have answers to these kinds of problems. But I’m increasingly playing with the idea that the problem is in the question. Perhaps there is no right answer to how to run a company.

So does that mean I’ve given up, that I should turn in my business consultant merit badge and accept that success is a matter of luck and no lessons can be learned from others’ successes? Of course not. But I think it’s better to view these business techniques as tools. Just as a successful carpenter has a giant bag full of hammers, mallets, and screwdrivers (and Phillips head screwdrivers and 20 mm Phillips head screwdrivers), a successful business person has learned many techniques. Further, just as that successful carpenter knows when and why to use a hammer versus a mallet, a business person is also a craftsman knowing when and why to use the different techniques.

To give an example, let’s look at the focus on small teams in Apple, with one person directly responsible. These allow the project team to get things done quickly, without having to worry about the endless levels of bureaucracy that burden most companies. The obvious dogma from this: all work should be done in small teams at all companies. But you can find examples of the value of large teams even within Apple. Every Monday morning, the top executives from Apple spend the entire day reviewing the status of every project. They do this so that all of leadership is on the same page about what is happening and what the priorities are, lest the company become splintered into competing fiefdoms. Small teams can work nimbly; large teams can all work on the same page. Studying Apple’s success ultimately doesn’t give us universal rules but demonstrations of cause and effect, in a specific situation. Philosopher Greg Salmieri once told me that real problem of generalization is figuring out under just what circumstances something is true.

This is important for me to keep in mind as I study businesses and advocate the techniques to JetBlue. Secrecy, for example,  would destroy JetBlue’s super-open culture. We give hugs freely and talk about our work casually, and that is right for us: a happy, supportive culture leads to a happy, supportive approach to Customer Service. But smaller teams and directly responsible individuals to increase speed? It’s an interesting question how we could do more of that, and Apple makes an interesting case study.

One caveat to all of this: I haven’t given up on the idea of universal laws of business. I suspect that those universal laws would have to do with the one thing all businesses have in common: people. My best candidates right now for universal laws would be that workers need to be motivated, have clear goals, and have the skills to do the job (even if that skill might be simply the ability to learn).

Pretty simple and almost self-evident. But the interesting guidance comes in how you do those things–when does a clear goal mean giving a teammate a specific solution to execute versus giving that teammate a specific problem to solve? It depends. What are the circumstances, and what are you trying to achieve? But if you can move to a tools perspective and really understand both techniques, then you have options.

%d bloggers like this: