You are here: Home / Archives for 1x

Cater to Your Personal Pathologies

June 6, 2013 by 2 Comments

Managing your time, I’ve found, is mostly a psychological problem rather than a logistical one. Many books lay out a particular system – from the Covey quadrants to David Allen’s 43 folders to a sea of nifty acronyms. What I’ve found from trying them out, and watching others try to use them, is that a system only works if it matches your particular needs. More specifically, if it caters to what I call your pathologies.

We all have some idealized version of ourselves that we aspire to be. This paragon of virtue may never procrastinate, or always rise above temptation .. whatever takes your fancy. Then there is the actual, flawed, imperfect person we actually are. Many people try to use a system that ought to work, rather than one that does work (for them). Hence a sea of unused DayTimer notebooks, mountains of abandoned organizational gear, and endless hopping from one To Do app to another. If cosmetics are “hope in a jar”, then organizational tools are “hope in an app” (or for the traditionalists, “hope in a binder”).

So what do I mean by pathologies? I don’t know what yours are, but I’ll share some of mine.

I Hate Clutter

Some people feel comfortable surrounded by things. They naturally keep papers in piles and leave lots of things lying out on desks. Not me – I like a spare and streamlined work environment. How does this relate to being productive? A friend of mine built an elaborate set of rules for sorting his email. Messages were passed automatically to a lovingly organized cascade of email folders. It worked well for him and was really cool, and I thought I’d give it a try, too. Result: disaster.

All my mail would come in, be sorted into the appropriate category, and I would look at it and be soothed by its orderliness. The problem is that I achieved this calm and pleasing result without actually doing anything. I had to throw away the whole thing and go back to having everything pour into my inbox and annoy me. Then I would be motivated to clean it up, by actually looking at the mail, making decisions, and taking action.

I Like To See My Whole World in One View

When I’m figuring out what to do, I like to see everything that matters all at once. I get stressed out when there are things I need to be thinking about, but they aren’t in front of me so I’m not sure I’m remembering all of them.

I like to plan out my week every Monday morning, and for many years, I have used two facing pages in my notebook to show: the big projects I’m responsible for, any deadlines for the week or in the near future, active to do items, key appointments, top priorities for the week, and top priorities for each day. It is a challenge to capture all that in two pages, but I’ve found it to be a really good exercise – it forces me to think about what’s important and distill it. Each time I have a new kind of role, I have to change those two pages. What I needed to capture when I managed a big team was radically different than when I’m a team of one in a startup and mostly work by myself on a set of projects. I keep those two pages open on my desk most of the time, so I’m always reminded of the most important things that I’m supposed to do that day and that week.

I could keep going for a while (I like to write and draw on paper, I can’t use bound journals because pages can’t be inserted or rearranged, ..), but I’ll spare you, because the important thing for you is to figure out what your pathologies are.

Sleuthing Them Out

A good way to start is to ask yourself:

  • What system has worked well for me? What did I like about it? Why did I like using it?
  • What didn’t work? Did it fail (you kept forgetting to do something important), or was it too much overhead, or did you just stop bothering with it? Why?

Remember, this is not about some idealized vision of yourself, or what works for somebody else – this is all about you. When you answer these questions, especially the second one, try to avoid value judgments – it’s not constructive to beat yourself up with things like “I’m lazy” or “I suck at organization”. Stick to thinking about what you have tried, what worked, and (for the things that have not) why they failed you.

The answers might be psychological (“I like writing things on paper because it is more visceral and I feel more committed to getting it done”) or mundane (“I didn’t carry around the binder because it was heavy and didn’t fit in my bag”). Don’t scorn the details – your whole system can founder if you just don’t like using it. If the color of the notebook bugs you, or you have a fetish for fountain pens, pay attention. If you are using an app, the details of the user experience matter a lot. “This app made me set up all these categories and I just got lost – I need something simple.” Or “I hate looking at the interface – it’s ugly”.

Your “system” might be very informal – maybe you like post-it notes on your monitor. Or piles on your desk organized a certain way. As long as it works for you, that’s what matters. Try to figure out how to eliminate any friction that prevented you from using (or wanting to use) some solution. Try to enhance any quality that you really like.

At the end of the day, the measure that your approach works is that you know what is important and you get it done. Then you have created a magical accelerant for your life.

Filed Under: 1000x, 100x, 10x, 1x Tagged With: ,

We Pace Within The Bars of Our Own Imagination

January 28, 2013 by 2 Comments

Have you ever heard somebody say, “I wish I could <do something or other>”, with a wistful look in their eye?  And you want to grab and shake them and say, “you CAN.  Do it NOW!”  And it is just so obvious to you that what they wish for is right there in front of them, ready to be seized if only they would have the gumption to reach for it.  Well, guess what: a lot of the time, you are that person.

We are the biggest buzzkill and the harshest critic standing between us and our dreams.  We shrink back from the echoes of old failures, from carping and doubting voices that ring inside our heads.  “I’m not the type who starts a company.”  “I’m not a natural leader.”  “I’m not creative.”  “I’m not a good writer, or an artist, or an athlete.”  We fence ourselves in behind these imaginary barriers, looking wistfully at the banquet of delights that we think is permanently locked away from our reach.

So What do You Want?  Really Want?

A fun way to start breaking through is to do a little fantasizing.  Try finishing these sentences:

  • “Of course it isn’t practical, but I’ve always wanted to …”
  • “I don’t do it any more, but when I was a kid I always loved to …”
  • “The times in my life when I was most exhilarated and at my best, I was …”
  • “In my dream job, I …”
  • “In the life that I daydream about, ….”

Get something down that you can look at.  Maybe write a journal entry on paper or on a computer, mindmap on a white board (with an encouraging friend, if that works for you), or draw on a big piece of paper, or collage a poster full of pictures.  Find some cool images on the Internet.  Whatever gets your juices flowing.

We’re not trying to be practical here, we’re trying to dream a little.  Always wanted to be an astronaut and explore other galaxies? You are five feet tall and walk with a cane, but fantasize about being an NFL running back or an Olympic athlete?  It’s all good.

After you’ve had a shot at this, and you sit back and take a look, you might suspect that some of your fantasies are a lot more fun in your imagination than they really would be in practice.  That’s probably true.  There is a reason that the phrase “it reads better than it lives” comes up a lot in adventure tales.  But you’ll never know until you try something, whether you will really like it.  And you may stumble across some related activity that is even better.  I backpacked quite a bit when I was in school, living out some fantasies that I had when I was a kid.  I discovered that backpacking is fun, but what I absolutely loved was rock climbing.  And I did quite a lot of it, in some amazingly beautiful places, and had adventures that I still often think about.

It takes a bit of work to figure out what will make you happier and more fulfilled.  You don’t have to – there are intelligent and highly paid people working hard to take care of that for you.  Their siren song is everywhere – how great your life will be if you have a fancier car, a bigger house, more fashionable clothes, and glamorous vacations.  There is overwhelming evidence that these things won’t make you happier, but perhaps you are the exception.  Run, hamster, run .. maybe you will get there, if only you can make that wheel spin a little faster!

Life Isn’t All or Nothing

One of the traps that I see people fall into all the time is being much too black or white about their dreams.  “I want to be an Olympic downhill skier, but I’m 40 so obviously that’s not going to happen.  So instead, I’ll have beer and chips on the couch.”  Uh huh.  Or, somebody is working full time and is a parent so they decide that their dream to be an artist is hopeless.  But you don’t have to be a full-time artist in order to make art.  If you are fascinated by outer space, you can study astrophysics, go to lectures, paint scenes set on other worlds, go to space camp, build your own telescope, and visit observatories.

If you love something, then weaving aspects of it into your life can be richly fulfilling, even if you can’t do it all the time or do it to the level that you fantasize about.  After all, even an Olympian only gets to compete in the games for a couple of days every four years.

Just Take a Step

Now you come to the crucial all-important step that so many people leave out.  They have dreams, but they don’t turn vision into action.  A grand goal like “become an artist” or “write a book” is great, but you can’t sit down on Monday afternoon at 2pm and become an artist.  You have to turn those ideas into concrete actions you can do right now.

To become an artist, maybe you need to research art classes at a local school or get an instruction book on some techniques you want to learn.  If you want to start a company, attend a local get-together of entrepreneurs or read a book about it.  I like to think about this as “just take a step”.  Write down everything you can think of that you know exactly how to do and can get done in less than an hour.  A big goal may seem impossibly daunting if you think of it as a whole, but surely you can spare an hour?  And then, after you’ve spent one hour, pick the next thing and spend another one.

Magic of Starting

There is a wonderful quote, which is commonly attributed to Goethe.  Sadly, that’s not exactly true.  But it’s great anyway, even if it has a mixed ancestry, and I have repeatedly found it to be true: “Whatever you do, or dream you can do, begin it.  Boldness has genius, power, and magic in it.  Begin it now.”

Filed Under: 1x Tagged With:

Kissing Frogs Part 2: Conducting the Interview

December 3, 2012 by Leave a Comment

You’ve done all your prep, and now the candidate is sitting there looking at you.  You have an hour, at the end of which you are supposed to have a smart and insightful analysis on whether to hire them or not.  How do you spend your time?

Have Them DO Something – Don’t Ask General Questions

One of the most common mistakes is to ask open-ended softball questions.  “What are your strengths and weaknesses?”  The candidate then babbles on about how disciplined and passionate they are, and how their big weakness in life is that they just work so hard, and take things so seriously – they struggle under the burden of an extreme work ethic that was just the despair of their former managers.  And now several precious minutes of your interview are gone, and you haven’t learned a darned thing.

I think it’s infinitely better to ask them to create something.  Write code on the board for a multi-threaded lock implementation.  Write the Javascript code to update the notification count when a new message arrives.  Design a UI for managing notifications.  Design a set of metrics to monitor the state of the business.  Create a plan to track and land a milestone.  Whatever is appropriate for the job you need them to do.

If the design involves a skill they need to have, you will quickly see whether they really have it.  Many people can do a lovely job describing a design they know but are lousy at creating one.  Confronting a blank white board and having to invent something on the spot cuts through a lot of blather.  If it’s a skill they are still learning, you will also discover a lot in watching them try to tackle a real problem.

What To Look For

When I pose a design problem, whether the result is an algorithm or a visual design or a report or anything else, beyond the quality of the work, I’m assessing a number of other things:

  • Do they like solving this kind of problem?  Of course there is some added stress because it is an interview, but you can usually tell if they are enjoying the opportunity to dig into the problem or not.  I try hard to make an interview feel as much as I can like the real job – sometimes I will pose a problem that I’m actually trying to figure out at the time.  If they hate doing it in the interview, they probably aren’t going to love doing it all day long.
  • Do we make each other smart?  If we’re going to be working together in the future, hopefully we have a good working rapport.  Did the design conversation zip along efficiently and cover ground well, or were there constant misunderstandings and false starts?
  • Do they handle pushback well?  I always question some of their decisions (politely, of course).  How they handle that will tell you a lot.  The worst reaction is if they get mad, or they dogmatically insist that theirs is the best approach without explaining why.  Almost as bad is if they cave immediately and ask what you think they should do instead.  A great reaction is to explain the rationale for the original design, and to list a couple of alternative approaches and why they seemed less effective.  I hope they welcome new data, if I share something useful that would influence the design in a better direction.  In general, I want to know if they are passionate about finding the best answer, or about moving forward with their answer.
  • How do they handle underspecified problems?  I like to ask design questions without providing enough information, to see what happens.  The two most common failure modes are to flail around and to make wild sweeping assumptions.  If I ask you to design an airport, do you just freeze up, do you assume that it is LAX (rather than, say, an oilfield airport in Alaska), or do you ask?  In general, I’ve found that people who fall into either of those traps often have trouble if they get hired.  The freezers aren’t good at taking on hard new problems without having their hand held, and the assumers bull off in wrong directions and get themselves (and their teams) into a mess.

Other Questions I Like

 Once you have figured out whether they can do the work that is most important for your role, there are other questions that I’ve found effective:

  • Teach me about X.  Pick something that looks interesting in their resume – a skill they say they have, a project they worked on.  Have them teach it to you.  If it involves a design they did, ask them why they made certain decisions, and what they would have done differently in retrospect.  At the end of the discussion, do you feel well informed about the topic?  Any job I hire somebody to do will almost certainly involve explanations of complex topics, so it’s an important skill in its own right.  And, it will help you figure out how well they actually understood what they were working on.  If a very attentive listener can’t get a decent grasp of it quickly, they probably didn’t.
  • How would YOU interview somebody for this job?  This is a fun question, and I’ve found it is really useful.  It helps me understand what they think is important about the role and how thoughtful they are about testing for those characteristics.  It also reveals whether they have insight into other people and how to work with/manage them.
  • Share a great success and a disappointing failure in managing other people.  What did you do, how did it come out, and what did you learn?  If the person is interviewing for a management role, I want to know how they think about other people.  Are they insightful?  Do they passionately identify with the success of the people whom they managed?  If you are an experienced manager, you are pretty much guaranteed to have succeeded with somebody and failed with somebody, so you should have some interesting stories to talk about.  I also often pose a scenario – “Margaret is a superstar but runs roughshod over others, and you are going to give her a tough review calling her on it.  How do you prepare, what do you say, how do you handle it when she attacks you …”

Making the Call

At the end of the interview, you have to make a decision – “hire” or “no hire”.  Often, it’s obvious.  But if there is any doubt in my mind, I find it really useful to write down the reasons and talk them through with somebody else who has made a lot of hiring decisions.  By the time I finish explaining the analysis, I almost always realize that I’ve made up my mind, and can ground the answer in solid reasons.

The people you hire will largely determine how successful your team is, so choose wisely.  Good luck!

Filed Under: 1000x, 100x, 10x, 1x, Managing People Tagged With: ,

Artisans vs. Armies

October 11, 2012 by Leave a Comment

There are moments in the history of software, when a product created by a tiny team has invented or transformed entire markets.  I was struck by evidence for a similar model in evolutionary biology: the theory of punctuated equilibrium, where there are long periods of relatively little change followed by short and dramatic periods of upheaval.

This kind of rapid change, brought on by an insightful act of creation, has happened repeatedly.  Afterwards, the market leaders usually settle into a period of stability and incremental refinement, backed by large teams.  For example:

UNIX: Ken Thompson and Dennis Ritchie were working at Bell Labs, and became disenchanted with a large-scale project to design a novel operating system, called Multics.  In reaction to its complexity, they created a much simpler alternative and impishly called it “Unics” (later renamed to Unix).  Thompson described Multics as “overdesigned and overbuilt and over everything” (a common complain about systems built by armies!).  Unix went on to become one of the two dominant server operating systems; it is now enhanced and maintained by an army of its own – thousands of developers around the world.

Visicalc: while a student at Harvard Business School, Dan Bricklin got tired of doing spreadsheets on paper.  He thought that he could use a personal computer to help, so he wrote Visicalc for the Apple II and transformed the role of the personal computer in business.  The spreadsheet has long since moved to the other model – Microsoft Excel has dominated the market for many years.

Electronic Arts: The company was originally created by Trip Hawkins in 1982 with a vision: find the brilliant programmers who could create amazing games for small computers, and celebrate those artists and their creations just as we do with great musicians.  One of my friends from junior high school wrote an early EA game (called Axis Assassin).  It was a very impressive homage to his favorite arcade game, Tempest, and he was the sole programmer who built it.  I still have the packaging with his picture and bio in it (at the ripe age of 18).  But that notion of the individual artist was abandoned by EA many years ago.  Now they make games like Madden NFL, which is built by 30 developers and has more than 10 million lines of source code.  The big PC and console games involve massive multi-year investments.  The artisans have moved to mobile, a disruptive domain where very popular games with millions of users are still being created by tiny teams of people.

American culture, I think, has always been caught between a celebration of the small (the lone inventor in a workshop building a better mousetrap, the small farmer setting forth in a Conestoga wagon on the Oregon trail, the “small is beautiful” philosophy of the 70s) and a celebration of the large (the great skyscrapers – “cathedrals of the machine age”, the massive industrial output that powered our economy and made us victorious in the world wars, the space program that landed astronauts on the moon).  Like the technology industry, our culture is tugged back and forth between these two extremes.

The Model

Across all of these examples, I find that there is a somewhat consistent pattern.  Typically, a new opportunity opens up due to some key technology transformation (like the advent of the PC or the Internet), which is not yet dominated by large established organizations.  Some ground-breaking programmers dream up a new kind of product and create it, often as an act of passion rather than of calculation. The new idea gathers popularity, and over time it either grows a large company around it or (occasionally) is taken over by some existing player that wakes up quickly enough and buys or builds their way into a dominant position.

Once a kind of software has become well-established, it usually stops being the realm of the artisan and becomes dominated by large, well-financed teams.  Division of labor was one of the foundational ideas of the machine age, allowing our society to generate massively more output than it ever could have from the labors of loosely organized artisans in their guilds.  The artisans in most industries were washed to the sea by mega-giants.

But division of labor has a great flaw in times of turbulence – it is extremely hard to rapidly re-architect large products or large teams.  At scale, nobody knows the full story of how either one functions.  In software, the products may be millions of lines of code.  The working relationships among hundreds of specialized experts on an engineering team is a tremendously complex system of its own – redesigning it can be even harder than redesigning the software.  Clayton Christenson and others have eloquently written about how hard it is for established players to reinvent themselves.

It’s Not Just Software

This alternation between artisan and army is not restricted to software.  I was fascinated to learn what happened in the 1800’s in manufacturing, elegantly described in the book The Tycoons (which I highly recommend).

During the Industrial Revolution, British industry was transformed by machine-based manufacturing.  Individual artisans were unable to compete and were largely supplanted.  That part I knew.  What I didn’t know, is that there were some key inventions in manufacturing that had the side-effect of making the roles within a factory require far less individual skill and judgment.  The British were slow to adopt them, and most British plant workers were artisans – in the 1890s, three-quarters of them were highly trained crafts-people with a lifetime of expertise.  By contrast, American plants had virtually none – somebody could be trained for almost any role in the plant relatively quickly.

For this and other reasons, American industry production sky-rocketed past the British.  In 1860, US output was one-third of Britain’s.  Fifty years later, it was 2.3 times larger (!).  Manufacturing has remained dominated by mass scale ever since, though there are interesting early signs of another major shift.  The rise of 3D printing technology makes it cost effective to do very small runs – we may see a new renaissance for the artisan manufacturer.

Another example is movie-making.  United Artists was founded in 1919 by four directors and actors, including Charlie Chaplin and Mary Pickford (two of the most popular actors of the day).  The vision, embodied in its name, was to create a place where the artists dominated, not what today we might call the “suits”.  The company struggled because the industry was moving to longer movies with high production values that required large teams and big investments (sound familiar?).

The company, and the broader industry, seesawed back and forth.  In the 1960s, United Artists created the Bond blockbuster franchise.  In the 1970s, they were involved in the shift towards small “auteur” movies that represented the singular vision of a one person (like Midnight Cowboy).  Then back to blockbusters in the 1980s.  Lately, “indie” pictures are all the rage.  The dynamics of the movie industry have interesting similarities to software, shifting back and forth across the spectrum between creation by artisan or by army.

We’re In a Time of Radical Change

As I’ve written elsewhere, because of the cloud and devices, technology is in a time of radical transformation – a lot of equilibriums are being punctured right now.  It’s a hard time to be an established leader – a threat can develop out of nowhere from a couple of passionate developers with a new idea, and it can grow to massive size in the relative blink of an eye.

But it’s a magical time for the artisans – they can challenge the dominions of the giants, tweaking the noses of the biggest companies in the industry.  And if they are right and they have a winning idea, they can have a tremendous impact.  You don’t need an army to change the shape of an industry – you can build a program and, with no capital investment at all, make it available to a billion people in an hour.  If you crack the code and build something that has real demand, there are ready accelerants poised to support you.  Investment capital is abundantly available to companies that have gotten traction, and people with every kind of specialized skill are ready to jump on the train once it has begun gathering speed.  I call it “scale fast or fail fast”.

I believe that during the next several years, many domains of human endeavor will be radically reshaped by small teams of scrappy challengers.  They will seize this period of transformation to forge and pursue new visions that will change the dynamics of whole industries.  It will be fascinating to see what they come up with.

Filed Under: 10x, 1x Tagged With: , ,

The Magic Tomato

October 2, 2012 by 2 Comments

A new productivity idea has been making the rounds lately, called the “Pomodoro” technique.  I’ve been using it quite a bit at our startup, and it’s been a great help, so I thought I’d share it on the blog.  The name comes from the Italian word for “tomato”, because the inventor (Francesco Cirillo) had a kitchen timer in the shape of a tomato that he used when he was coming up with it.

Pomodoro is really helpful for doing focused work on important projects, especially when they require creative or deep thinking.  It’s so easy to get distracted by easier work or email or interesting discussions with co-workers.

I use Pomodoro for projects that

  • Don’t have clear short-term milestones.  For example, I spent a number of weeks diving into the latest techniques in machine learning and figuring out how to apply them to our product.  This project took hundreds of hours and I just had to chew away at it day after day, working through the algorithms and how we can use them most effectively in our application.
  • Are hard.  In most jobs, there are a myriad of useful and productive things to work on.  A few of them are really important … but the others are often a lot easier.  It takes very little intellectual effort to update the feature spreadsheet, or answer some emails, or do a QA pass over the website – all fine and useful things to do.  But they aren’t the projects that are going to yield huge amounts of value.  Often, a project is “hard” because you don’t know what to do.  You just have to bash away at it until you figure out how to get traction (possibly using some of the ideas from the “crack the nut” post).  Or, it might be hard because you are trying to create something new, and that can be scary.

So How Does It Work?

There is a detailed online guide, which is well worth looking through.  I do find that it can be overly prescriptive about how you are supposed to use the technique, and my approach is somewhat simpler.

Say you have a project that you want to focus on.  The basic idea is that you tackle it in blocks of time, choosing the block size that works for you.  The guides recommend numbers like 25 minutes; I have found that 50 minutes tends to work best for me.  You commit to working for that long without stopping – no answering the phone, no getting up, no checking email, no distractions.  You just work.  If anything comes up that you need to attend to, write it down and get right back to work – don’t do anything else about it.  At the end of the block of time, you stop and get a rest period, where you can deal with things that came up, check email, etc.  The rest period might be 10 or 15 minutes, or whatever works for you.  Check off the Pomodoro when you finish it, and it doesn’t count if you didn’t spend the entire time on your project without stopping.

At the start of the day, I might decide that my goal is to do (let’s say) four 50-minute Pomodoros.  Maybe I’ll spend two of them on machine learning, one designing our user profile system, and one on learning about business metrics for SaaS companies.  I find this approach works really well, because it makes it pretty easy to line up my time against the really important priorities.  The chunks of time are big enough that you can make decisions about them pretty easily.

At the end of the day, I’ll look at how I did.  If I didn’t get very many Pomodoros checked off that day, I know that I wasn’t able to focus on the projects that I wanted to.  I got interrupted, or other things came up.  That’s ok .. the point is not to beat yourself up, but it is important to be honest with yourself about whether you are really moving ahead on the things that matter, and if not, figure out what to do about it.  You’ll also be surprised at how few Pomodoros you can really get done.  In a multi-tasking environment with meetings and so forth, you might get zero significant blocks of utterly focused, undistracted time.  In a startup with virtually no meetings, I’m able to get several 50 minute Pomodoros done on a really amazing day, which is an incredibly good feeling.

Why It Works

One of the things I really like about this technique is that it makes an open-ended project quantifiable.  A multi-week or month project that doesn’t have a lot of interim milestones suddenly has a countable milestone every 50 minutes of work.  You can plan in terms of these chunks of time, you can check them off, and you get a feeling of progress even if there isn’t anything else you can really point to.  I think most people find it much easier to work on a project when there are tangible results along the way – I know that I definitely do!

It also makes it much easier to psyche myself up for a big hard task, because I know that I can stop in 50 minutes – it’s a real comfort to know that no matter how bad things get, I only have to push for that long and then I get to stop.  What almost always happens in practice, of course, is that once I get going, the project sucks me in and I pound happily along, annoyed when I’m “forced” to stop at the end of the work period.  But there is a lot of research that you are most productive if you do sustained bursts of work with breaks in between.  It’s also healthy to get up and stretch regularly.

Another good thing is that it gives you permission/”coerces” you into ignoring potential interruptions.  When you are doing something intense or creative or hard, it’s death to be constantly starting and stopping – you don’t get into that flow that is so magical.   When you are in the midst of a Pomodoro and you know that you won’t get to count it if you let yourself get pulled away, you actively resist interruptions.

Tools

You can do a fine job of using the Pomodoro technique with nothing but a piece of paper and a watch or a kitchen timer.  I do use two pieces of software that I find helpful:

  • My Little Pomodoro – a cute little app for the Mac that will time your Pomodoro interval and chime at the end.  There are several apps like this, or you can also use a kitchen timer, or just your watch/smartphone.
  • Omnifocus – a great productivity tool I’ll write about in another post; the key thing for Pomodoro is that any time I want to note something, I just hit a quick key combination, type in a phrase, and hit return.  The window disappears, and I know the note is squirreled away where I can (and will!) deal with it later.  A lower tech solution is a piece of paper that you scribble a note onto.  Anything works if it is a quick and dependable place to jot down an idea or task, so you can forget about it and get back to your Pomodoro work.

Since I work in an open office, I have a bit of a ritual for starting the Pomodoro.  I put on noise cancelling headphones, start up a special playlist of music (my favorites are choral pieces from the 16th and 17th century), start up the Pomodoro app timer, set the program I’m using to full screen so no other software will be visible … and WORK.

When To Use It

Paul Graham wrote a wonderful essay about the difference between a “maker’s” schedule, and a “manager’s” schedule.  When your time is divided up for you, where things are very structured, and you go from meeting to meeting or activity to activity, you don’t need Pomodoro.  But when you are taking on something open-ended and creative, or you have to think really hard about a problem you don’t know how to solve .. give it a try.  Perhaps you will find that it is as magical for you as it has been for me!

Filed Under: 1x Tagged With: , ,

The Physics of Software

September 4, 2012 by Leave a Comment

Physics – the natural laws defining the behavior of matter and energy – determines  what is possible in the universe.  I have found that engineering projects have a kind of physics as well.  But as technology undergoes fundamental transformations, that physics changes.

Enterprise Servers

Let’s look at large-scale commercial enterprise servers composed of millions of lines of code, which in my experience follow a pretty well defined model.  It’s dictated by the needs of the customer and by the constraints of the problem.

In a typical release that makes real but evolutionary steps forward, you take two years to do a version.  During those two years, you get three coding milestones, each of which is eight coding weeks.  Each developer on the project might do four coding days per work week, three if they are a lead.  Roughly 40% of the team is developers (the rest are testers, project managers, designers, etc).  That means that for every person-year spent by the engineering team, you are getting an average of 18 days of actual production coding on the product.

Ouch – no wonder those products take large teams to build and evolve so slowly.  What’s the deal?  The absolute killer .. the single thing that takes away the most productivity from the team, is the need to test and stabilize the product for the vast array of configurations that customers will use it in.  We called it The Matrix – the multi-dimensional matrix of every possible operating system (at different patch levels), every possible storage system, every possible database that customers might be using.  The combinatorics are brutal.

You have to test and retest and retest your product .. not just that it works, but that it is stable under load, that it performs as well as it needs to, that it fails in the same predictable ways, that it recovers from failure, that it can be managed, and backed up, and diagnosed when it goes wrong, and is secure, that you can smoothly migrate to it from older versions, that it integrates with all kinds of other systems that customers want to use it with, and on and on.

We called these “the basics”, and they soaked up far more time than actually writing the code that makes the product function.  Even if you are a very wealthy company, your test lab can’t possibly have every configuration that customers actually use (which is in fact unknowable, since everybody does weird things to customize their datacenter), so you put out a beta and work with early adopters to deploy and test the code in even more configurations.

The sad thing is that even if you could go faster, customers often don’t want you to – from their point of view, you are going too fast.  Once you finish your shiny new version, you have to get them to deploy the darned thing.  They frequently don’t want to, since the old one is working and they are risk-averse and have other and better things to do.  So you work on them, and gradually persuade some of them (often it takes years, and plenty of them will just skip a version).  Then they do a test deployment.  Then they come up with a migration plan.  Then they gradually spin up the new system and move over to it.  Multiple years after a new release, it is quite likely that the great majority of your customer base is running the older ones.  So you have to support every version until the support window runs out – for Microsoft that is ten years, or longer in some cases where the customers were very insistent.  If you are shipping every two years, that might mean supporting five different versions.

And worst of all, once you finally have the customer running live on your system, you basically have no idea what they are doing with it.   Are they using those features that you sweated blood to build?  Is the product working well and delivering the results they need?  You have virtually no data and hence there is a lot of guesswork in figuring out what to do next.  You prioritize things that users complain about or that the engineering team is excited about, never really sure if your priorities match the real needs of the customer.

Cloud Services Change the Physics

Contrast that with running a service.  When you host the service yourself, you have one configuration to support.  You have one team operating it that all works for one company and that works closely together.  You have perfect knowledge of, and control over, the environment where the system is going to be run.  When you deploy a new version, everyone is instantly running on it.

The result is a dramatic change in the size of the team that you need and the efficiency with which you can deliver to customers.  And keeping team sizes down pays off in many ways that are hard to quantify but nevertheless crucial – less communication overhead, a stronger sense of unity, and the ability to make changes in plan more quickly.

Even more important, when customers use your service, you know everything.  You know what features they use, what kind of performance you are delivering, whether searches are yielding results that users are interested in, whether one version or the other of your software gets better results.  You can spot and fix problems in real time without desperately trying to diagnose a critical live system in a customer’s facility based on the few clues that they are able and willing to share with you.

What Does It Mean?

In the history of computer technology, there have been several times when the physics changed profoundly.  Moving from batch to interactive systems was one.  The advent of the PC, where computing became ubiquitous and under your own control.  The standardization of key building blocks like operating systems and databases, so applications could focus on the unique logic of the problems they were targeting.

Every time the physics changed in the past, it enabled a massive acceleration of innovation and disruption.  New markets opened up, software was able to do things it had never been able to do before, and established companies faced tremendous pressure.  The traditional way of doing things doesn’t always go away – mainframes running COBOL process enormous numbers of transactions every day.  People still buy PC software, and servers will be deployed into data centers for decades.  But companies and communities that miss out on one of these fundamental transformations usually have a difficult time.  They often end up living in a perpetual twilight world of stasis and conservatism.  The frontiers of technical development, the best developers, and the biggest new opportunities leave them behind.

I believe that this transition, from servers to services, is one of those abiding changes in the physics of software.  The benefits of services are so compelling in terms of efficiency, of deeply understanding your customers and what they need, and of adjusting and adapting software in real time, that I think they will be the place where the white-heat of innovation happens.  If you are on the wrong side of that divide and your competitor is not, it will be very difficult to compete toe to toe.

