Archive for February, 2013


Tools, Not Rules: How Not to Use Business Cases


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.


Design vs. Leadership: The Curious Case of Steve Jobs



One of my favorite reads of the last week was this description of working with Steve Jobs. The conclusion hit me with a big “Of course.”

“That is what I remember most about Steve, that he simply loved designing and shipping products. Again, and again, and again. None of the magic that has become Apple would have ever happened if he were simply a CEO. Steve’s magic recipe was that he was a product designer at his core, who was smart enough to know that the best way to design products was to have the magic wand of CEO in one of your hands. He was compelling and powerful and all that, but I think that having once had the reigns of power wrestled away from him, he realized that it was important not to let that happen again, lest he not be allowed to be a Product Manager any more.”

I worked through several hundred pages of Walter Isaacson psychobabble about the source of his impatience and poor treatment of others, and the answer is so much simpler than rage at being adopted or whatnot. Jobs was a designer who became CEO out of necessity and never figured out how to reconcile the tension between them (and maybe never cared to).

Designing and leading are very different modes of action. I say this both from my observations of people who are good at each and from my personal experiences.

Designing benefits from having the shortest distance possible between emotion and action. A good brainstorming session is five people in a room bubbling with new ideas and suggestions for improving others’. It is exciting and incredibly satisfying, though I also find it often frustrating along the way. You have a sense of what good would feel like, and you ain’t there yet. So that frustration drives you, generating new ideas that might get you to good. Stanford’s d. School emphasizes quantity of ideas and speed, and these both come from being very connected to your emotions.

Leadership benefits from having a long distance between emotion and action. As a leader, your every action impacts the people that get things done, and  acting emotionally means acting without really considering whether you are taking into account each individuals’  needs or the team dynamic as a whole. The best leadership I’ve seen has come from a quiet person listening, distilling a room full of drama to two or three key points, and making the unsolvable solvable.

That doesn’t mean that leadership is unemotional. Far from it. Leadership starts with caring about the goal and the people executing it. It continues with the same kind of excitement and frustration at things going well or badly. But I think that emotion always needs to be checked against your understanding, and that takes time.

It sounds like Jobs led as a designer. From “Inside Apple,” it sounds like this extends not just to designing amazing products but to an amazing company as well (their Monday meetings reviewing every product with all execs are genius). And in leading others, it sounds like he often acted too quickly from his emotion, calling someone a “genius” one second and a “bozo” the next–the same kind of swing between excitement and frustration that drives a designer. But in applying this to people, you come across as erratic, demoralizing, unfair. Good thing that he designed a company with so much opportunity for others to do great work that people were willing to suck it up and deal.

This raises an issue: how do you merge the two together and be a good leader of design? Is it a swing between acting emotionally and acting thoughtfully? Is it about understanding the design process but giving up your role in it so that you can focus on getting the most out of others?

My best assessment: I think it’s probably a bit of both–leadership skills and design skills are both tools that you have to have at the ready based on whatever is needed from the situation. As always, the goal is king. But I’d be curious to hear from any leaders of design out there.

%d bloggers like this: