Cater to Your Personal Pathologies

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.

Congestive Meeting Collapse – Scheduling Gridlock

I used to spend most of my day in meetings.  At one point, when I was managing a large team, I routinely had weeks where there were a total of 2 hours between 9 and 5 that I wasn’t in a meeting .. for the entire week.  Anything I needed to work on that didn’t involve other people had to happen early or late.  Such as answering the crushing quantities of email that stacked up while I was in meetings and actually paying attention.

Now that I’m in a startup, where I’m typically in a traditional “meeting” for a couple of hours a week total, it is amazing how much gets done.  When I touch base with people from my previous employer, the scheduling overhead can become darkly humorous.  Routinely somebody will ask to get together, and then schedule it for a month later.  That slot then gets stepped on by some other meeting, often more than once (and typically at the last minute). It’s common for it to take two to three months to set up a conversation with more senior folks (!).  Really?

I think there is an interesting analogy to the performance of networks.  When the amount of traffic reaches a certain fraction of a network’s capacity and the scheduling protocols are not optimal, the network achieves what is called congestive collapse.  It means that the network is in a stable state of low throughput.  Is your company permanently in “congestive meeting collapse”?

The Damage it Does

When everyone is so hyper-scheduled

  • There is no slack in the system.  If something important comes up, you have to step on an existing meeting to get everyone together.  When one meeting is moved, that causes a cascade of rescheduling among all the attendees, which moves other meetings they were in, and on outwards like ripples in the water.
  • Everyone is in meetings all the time, so they are frustrated, bored, and don’t have time to work on individual projects except outside normal hours.  Anything “optional” (like thinking deeply about the state of your world, the future, and what you need to do about it) gets squeezed out by something “practical” but often much less important.
  • A huge amount of time is wasted scheduling and rescheduling.
  • “Medium importance” decisions take forever.  Big ones get attention; the medium ones that require a number of key people to get together and resolve something, but aren’t a crisis, get rescheduled and rescheduled and take much longer than they should.  This gums everything up and makes the organization inefficient.

Why Does This Happen?

Clearly the problem is that there are too many meetings, but why is that?  There are some obvious kinds of inefficiency, such as:

  • The Serial 1:1 – Some meetings are a lazy way for a manager to talk to folks on their team.  Everyone else sits glumly listening, doing email and/or propping up their eyelids with toothpicks, as the manager talks in turn to each person.  Now and then something relevant to the whole team comes up, but mostly it is a series of 1:1’s with bystanders.  Regular team “status” meetings are often like this – ugh, don’t do it!
  • The Inefficient Mess – There is no clear agenda, things wander along without being well managed, and action items aren’t captured efficiently.  Something that could have been handled in 15 crisp minutes takes 90 minutes, and often bleeds over to another meeting because people weren’t clear about what they were and weren’t accountable for doing afterwards.  This is lampooned by John Cleese in a fun training video called “Meetings, Bloody Meetings”.

But annoying as they are, bad meetings like these are just one-off problems that can be fixed with some coaching.  The much more insidious villain, I’ve found, is too many stakeholders.

As organizations grow, and as more groups are needed to be successful, every important decision develops a long list of people who legitimately have a stake in how it is made.  For example, consider a major shift in the strategy of a particular product.  It affects the people who design the product, build the product, communicate with customers, sell the product, and support customers.  It might also involve legal issues, HR issues, and resetting the expectations of senior management.  In a matrixed world, even one stakeholder can drag in multiple people – sales organizations often have somebody who owns the worldwide quotas for a particular product, for a particular market segment (“enterprise customers”), and/or for a particular regional market (“Germany”).

Thus, two things tend to happen.  One is that many stakeholders get involved in the decision.  They participate in meetings to discuss it, commit to it, implement it, learn about it, and review progress on it.  They all try to get invited to the most important meetings, so they are “in the loop”.  As you scale up, this leads to madness.  The other result is that it is so hard to get things landed that only the most senior people in the organization have enough authority to drive key decisions.  So more and more things land in their lap, disempowering everyone else and slowing things down to a crawl because nobody can get the meeting scheduled with them(!).

Sometimes you can dodge the problem by keeping teams small – the so-called “two pizza team” approach.  But if you are successful, eventually things tend to get big.  And at scale, I think the only solution is to cleanly and aggressively delegate authority and to be absolutely hard-core about defining a minimal set of people who get to influence a decision before it is made.

Both of these are hard and involve risk.  Sometimes, the decision-maker will screw up.  Bad decisions will get made that could have been avoided by involving other teams or more senior people.

But the price of avoiding those mistakes is to live constantly waist deep in mud.  Everything you do, every decision you make, is a slow-motion struggle to make progress.  The cost may be less apparent, but in a world moving at lightning speed, can you afford to carry that kind of a burden?  As Teddy Roosevelt said, “in any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing.”

Kissing Frogs Part 3: Frog Dos and Don’ts

The first two posts in this series were from the point of view of the interviewer.  But suppose you are on the other side of the table?

Do’s

Do your research.  It’s really disappointing for an interviewer when a candidate doesn’t have the first notion of what the company or the team does, and it’s great when they have intelligent questions.  “I tried out your product, and it seems like one of your big challenges is integration with systems that customers are already using.  Is that right?  How are you handling that?”  So much better than somebody who doesn’t have a clue.  These days you can learn staggering amounts about almost anything on the Internet.  So check out the company, the project, and the people.

Do practice.  Interviewing is unnatural for most people.  You won’t have concise soundbites ready to roll out about the work you did in previous jobs.  You may be rusty or misremember the details.  It’s very, very useful to have some mock interviews before you go into the real thing, especially if you can do it with experienced interviewers who will be honest enough to give you candid feedback.

Do interview them.  You are preparing to commit huge amounts of your time to this team and this project.  It’s probably the biggest investment decision you are going to make – your time is your biggest asset.  So learn as much as you can while you are there.  Are these people you actually like?  Is the work inspiring?  Will you learn something and stay engaged for the long haul?

Do prepare.  Be ready for hard questions.  “Why didn’t you finish school?”  “Why do you jump from job to job?”  “Why have you been unemployed for the last two years?”  “Why did the product you worked on get panned by every review?”  Look over your resume through the eyes of a stranger (or ask another person), and think up the most difficult questions you can.  Answer them honestly, be open about mistakes (if appropriate), and tell people what you learned.  Don’t be bitter, don’t whine about your past co-workers .. be constructive.

Do be concrete.   I think the best questions are not open-ended and general.  But lots of interviewers use them, anyway.  Don’t meet vague questions with vague answers – ground your answer in detail.  Tell stories.  Not “I think I’m very results-oriented.”  Ugh.  Instead, “in my last job, I drove the marketing campaign for Jumble.  It was a tough push, but we delivered on time into five different channels, driving a positive awareness of 44% – the best result of any campaign our company had done.”

Do be passionate.  It’s deeply dull to listen to somebody drone on in a monotone listing facts and figures about their career.  Boorrrrinnngg.  It’s very interesting when somebody’s eyes light up as they share personal stories about things they’ve done that inspired them.  Find things to talk about that you are excited about, that you loved doing in previous jobs or educational experiences.  You’re a human being, not a resume – let people get to know you.  Share yourself and what you love.

Don’ts

Don’t assume!  If you aren’t sure you understand the question that you are supposed to answer, don’t launch off and answer it anyway.  You can ask, or you can explain.  Start by asking: “when you asked me to design an operating system, did you mean something like Linux, or something else like an embedded system?”  Some interviewers want you to dive in and don’t want to be interrogated, however.  You can usually tell immediately based on their reaction to your first question.  In that case, I’d stop asking and make some assumptions, but I’d be explicit about them.  “Ok, I’m going to assume unless you stop me that you want an operating system like Linux.  That means a general purpose server OS that …”  Then you are diving in and moving forward but are clear about the assumptions you have made.  In any case, don’t ask too many questions – the purpose of the interview is not to collaborate with your interviewer on defining an extremely precise question, it’s to show that you are good at answering them.  So make sure you spend most of your time on the answer.

Don’t be prickly.  Interviews are inherently awkward, and some people like to put you under pressure to see how you perform.  I don’t like that approach as an interviewer, and don’t use it, but many swear by it.  That means they are going to push you.  They’ll ask tough questions or brain teasers and watch you sweat.  They’ll push back on your answers, with varying amounts of respect, to see how you handle it.  Don’t freak out .. just stay calm, and focus on the answer, not how you feel about the situation.  That doesn’t mean that you should allow yourself to be abused or mistreated, but keep your cool even if the other person is pretty hard on you.  If you think of it as a test, and letting yourself get emotional is failing the test, that might help.  Don’t let them throw you.

Don’t be desperate.  This is easier said than done, especially if you ARE kind of desperate to get the job.  But realize that the odds may well be against you in any particular interview.  They may have a favored candidate lined up and are just checking to make sure they aren’t missing a bet.  You may be a bad fit for what they think they need in the role.  The more you build up the job in your mind and get wound up about how you absolutely have to get it, the worse you are likely to perform.  So be hungry, give it your best shot, but don’t think it all rides on that one interview, because life is mostly not like that.

Don’t lie.  This should go without saying, but a lot of people seem to think it’s ok to fudge on a resume.  Who is going to find out, right?  Wrong.  In the age of Facebook and blogging and LinkedIn, it’s crazy to be confident that you can get away with it.  If the employer finds out that you have been deceptive, that’s probably game over.  And the world is a small place, so there is every chance that they might tell the next company you talk to.  So in addition to it being immoral, it’s also dumb.  Just don’t go there.

I hope that these ideas help you prepare for your next interview .. good luck!

Kissing Frogs Part 2: Conducting the Interview

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!

Kissing Frogs: Preparing for an Interview

One of the most important things you ever do is to interview people for a job on your team, and it’s hard to do it right – people don’t come neatly labeled.  But somehow, you need to figure out if this person is that great ingredient you can mix into the stew of your team and make it better.  I’m going to spend the next three posts on interviewing, and we’ll start with getting ready.

What Kind of Prince Do We Need?

We work at FriskyCo, a small technology startup, and we need to hire a great database engineer to design, build, and run our back end storage systems.  Let’s start out by making a very short list of hard requirements.  And really, these supposedly “hard” requirements are just “highly desirable” – somebody who has some other amazing strength might be a good bet even if they look very different from the person we thought we were looking for.

We’ll start with skills they need to have.  Ideally, our new hire would already be an expert in building, using, and maintaining highly scalable storage engines.  In fact, they’d have already done the job, with the same technology we want to use, for some other company.  Unfortunately, if we insist on that, there are a tiny number of people in the world who would qualify (the so-called “albino unicorn”).  We can hold out for that miracle, or we can accept more ramp and risk to get a broader candidate pool.

On the flip side, setting up a system like this is not for amateurs, so we aren’t willing to hire just any competent developer.  After a bunch of debate, we’ve decided we should look for these “hard” requirements:

  • Has built and deployed some kind of highly scalable system.
  • Is an expert at some industrial strength database system.
  • Is a skilled systems programmer.

But skills are not enough; it’s vitally important to assess team fit – whether the candidate will flourish in our team’s culture.  FriskyCo is a startup, which means we move fast and change our minds as we evolve the product.  They have to be able to handle uncertainty and not freeze or freak out.  They have to be inspired and passionate about the mission we’ve undertaken – we’re too small to have people who aren’t bought into the adventure.  We have a standard set of things we always look for as well around their nature – they are smart, not too arrogant, can handle pushback, and are driven to get things done.

Now we have a bottom line on what we need in a candidate (or at least what we think we need).  Note that we don’t have any requirements around education or “years of experience” – those can be useful indicators that somebody has what you actually need, but I think it’s a big mistake to focus on them rather than on your true requirements.

Architecting the Interviews

This is a crucial hire for us and we’re going to have a set of people talk to the candidate.  We’ve done a number of interviews together, so I have a pretty good sense of what each person does well.

  • John, the head of engineering, is a good all-around interviewer and does a great system design assessment.
  • Mary, the front end dev, has a good set of questions around designing a well factored database schema and a solid API.
  • Rajiv is good at straight coding questions.
  • I’ll test to see if they can handle our environment, if they have passion for the product, and if they have design insight.

By thinking about what each person should focus on, we are much more likely to get decent coverage.  Otherwise, everybody may ask coding questions and we won’t know if we have a good fit for the team.  Or, even worse, most people spend their time on team questions, and we don’t know if the candidate can actually build anything.  Also, the team is crazy busy, so giving each interviewer a concrete set of things to probe is much appreciated.  It isn’t a straight-jacket – if an interesting digression comes up during the discussion, everyone knows they can and should pursue it.  But each interviewer should really try to nail those one or two things that we’re counting on them to test, and have a firm opinion at the end as to whether the person is a hire from that perspective.

One tricky situation is that you are hiring for a skill that the team doesn’t have yet.  Suppose in our FriskyCo example, we don’t have anyone who knows databases well.  What to do?  Sometimes you can wriggle around this (maybe one of the folks can assess a schema, even if nobody knows how to design one).  But that’s pretty risky – it’s often possible for a glib person with weak knowledge to snow somebody who has even less.  So I always try to draft somebody from outside the team to participate in the interviews.  Maybe somebody from elsewhere in the company, if you are part of a larger organization.  A contractor you’ve worked with.  A friend who will pitch in as a favor.  There just isn’t any true substitute for somebody who is an expert at the thing you need to evaluate.

Interview Etiquette

Every candidate is interviewing us as much as we are interviewing them.  How they are treated will strongly affect whether they accept an offer, if we extend one.  So:

  • Don’t be clueless.  It’s really irritating when the interviewer isn’t sure what position you are interviewing for.  They haven’t looked at your resume.  They putz around, trying to figure out what to talk about.
  • Don’t be a jerk.  Enough said.
  • Don’t dither.  One of the most annoying things you can do is not to make a decision.  Interviewing at some places is like dropping a rock into a bottomless pit .. you wait, and you wait, and nothing seems to happen.  Get all the information you are going to get, and then make the damn decision.

Next, we’ll look at what to actually do during the interview.

Photo credit: Nickodemo

The Rip Van Winkle Question

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.

Manage Your Firedrill Capacity

Ah, the firedrill – that urgent project that your team has to scramble to get done by the deadline.  Everywhere I have been, they are an inescapable fact of life.  “We just got a key customer meeting and we’ve got to have that demo ready!”  “There is a VP review of the project next week and we have to nail it!”  “I need this analysis done tonight for the board meeting – they said we have to cover this compete angle!”  “Our customer’s site is down and we have to get them back up ASAP – drop everything!”

Some of this is inevitable – things come up, so you have to rise to the occasion and get it done.  But some teams seem to exist in perpetual firedrill – life is just an endless succession of crises and it feels like a treadmill; you never get the chance to move forward on the really important projects that could be game changers, because you are running as fast as you can to handle the constant stream of do-it-now projects that bombard you.

How much you can control this problem depends on the role.  If your job is to fight fires (literal or metaphorical), then maybe the firedrill is what you do.  But if your work is more project-oriented, my guess is that a lot of them could have been anticipated and avoided.  That’s been my experience.  Test it for yourself – keep track of the firedrills you are pulled into for a couple of weeks, and look over the list.  How many of them really came out of the blue and could not have been avoided?

The Magic Wand: Designing Good Systems

Systems and processes can make life miserable and are one of the things that people complain most about.  They can get rigid, bureaucratic, and generally suck the spirit and energy out of life.  BUT … they are the critical tool that can eliminate firedrills, if they are done right.  What I’ve found is that you must design them thoughtfully, hone them until they cause the minimum of friction, and throw them out when they are no longer adding value. You probably will benefit from a system when something is predictable, repeated, and complex.

  • Predictable: hey, it’s a new year and we have to get our plan landed – wow, who could have seen that coming?  Excuse me, but it’s been on the Gregorian calendar for around 430 years, so this really shouldn’t catch you by surprise.
  • Repeated: if you do something once, then designing a system may or may not pay off.  If you do it over and over again, you don’t want to lose the hard-won lessons of the past.  Figure out how to do it well and bake it into a system so that you don’t have to think about it.  We’d never be able to function as human beings if our bodies didn’t do this constantly – we couldn’t walk, talk, eat, read, or write.  We spend much of our early childhood evolving our neural systems to master the key activities needed for life – think about how helpless an infant is.  Reinventing the wheel every time you do something keeps your team in perpetual infancy.
  • Complex: if it’s trivial, you may (may!) not need to remember how to do it.  But as things get complex, you are wasting enormous amounts of time and operating very inefficiently if you don’t capture that knowledge into a system.

Firedrills are a great indicator that you need to do something – jotting down a line or two about each one will take you less than a minute a day and looking the list over will help you diagnose places where you have a missing system or a failing one.

Don’t Waste Your Firedrill Capacity

Every team has some capacity to absorb firedrills.  That capacity increases as people are more committed to the mission.  It increases with confidence in the team leadership – people figure that if the leaders say something is important, it probably is.  But if you burn through that capacity too often, or you waste it on things that are obviously just screw-ups in planning that could have been prevented, you’ll pay the price.  People will get grumpy, cynical, burned out .. and eventually will leave the team.

So manage that capacity.  Fill the tank by fostering trust and commitment.  Avoid burning it up on dumb things that you could have avoided with some thoughtful planning.  Come clean when you screwed up and the team has to pay for your mistake.  And then when you really do need them to commit heart and soul to pulling off something heroic, the team will be right there with you, ready to dig deep and gut it out.

Rubber Gloves, Not White Gloves

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.

Eyes of a Stranger

I’m always looking for best practices to adapt and adopt, and I got an idea that I really like from a mentor.  It is a way to combat the complacency that sets in as we settle into any role – that tendency to become accustomed to the way things are, even when they are pretty screwed up.  “Well, of course you stand on one foot and tug on your left ear with your right hand .. that’s just how things are done here.”  With fresh eyes, we might ask “but, umm, isn’t that kind of stupid?”  And, “about the fire burning over there .. maybe throwing some water on it would be good?”

So periodically – maybe once a quarter, or once a year, the idea is to do an exercise I like to call “eyes of a stranger”.  Pretend that you just got your job and are figuring things out – you are in your “first 30 days” and are coming up to speed on the important things you need to focus on.  What is a top priority issue or opportunity that you would see and decide that you absolutely have to pursue?  What inefficiency would you discover that would just bug you until you got it fixed?  What joy-killer is afflicting the team (or you) that needs to get taken care of?

There’s a scene from a book that got stuck in my mind; it’s in Kon Tiki, the really fun story about an anthropologist who gathers a set of kindred spirits to prove that it is possible to sail a raft from the Peruvian coast to the Polynesian islands, using only the technology available in ancient Peru.  At the end of the book, they have crashed on a reef and the raft is smashed, they are pinned down and waves are pounding over them, and one of the people clinging to the remains of the boat says calmly “This won’t do.”  I try to apply that same calm but determined spirit to situations at work that feel desperate.  As you look at your job and the environment around you, what “won’t do” that you’ve gotten used to and have been letting slide?

I’ve found that you probably want to come out of the exercise with a very short list of things you are going to pursue more aggressively than you have been – one is good, three is probably an absolute max.  If you come up with a longer list, revisit it after you do something about the top ones.  I tend to find that you get wildly more bang for the buck by focusing on a couple of things (or one!) rather than dutifully writing down ten “priorities” and feeling overwhelmed so you just go back to ignoring them.

For each of the issues that you’ve picked, you need to figure out what concrete steps you can actually go take to deal with them.  I like to sit down with a piece of paper and do a mind map.  If the issues are worth addressing and you haven’t been doing it, it’s a good bet that you are a bit stuck in figuring out what needs to be done.  Maybe you just need to spend 30 minutes listing next steps or coming up with a plan.  Or, perhaps it will work better to pick somebody you have a good rapport with, and brainstorm about it together.  If it’s a really big issue, you might find it helpful to apply (some of) the framework that I outlined in the series on “Cracking the Nut”.

I’ve done this exercise over a dozen times, and each one has helped me get hard core about tackling something that needed doing and that wasn’t moving forward.  See if it works for you, too!

Beware the Shining Paladin From Afar

Companies often fall into the trap of believing they can hire some external person to be their salvation – a shining knight who will lead them out of the darkness and into the promised land.  There are times when this works, but in my experience those are overwhelmingly outnumbered by the failures.  Why?  And can we learn something from the failures to try and avoid them?

The idea is very appealing.  If we as an organization are failing – maybe we are getting creamed by some competitor, or our formerly successful product is moldering into obsolescence and we can’t seem to get with the program on a modern reinvention of it.  Shouldn’t we invigorate the tired old blood in the team with a turbo-shot of new thinking?  Well, maybe.  But if we do, we’d better think about the many ways that this tends to fail.

Internal Pathology

We might be failing because of a systemic problem within the company.  This problem might be organizational (there is no team that cleanly owns the charter, so it keeps falling between groups), personal (somebody influential and passionate is preventing us from pursuing a workable strategy), failure of execution (the team that owns it isn’t healthy or effective), failure to focus (the team that owns the problem fundamentally doesn’t care about solving it), or strategic (the team gets pushed by company leaders into building overly general solutions that collapse of their own weight).

Fixing these problems can require a lot of organizational savvy and trust from the rest of the company; a newcomer is often much less capable of solving them than a seasoned employee.  Add to that the burden of expectations, and you have a situation designed to create failure.

Teacher’s Pet

Many times, I’ve watched a senior person get frustrated with a team, so they stick in some new blood and hope for the best.  The team can resent the newcomer as a teacher’s pet or “golden child” who hasn’t paid any dues.  Who are they to come in and start shooting off their mouth, without knowing anything about the team or the product?

For example, a friend of mine was hired by the president of a division to come in and shake things up in a new direction.  My friend gave an exciting pitch about the opportunities the team had and wasn’t taking advantage of.  He was put inside a group that had no buy-in to those new ideas, and which took its cue from somebody who had helped create the division and been responsible for some of its great successes.  Who also wasn’t bought in.  How receptive do you think the team was to my friend’s ideas?  Right, zero.  It was a massively frustrating experience for him and a waste of energy for the team, which of course went on to do exactly as it had before. 

Cultural Rejection

Teams can be a lot like the immune system, which “will try to destroy or neutralize any antigen that is recognized as a foreign and potentially harmful invader.”  People coming into the team, especially people brought in because they think differently and aren’t bound by the dominant assumptions shared by everyone else, are just bristling with antigens.  They use different language and terminology, they say things that seem off-key.  Often the instinctive rejection is so strong that their ideas don’t get a fair hearing.

Missing Key Skills

Having worked at both startups and large companies, I know how deeply different the success factors can be in those two environments.  People who flourish in a smaller community don’t always have (or value!) the skills to negotiate the internal landscape of a large company.  A big company might hire somebody who was winning, and the big company hoped that this person can transform its efforts.  If I’m that new person, why would I abandon my successful approach and adopt ideas from this team that has failed?  What could they have to teach me?

The problem is that the way you run an independent team for success, and the way you run a team inside of a big company, is quite different.  There is some overlap, but there is a lot of non-overlap.  As the new person, I have a lot to learn.  It’s very hard to figure out which traits I bring that are uniquely valuable and must be preserved, and which ones I have to supplement or replace in order to be effective in my new environment.

Wrap Up

I’m certainly not advocating that companies refuse to bring in new blood – it is crucial that they do.  But those people, especially if they are brought in to turn around a failing situation, have to negotiate a minefield.  The company needs to think hard about whether the problem it has is one that an outsider is really equipped to solve.  And it can’t expect that outsider to solve it alone – he or she is likely to need seasoned partners who can help translate that new perspective into a form that others can understand and act on.  Paladins seem like lone crusaders, but they wouldn’t have gotten very far without a host of supporters ranging from squires to armorers (not to mention the most important one – their horse!).  Before you try to hire one, make sure it’s what you really need … and don’t leave them unmounted and unsupported, or you are likely to have a bruised and grumpy knight on your hands pretty soon.