Filed Under: 1x Tagged With: ,

Do You Learn More at a Startup?

August 15, 2012 by 1 Comment

I’ve had The Debate many times with people at very different stages of their career – whether to go to a startup, or to work at an established company.  One of the classic arguments for the startup is that you learn more than you would inside the belly of the beast at a large company.

Why it’s True

One of the distinctive things about life at a startup is that everything happens at a hyper-accelerated rate.  Which means that for a given amount of time, you will generally experience much more of the lifecycle of a product, a business, and a company.

I experienced this really vividly when I did my second startup, a dot.com.  I left Microsoft for the opposite coast to co-found the company.  In two years, we grew it from a few people to over 100, built a massively scalable server infrastructure from scratch and shipped it in six months, became the 50th most active site on the Web, went on a road show and took the company public, lived the exhilaration of flying high, got caught up in the crash and watched our stock go into the tank, had it come back to a more reasonable level, and merged the company with another.  Then my previous partner convinced me to come back to Microsoft to do an internal startup .. and I ran into people who were still working on exactly the same product cycle they had been doing when I left (!).  I felt like a traveller who has gone out into the world, had exotic adventures, and feels utterly changed by them, only to come back and encounter the polite incomprehension of the folks who stayed at home muddling along just as usual.

Another thing is that you typically get involved in a much broader range of activity.  At a big company, division of labor exists (must exist!) at an extreme.  There are hundreds of finance people at Microsoft who are extremely expert at what they do, so your involvement in that discipline even at senior levels of business ownership is very limited.  You consume their work, but that’s very, very different from actually doing it.  Similarly for legal, HR, recruiting, sales, lab management, datacenter design, office facilities, networking infrastructure, ad infinitum.

At a startup, there aren’t any specialists in most areas, so you have to jump in and do them yourself.  You get exposed to many aspects of the business that you wouldn’t otherwise know anything about.  If you like a holistic understanding of what’s happening, you love that.  If you want to focus deep in an area, it can drive you nuts.

But .. It’s Not That Simple

That’s the “pro” argument, but there’s another side of the coin that I think is often glossed over by the advocates.

Because things are moving fast and there aren’t a lot of “experts” around, you usually won’t get trained with any kind of deliberation.  Big companies are very uneven about how thoughtfully they develop their people, so it’s by no means assured that you will get a better experience, but hopefully you will.  I think one of the best way to learn, especially early in your career, is to “apprentice” with a more experienced and expert person.  Ideally, they are a great coach who will push you with challenging work, will evaluate it deeply and give detailed feedback, and they will be there to help when (and only when!) appropriate.  I think you are more likely to get that experience at an established company ..  but lousy managers abound everywhere, so you’ll have to be lucky or smart to find a good one.

It’s rare to get the opportunity to learn big and complex things systematically.  There are areas of expertise that are deep, hard, and take time to absorb.  Things like operating system and database kernels, distributed system design, compiler optimization, and machine learning, are systematic bodies of knowledge that call for the accumulation of knowledge and wisdom over many years to become a true expert.  In startups, you are scrambling like hell and need to get something up that works, so it’s hard to create something that is carefully and thoughtfully designed for the long term.  There are wonderful counter-examples of well-architected systems built by startups, and many pieces of crap built by big teams at established companies, so this is not some universal law.  But, in my experience, you are more likely to get a chance to master those kinds of areas at a big company that has the resources to invest in thoughtful architecture and quantities of deeply trained people available to work on it.

Running a business at scale is different than running a small one.  You won’t learn how to operate at scale at most startups.  Managing teams of hundreds of developers, keeping hundreds or thousands of sales people productive, coordinating hundreds of subsidiaries around the world – these are very difficult things to do well, and you won’t learn about them at a small company.

How it Nets Out

So will you learn more at a startup?  It depends on what you want to learn.  If you want to experience the whole business from customer experience to support to revenue, choose a startup every time.  If you want to move fast and see a lot of things quickly, ditto.

But, if you want to go really deep and immerse yourself in something complex, or you want to train yourself in your craft (whatever it is – systems programming, project management, finance), or you want to learn how to operate at high scale, you might find that you will do better at a larger and more established company.

What’s my approach?  Do both.  I have had by far the most fun at the three startups I’ve done, but I’ve learned powerful lessons at large companies that serve me well in everything I take on, with teams large and small.  And if you are at a startup, and it’s successful, then it’s nice to know that you have experience operating at larger scale – you won’t have to learn every lesson on the fly, when it’s life or death for the company that you do it right.

Filed Under: 100x, 10x, 1x Tagged With:

Rise of Data Science

August 2, 2012 by Leave a Comment

Radically accelerated by the advent of cloud computing and devices, a role has begun to develop that will flourish in the coming years, and I am convinced that it will have a major impact on our lives.

New technologies often usher in new disciplines; they typically begin as a chaotic area of focus, with all sorts of people falling into them from different backgrounds.  Over time, they take on structure, books are written, educational and training programs develop, and they turn into a mature discipline.  That’s what happened when the Web was created – building a web site requires a mix of skills that draw from what had been quite separate worlds of activity: art and visual design, image processing, and programming (among others).

The same arc happened a few decades earlier when programming was invented – it drew from fields like mathematics, engineering, and linguistics.  It attracted people from those fields and many others (including more than a few high school students who were supposed to be doing something else!).

This new field hasn’t been officially named yet, but one of the terms that people are using for it is “data science”.  I’ve been diving into it pretty deeply for our startup, and some remarkably interesting work has been happening over the past several years.

What Does a Data Scientist Do, Anyway?

As you would expect from an emerging discipline, people don’t agree yet on exactly what it is all about.  But the fundamental idea is that enormous bodies of data are being gathered through software, and somebody has to make sense of them.  The analysis can influence decisions that people make (“hey, this version of our web service gets 15% more people to sign up for an account than the other one”) and decisions that software makes (while browsing items on Amazon, the web site will tell you that people who bought this product also were interested in …).

A data scientist is somebody who figures out what data to gather, how to analyze it, and what to do with the results of that analysis.  The discipline combines ideas from areas like statistics, machine learning, mathematics, databases, and psychology.

What’s it good for?  Well, here are just a few ways it is being used today:

  • The magical ability of Google search to find what you need from a couple of words and no other hints.  Compare that experience to what you typically get from software – you usually have to tell applications in painfully explicit detail exactly what you want, in very tightly scripted sequences of commands, and it can be extremely frustrating if the programmers haven’t anticipated what you want.  With Google, you type just about anything into the search box, and with incredibly high probability, it will give you a useful set of answers.
  • The ability to recommend things that are likely to interest you.  Amazon is very, very good at helping you find a book you want on any subject under the sun, through a combination of search and recommendations.  Netflix has gotten to the point where 75% of the shows that people watch on their streaming service come from a recommendation
  • Web sites present users with multiple versions of their product simultaneously, watch how users react, and pick the best one.  Large web companies are running dozens or hundreds of these A/B tests simultaneously and are updating their product daily based on the result.  I used to ship large packaged software products to enterprises, and we would conduct a manual poll of our users years after we shipped to try to figure out whether they used the product and what they did with it – the results were very spotty, very late, and highly inaccurate.  It’s like trying to drive by covering the windows of your car with black paint and having somebody write you an occasional letter about where you are and the condition of the road.

Those are just a few examples – almost every Web-based company depends on data science as its lifeblood to make its product come alive for users and to run its business internally.

The Future

What’s being done today with data science, while impressive, just scratches the surface.  The current economic models have only begun to evolve.  And many parts of our lives remain deeply inefficient and filled with friction:

  • Transit is very wasteful – guessing about traffic patterns, individual drivers maneuvering 3000 pound chunks of metal with dubious competence.
  • Integration of medical care, diagnosis, and monitoring our bodies, remains technologically primitive.
  • Energy use is highly inefficient, partly because we have little idea how to optimize or the implications of our decisions.
  • Education hasn’t improved much in the last few hundred years, when President Garfield said that the ideal college was a famous teacher (Mark Hopkins) at one end of a log and a student at the other.  It’s arguably the most important competency of a successful nation in the modern age, and our system (in the United States at least) is hardly flourishing.

Along with much of the economy, these areas are ripe to be transformed, and I am convinced that data scientists will be at the heart of that transformation (for good and for ill!).  If you’d like to learn more:

It’s a discipline that I think anyone involved in technology should understand at some basic level.  Pretty much whatever you do these days, there are probably large quantities of data being generated around it that can be mined for insight.  You want to leverage this power, to make your own decisions and to create a great experience for people using your software.  It’s going to continue to transform the world over the coming years .. and maybe you can become a real-life Hari Seldon.

Filed Under: 1x Tagged With: , , ,

The Rip Van Winkle Question

July 18, 2012 by 2 Comments

Several years ago, I become responsible for a reasonably large business.  As you’d expect, the team regularly reviewed progress using a series of reports full of numbers.  Page after page of them, with thousands of numbers, analyzing performance by region, by pricing level, by licensing model, by customer type – you name it.

To an expert, these reports were filled with wonderful nuggets of insight.  Wow, what happened to sales in Germany last quarter – why did they tank even though the competitor’s results were strong?  Clearly, the Japanese sub is the only one leveraging the price increase – their average revenue per unit is spiking while everyone else is just plodding along.  And so on.

To somebody who was not expert (i.e. me), it was just a wall of numbers that didn’t convey much of anything.  To get a sense, check out a report like this one.  If you are an experienced investor, or used to reading accounting statements, you can glance over it and almost instantly you know a lot of interesting things about Google as a business.  If you aren’t, your eyes probably glazed over and you are hoping there won’t be a pop quiz at the bottom of this blog post.

In my case, I didn’t even know what half of the numbers on the business reports were about.  What the heck was the “PSP attainment vs. seasonality adjusted target”?  Did it matter that we seemed to be below what we had originally expected?  But I had to get smart quickly – these reports were the lifeblood of the business.  It’s like a medical chart to a doctor; they can spot patterns that reveal what is happening to their patients.  I had just become the doctor for this business, and I needed to know if the patient was suffering from any serious illnesses, so I could do something about them pronto.

So How to Start?

The best technique I’ve found is what I call the “Rip Van Winkle” question.  If you aren’t familiar with the short story, Rip was a man who fell asleep for twenty years, and found that the world had changed dramatically when he woke up.

What I did was to take every important angle on the business and find somebody who was really smart about it.  Then I sat down with them and asked the key question: “if you fell asleep for a year or two, when you woke up, what are the first things you would look at on this report to understand how the business is doing?”  Over and over again, I got amazing insights by asking this.  “Well, the first thing I’d do is look at new sales in the enterprise segment to make sure we are getting growth instead of just milking the installed base.  Then I’d divide that by the number of units for a quick check that our price was holding up and we’re not jacking up sales with deep discounting.  Then ….”

I did this walk-through with around 30 people, for a total of some sixty hours of discussions.  Finance people told me how they analyze the finance numbers.  Customer service showed me how they track and assess problems and customer satisfaction.  Sales managers talked about the pipeline and performance and hiring.  Often, different people would take me through the same report, and come at it from radically different directions.  I took copious notes, but I always asked for the top 2-4 things they would look at first.  I would highlight and number the places that held the answer.

Vital Signs

It turns out that for just about any report, even if it has hundreds or thousands of numbers on it, there are a handful that really tell the crucial story.  The rest of them might be useful to support the story or diagnose a problem, but you mustn’t get distracted.  In medicine they call them your vital signs – tell me your pulse and whether your eyes dilate and a couple of other things that can be measured by an EMT in seconds, and I will know if you are basically ok or deeply traumatized.  I may not know if you had a stroke or a concussion, but I’ll have a good basic sense of how you are doing.

This technique hinges, of course, on finding insightful people with an intuitive mastery of the numbers.  I could never predict who it would be from the org chart – they might be high up or buried deep.  But the people who worked in that area almost always knew whom I should talk to.  Ask around!  Once I found the right people, they were usually happy to share some wisdom with an interested and enthusiastic listener.  Buying them lunch never hurt, either.

By the end of those sixty hours, I was pretty darn good at diagnosing the business from the numbers, because I had learned from such a wide range of experts.  The process also turned out to be a useful diagnostic tool in its own right.  If I couldn’t find anyone in an area with great insights to share, chances were pretty good this was a side of the business that wasn’t being managed very well.

What I’ve learned by doing this exercise many times is that project reporting is almost always far too detailed – it’s like the old story about writing a shorter letter if you had more time.  It’s very hard to distill a lot of complexity into a tight report that shows only the key things – that means you have to figure out what those key things are (and have confidence that you didn’t miss anything vital!) – so most people cop out and throw in the kitchen sink.  As you are ramping up, think about how to cut way down on the amount of information being reported.  More is definitely not better, when it comes to metrics.  Einstein’s famous dictum applies perfectly here – “make things as simple as possible, but not simpler”.

The next time you have to get smart about a report full of numbers, give the Rip Van Winkle technique a try, and see if it works as well for you as it has for me.

Filed Under: 1000x, 100x, 10x, 1x, Rhythms of Business Tagged With: , ,

Rubber Gloves, Not White Gloves

June 14, 2012 by Leave a Comment

I’ve always loved to be involved in making things happen, on the ground.  The detail of execution, the individual decisions that mount up to determine success or failure – I like to plunge my hands into the engine grease.  Hence, rubber gloves, not white gloves.

That enthusiasm hasn’t always been embraced by the environment I’m in – places where the focus was on Big Ideas™, not the minutia of execution.  In academia, research labs, and staff or management roles, I was often supposed to step back, see the bigger picture, and identify the key trends and leverage points.  I love to do that, but I find that big ideas often become irrelevant if you are disconnected from the details.  In studying many projects that both succeeded and failed, my conviction has only deepened that the combination is where the magic lies.

Combining Vision and Execution

A great example is Brunelleschi, the architect who designed the beautiful Duomo – the dome that sits atop the famous cathedral that dominates the skyline of Florence.

It took 140 years to complete the building; the dome had remained a puzzle for decades because nobody could figure out how to build it.  The solution called for rediscovering ideas that had been forgotten since the days of the Roman Empire, and new inventions that had never been tried before.

Brunelleschi solved the problem in 1419 and got the commission, dedicating most of his adult life to constructing the dome and other parts of the cathedral.  The dome took more than four million bricks (37,000 tons of material!), and with the lantern on top stood 375 feet high.  He got a couple of the first patents ever issued to protect his ideas for a new kind of hoisting machine and a river transport vessel.  Brunelleschi was intimately involved in every step of the construction, laid some of the bricks himself, and immersed himself in every detail (including the work schedule and diet of the people doing the construction).  If you are interested, check out the Wikipedia entry; Ross King did a great job telling the story in more detail in the book, Brunelleschi’s Dome.

Another interesting case study was the race to reach the South Pole first in 1911.   Two expeditions were involved.  One party, led by Robert Scott, was less focused on the details of planning and preparation.  The other, led by Roald Amundsen, was a great example of deep focus on every detail.  Amundsen insisted that every member of the expedition be an expert skier who had been practicing the sport since they were children.  Scott’s team mostly couldn’t ski.  Amundsen prepared navigation sheets so that they wouldn’t have to make complex calculations when they were exhausted.  Four out of five members of his final team were experienced navigators.  Scott had one, and used a technique that required more calculation.  Amundsen relied heavily on sled dogs and figured out how to keep them properly fed and cared for.  Scott’s team didn’t want to rely as much on dogs so they were dependent on horses, which turned out to be poorly adapted for the conditions.

Both teams were staffed with brave and seasoned explorers, but the results starkly illustrate the cost of poor focus on execution basics.  Amundsen got to the pole first and returned successfully without losing a man.  Scott, and the four companions who made it to the pole with him, all died.

Right Vision, Bad Execution

There are many, many examples where a compelling vision but poor execution leads to disaster.  It often happens even if the vision is a great and achievable one.

I thought it was very interesting to learn about the history of the Panama Canal in the excellent book by David McCullough called Path Between The Seas.  Basically, there was a competition to come up with the design for a canal that would connect the Atlantic and Pacific Ocean and avoid the laborious and dangerous trip around South America into the treacherous waters of Drake’s Passage.  A Frenchman, Ferdinand de Lesseps, had been the leading spirit behind the Suez Canal and came up with a hastily slapped together plan that chose a sub-optimal path and paid little heed to the enormous engineering challenges.  An American team very carefully and thoughtfully developed an alternative based on extensive surveys.  Lesseps, who was a charismatic, larger than life figure with little engineering knowledge, carried the day anyway and inspired investors to finance the effort.

An engineering group estimated it would cost $214 million; Lesseps cut that to $120 million with no real justification.  After eight years, 22,000 people had died (mostly of malaria and yellow fever – nobody realized that they were spread by mosquitos) and $235 million dollars had been spent, but the project was only partially done with the hardest issues unresolved.  The company went bankrupt.   The project was eventually taken over by the American government, after a fifteen year delay, and it took another $375 million and nine years to complete (but came in under the budget estimate!).  I think it’s a powerful example of a great vision, uncoupled to strong execution, leading to horrible results.  Then that same vision, carried forward in more pragmatic and expert hands, created a vital global resource.

Vision is Crucial .. but Must Not Become Decoupled From Reality

I’m a great believer in the importance of vision and strategy.  But strategy has to be deeply, deeply informed by all the infinite detail of execution.  And in looking at brilliantly successful strategies in technology, I’ve found that they are often emergent properties.  They were glimpsed, and then refined, by someone steeped in a deep understanding of their markets and the technology forces transforming them.  A kernel of insight evolves into a huge success – it doesn’t leap forth from the mind fully formed, like Athena from the forehead of Zeus.   Having a big and bold goal is fantastic .. but strategy is shaped, and success or failure is determined, by the execution.

Great execution is hard and requires endless focus and obsessiveness to achieve.  I’ve mostly worked on large software projects, and when you are building something that has millions of lines of code in it, the team must work together extraordinary well.  Such projects call for Herculean efforts and tiny bits of friction can lead to huge problems.  The code, the test suites, the shiproom triage meeting, the bug count, the milestone definition .. those are the clay and brick from which the great cathedrals are forged.  Lose your connection to the grit and the glue at your peril.

That’s why I love being in a startup .. we have a bold vision for what we hope to achieve, but our days are full of designing and building the product with endless and loving focus on every detail.  Hopefully we are achieving a combination of vision and execution that will let us have the impact we aspire to make in the lives of our users.

Filed Under: 1000x, 100x, 10x, 1x Tagged With: ,
Next Page»