You are here: Home / Archives for 100x

Eyes of a Stranger

June 1, 2012 by Leave a Comment

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!

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

Relay Race vs. Diving Competition

May 25, 2012 by 2 Comments

When you are evaluating how people are doing, it seems reasonable to focus on the business results they deliver.  In my previous team, we called this the relay race model.  What matters in a race is finishing, and finishing with the fastest time.  Nobody cares whether your running form was good or terrible – you are measured solely on the results you deliver at the end.  In most work environments, this is appealing, intuitive, measurable … and wrong.

A diving competition is almost the exact opposite of a relay race.  After all, everybody is going to hit the water, and it will take about the same amount of time no matter what you do.  The score is based on your form – how difficult a set of moves you undertake, and how gracefully and perfectly you do them.

Why the Diving Competition Matters

So what does this have to do with measuring job performance?  It’s the difference between assessing the pure business results that somebody delivers vs. the way they delivered those results.

It’s easier to measure (and talk about) the results that were delivered.  Did the product ship?  How much revenue did it generate?  Did you hit your sales quota?  Was the code quality where it needed to be?  Is the product performance hitting the ship goal?  It depends on your job, of course, but in many cases it’s relatively straight-forward to tell whether the person and/or the team achieved the goals that they were striving towards.

But there is another side of things – the way you behaved in pushing towards that goal.  Did you help build up the team?  Do people find you a good person to work with?  Do you help make the whole team better, smarter, and more capable?  I’ve worked with a lot of aggressive young engineers, and they sometimes are very impatient when I bring up these questions.  “Hey, I wrote the code, the product shipped, and it’s good.  I didn’t have time to humor those other idiots – we were on a tight schedule.  And I was right, wasn’t I?”  Often, yes.  But you are still going to get dinged on your review, because you may have been right about the issue, but you didn’t handle it the right way.  By running roughshod over the other person and leaving them feeling dismissed and mistreated, you blew it.  Why?

Well, for one thing, you are only responsible for part of the project.  Checking high quality code into the build is important, but the crucial thing we need to do is solve the customer’s problem.  Which means we need to understand their problem holistically, build a complete solution that meets their needs, test it, explain it and then sell it to them, support it, and integrate with other products.  That calls for a group of people to work effectively together.

Also, a particular deliverable is just one in a long succession of business results that we have to achieve together.  Sure, we shipped the product .. but that was just the beginning.  Even with packaged software, we have to ship patches.  We immediately start building the next version.  If it’s a service, shipping is the beginning of the hard work, not the end – now we have to run it 24/7 and manage the business that is based on it.

All of these ongoing business deliverables rely on the team working smoothly together.  When you are working on a problem that involves groups of people, no single person’s work alone can make the whole group successful.  If you achieve the goal you are focused on but leave a path behind you strewn with dead bodies, you can easily do more harm than good even if you do achieve what you set out to do.  Every team member has as much of an obligation to help ship the team as they do to help ship the product.  Given our ongoing responsibilities, the team is often the more important deliverable.  In the software business, if we create an unpleasant working environment and everyone leaves, we’ll be left with a big pile of code and no ability to run it, fix it, evolve it, support it, and sell it.

So for very hard-headed business reasons, I think it is necessary to evaluate people based on both the relay race model (the explicit results they achieved) and the diving competition model (whether they work effectively with others).  If you only focus on one, you aren’t encouraging and rewarding the behavior that yields the most value for the organization.  And on a more personal note, who wants to be on a team that’s unhappy and mistreats each other?

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

What Do You Want to Be When You Grow Up?

May 18, 2012 by 2 Comments

When I’m managing or mentoring somebody, this is one of my favorite questions.  It’s a good way to crawl into their heads a bit, understand their motivations, and figure out how I can help them.  It’s also not a bad question to ask yourself!

Framing

There are different ways to approach the answer – you might base it on:

  • A particular person’s abilities: code like Guy Steele, move an audience like Meryl Streep, or paint like Raphael.
  • A particular job: be the VP of your division, the CEO of a Fortune 500 company, or the founder of a growing startup.
  • An achievement:  win an Olympic gold medal in swimming, design a piece of software that millions of people adopt, or take a company public.
  • A state of being: be crazy passionate about your job, feel that you are living in perfect alignment with your principles, or devote your life to serving the community.

How somebody chooses to answer will tell you a lot about their values, ambitions, and self-image.  Be careful about guiding them too much .. we’re talking about their dreams, not yours.

Cheerleader or Critic?

In doing this exercise with many people, it’s usually at least imaginable that they might achieve their ambitions with hard work and some (or a lot) of luck.  However, now and then somebody will come up with a goal where you have to struggle a bit to keep a straight face.  Often it’s about personality and passion – if you are impatient and can’t stay focused on your own, writing novels might not be your best bet.  So what do you do when someone who hates math wants a Nobel Prize in physics?

I try to be a “pragmatic cheerleader”.  I don’t want to be a dream buzzkill – most people are surrounded by plenty of those already.  But I also don’t want to be mindlessly encouraging.  The next question often helps to get things more grounded in reality.

What Does it Take to Achieve That Goal?

Dreaming big is great, but you have to break down the goal and figure out what it takes to achieve it.  One approach I like: if the person wants to be an X, I get them to write down a description of what the absolutely perfect X would be like.  For example, when I was running a relatively large team, I came up with what I thought a perfect team leader should do .. I wrote about that here.

Often, the person doesn’t have a great answer.  They are attracted to the idea of being a CEO, but they don’t actually know much about what the day to day life of a CEO looks like.  After some discussion, we can usually rough out an outline of the skills and qualities needed, but we often agree that a key next step is to validate that list with people who actually have that role or are more familiar with it than we are.  That’s a great practical step forward on the journey.

How Do You Stack Up Today?  How Do You WANT to Stack Up?

The next thing I do is have them assess themselves against those ideal qualities or skills.  At this point, people sometimes realize that their supposed goal doesn’t actually make a lot of sense for them.  I was talking to one person who thought they wanted to be the CFO of a public company.  We talked about the skills you’d need to be a fantastic CFO, and then she thought about when in her work life she had been really happy and why.  And she realized that the things that really did make her passionate and inspired were not the key activities of that job at all.  So I think that was a helpful moment of self-revelation.

This exercise also tests self-awareness.  Sometimes, they are confident that they have some needed quality .. and you think they are wrong.  It’s tricky to handle this.  I tend to tread pretty lightly – the goal here is self-revelation, not a lecture on their weaknesses, which tends to bring the discussion to a halt in a hurry.

But if people have at least a basic level of clue about their true nature and abilities, this exercise can have quite a profound impact.  I’ve watched people realize that they were carrying around outmoded ideals foisted on them by authority figures from their youth, and realize that they have an inspiring path open to them in a quite different direction.  That’s what you hope for – an opportunity to enable somebody to achieve a profound moment of self-discovery.

How Does One Actually Get That Job?

Next, I like to consider how people actually get the job or the opportunity to achieve the goal in question.  If it is a well-defined role, then the answer is usually straight-forward, but many people don’t think about it very practically.  I’ve repeatedly asked, “how do you become a VP” (or whatever).  People go on about a demonstrated track record, a well rounded set of skills, and all sorts of worthy things … but none of those are the real answer.

The actual answer is, “somebody who hires VPs chooses you”!  Now why would they do that?  All these ideas about skills and roundedness are fine, but often the true reason is that the hiring manager has confidence in you to do a great job and trusts you.  They’ll almost always pick somebody with strong skills, whom they deeply trust, over an unknown with a potentially stronger resume but who might be a whacko.  And they trust you because they know you over a long period of time, and have watched how you handle many different situations.  So one of the things that might be necessary to achieve your goal is to deeply commit to a particular team or company for an extended period of time, rather than bouncing around all the time.

Alternatively, the goal might be something that has to be created rather than granted – becoming the CEO of a new startup is self-elected (!).  But they need to have enough money to survive without an income and perhaps to fund the company for a while.  They may need a network of people they can hire.  And so forth.  Pretty much any ambitious goal will require something in order to open up the opportunity.

What Are Your Next Steps?

Now they have identified the goal, what it takes to get that opportunity, what they need to be successful, and where they stand now.  For each skill or ability where they aren’t already strong and experienced, I’ll brainstorm with them about a specific action that will develop it.  For example,  they can often build up skills that aren’t a direct part of their job by volunteering for extra projects – what I like to call “hobbies”.  I’ve learned a ton from hobbies – helping to organize and run a large developer conference, participating in working groups considering radical new directions to take the team, teaching classes, etc.  None of those had much to do with my core job, but I practiced new skills, learned about new areas, met really cool people .. and had a lot of fun.

The goal is to finish the discussion by identifying very concrete steps that will build the skills they need to achieve their dreams.  And if you have an ongoing relationship, hold them to it.  If you can really help somebody achieve their dreams, that is one of the best feelings in the world!

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

Beware the Shining Paladin From Afar

May 3, 2012 by Leave a Comment

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.

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

On Being Acquired – Lessons Learned

April 30, 2012 by 2 Comments

Once upon a time, I was one of the three full-time employees at Colusa Software, which Microsoft acquired in 1996.  We all came to Microsoft as part of the buyout, and went on to learn some interesting lessons about having your very small company acquired by a very large one.

Who We Were

Colusa was building some nifty virtual machine technology – you could target it from any conventional language, could run in a protected sandbox, and could get close to natively compiled performance on a variety of hardware platforms.   Our dream was that we would contribute towards a VM for Windows that would ultimately run much of the software in the world.  Other companies wanted to acquire us, but we came to Microsoft because we thought it offered the best chance for our technology to be ubiquitous – we said to each other that it would be a place to build software that “my mom will use.”  That was a very powerful motivation.

What Happened

After we were acquired, we ended up in the Visual Studio organization.  It seemed to make sense because we needed to work closely with the compiler team to target the VM, but actually it was a mistake.  All of the major decisions about runtimes were being made elsewhere, and we had limited contact with the key people.  Many of them were already committed to other solutions.

The result was that we kept getting redirected from afar.  “Your VM would be perfect if the wire size was smaller than Java.”  Ok, we went and built a cool compression strategy that yielded extremely compact code.  “Your VM is out of the question because it isn’t compatible with Java bytecodes.”  Oh.  “Your VM is Microsoft’s future.”  Great!  “Your VM would be cool, but isn’t practical without a substantial modification to Windows that would require too many resources.”  But …  And so on.

Amidst these conflicting messages, we tried to soldier ahead.  We rebuilt our original system to work with Windows, and demonstrated that it worked  by recompiling Microsoft Word and running it on the VM with performance indistinguishable from natively compiled code.  Eventually the team helped design the bytecode strategy of one of the VMs in the operating system.  Although it wasn’t what we had originally hoped to accomplish, the ideas did influence the design of a part of Windows.

So, what did I learn from all this?

Lesson #1: Have a champion

By far the most important lesson is that you desperately want to have a senior person who is the champion for your group.  We didn’t have one, and we suffered badly for it.  The need is particularly acute if you walk into a politically charged area.  There were deep divisions in the company that we didn’t understand – it was confusing for long-time employees and utterly baffling to us.  We thought we had something that the company would eagerly seize upon.  Over the course of six months, we were told that we had one of the most important projects in the company, that our technology would be scrapped, and that we should redesign it in ways that we felt would be a disaster.  Not fun.

I don’t think anyone could have prevented the situation from being difficult and confusing, because the company was facing very tough and important decisions.  But at least we would have felt that somebody was in the key meetings advocating for us and then telling us what was happening.  I think the team was hurt, for example, by a feeling among some key partner teams that we were overselling.  We thought we had carefully explained that, for a commercially viable solution, we would have to rely on other parts of the company to deliver key missing pieces.  But that message didn’t get through.  This kind of disconnect happens all the time and is natural; people who hear about a technology without the details make assumptions about what it does and doesn’t deliver.  Teams have to actively (and continually) educate their partners.  We just weren’t talking to them.  In fact, we didn’t even know their names.

To a company being acquired, I can’t stress enough that you want a politically savvy champion who has the ear of the key architects, people in management, etc. and will go to bat for you when it is appropriate.  You want that person to be identified with the acquisition and their credibility on the line as to whether it succeeds or fails.  They should drive you hard and want to exploit your ideas for the maximum benefit of the company – after all, that’s what you want, too!

Lesson #2: End up in the right part of the organization

Many large organizations have teams that are quite autonomous from each other.  If you land in the right place, which we didn’t, the people around you will understand how to integrate your technology into the product portfolio of the company and be in a position to make that happen.  The key thing, though, is that your hosting organization is the one that drives the decisions that most directly affect you.

Lesson #3: Nobody trusts you

Getting acquired feels like a seal of approval.  It says that you were doing something cool enough that the big company felt it was better to buy it than to build it themselves.  That doesn’t prepare you for the likelihood that nobody in your new company will trust you at all.  They won’t believe that your code is any good or that your team is up to the standards of the rest of the organization.

As far as I’ve seen, there are only two solutions:

  • Seed your team with some experienced and trusted employees from the big company.  This is a great idea anyway, because in addition to providing credibility, they can also be enormously helpful in getting things done in your new environment.
  • Ship and win in the marketplace.  That’s the ultimate coin of the realm in any software company.

Final Thoughts

There were ups and downs throughout the experience, but I learned an enormous amount from being acquired by and working within a large company.  I’m doing my third startup now, and hopefully applying lessons learned from all the experiences I’ve been fortunate enough to have along the way.

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

Use the “Pet Rock Principle” for your next project review

April 24, 2012 by Leave a Comment

Ah, the project review.  Like death and taxes, if you work in a larger company, these are probably an inevitable fact of life – at some point, and maybe quite frequently, you have to get in front of somebody senior and give a review of the state of your project.  At Microsoft, the ritual of the “BillG Review” was woven into the culture when Bill ran the company.  Your review might be anything from a routine monthly status update to a high stakes undertaking with people who have the ability to cancel the project (and/or fire you).

Designing a great review is complex and involved; you want to tell a compelling story that resonates with your audience, to distill the work into its essence, and to convince that the team is executing well and should continue to get support.  These reviews can take on a life of their own and soak up tremendous amounts of time that could be (much) better employed in getting the darn work done, rather than talking about it.  This is one of the reasons that small organizations can be more efficient – they don’t need to prepare reviews of the work they are doing, because everyone is too busy getting it done.

Enter the Pet Rock

To avoid getting bogged down in an expensive manage-up exercise, when I’m preparing for a review I try to stay focused on what I call the “pet rock” principle.  If you didn’t grow up in America in the 1970’s, you might not have heard about the pet rock – it was a hilarious (and self-mocking) fad where people bought a rock, instead of a real pet, because they are much less trouble to take care of.  Pet rocks were very good at some tricks – as the instruction manual explained, they excel at “sit” and “stay”, but struggle with “shake hands”.  Since the pet rock is an iconically useless object, it seems like the perfect stand-in for some members of senior management, as seen from the trenches.

The principle that’s guided me through many reviews (on both sides of the table) is that most of the value from a really good review would be achieved if you replaced the audience with a pet rock.  In other words, the review should be mostly designed to benefit the team, not the reviewers.

As easy as it is to get cynical about reviews, they can be a valuable exercise.  They force you to:

  • Articulate the goals, strategy, and execution plan for the project.  As I have repeatedly advocated throughout this blog, there is magic to writing things down.  It forces you to think much more carefully and systematically than you usually do.  A review is a great opportunity to tell your story to your own team.  Usually the leaders of a team assume that everybody “gets it” .. and often that isn’t true.  It’s incredibly valuable for the team to walk through the vision, the strategy, and the plan.  From research in advertising, we know that people do not absorb a message until the third exposure (and some studies have yielded much larger numbers).
  • Distill the essence of the work.  Senior people generally get bored easily, so they won’t let you maunder on at endless length about what you are doing.  They want it summarized into a succinct and effective form.  Figuring out how to capture the work you are doing in a tight and lean format is a powerful exercise.  And it’s hard.  Often you won’t bother to do that work until you have a forcing function, and the review can be that forcing function.
  • Enumerate top issues/risks and what is being done about them. It’s easy for teams to get desensitized to their biggest problems.  “Well, yes, there is a blazing fire over there that threatens our success, but it’s been on fire for a while and we just don’t have time right now to worry about it.”  Reviews can force you to think those problems through and make sure you have a plan to resolve or mitigate them.

An excellent review can be a morale booster that reminds everyone of the exciting mission that they are on.  It can identify issues that are falling through the cracks, and can help you to hone your execution.  Mostly, that isn’t how it works, though – they provide modest benefits (at best) for the team, and they represent a bunch of overhead that saps precious reserves of energy and enthusiasm.

So if you are pulling a review together, see if this principle helps you stay focused.  Constantly ask yourself whether you are working on something you would truly continue to do if there were a pet rock presiding over the review.  When the answer is no, you are just managing up.  You may have to do some of that, but the more you do, the less you are advancing the organization’s true interests, and the more you are creating the overhead that everyone complains about.

Omit needless work .. and remember the rock!

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

Ready to Ace Your Exit Interview?

April 18, 2012 by Leave a Comment

When I’m having a management or a mentoring conversation, I like to pose the following challenge: “You just got offered an amazing new job .. it’s one you’ve always dreamed of.  But before you leave, you have an exit interview with your manager and your successor.  What do you want to tell them about your tenure, your team, and your projects?  What burning issues will your successor inherit and are they on track to being resolved?”

The answers depend, of course, on the nature of your current role.

  • If you are a manager, you probably want to talk about what a great, high morale team you have.  How the people are on a good trajectory, or how you are working with the ones who aren’t to get on a clear path for addressing the problems.  How you have a strong bench of future leaders you’ve been developing (hopefully your successor is one of them).  The mission is inspiring, the goals are clear and reflect the biggest opportunities available, the strategy is compelling, and the execution is effective.
  • The projects that you are responsible for are on a great path to success.  As you leave, things will continue seamlessly forward because the work is well organized and you have made sure that it an be passed over cleanly to somebody else.  No commitments will be missed, no balls dropped.
  • The issues that potentially block success have been analyzed and are being addressed and/or mitigated.

If you can say all that, congratulations on having aced your exit interview!  The person who is taking over for you is truly set up for success, but they have some big shoes to fill.

*****

Is that how it’s going to go?  If not (and I have yet to meet anyone who says it will!), what are the biggest reasons you won’t be taking a victory lap at your exit interview?

Usually, I find that there are a handful of big issues that people are worried about and that aren’t on a good track to resolution.  They might be:

Unpleasant.  People problems often fall into this bucket.  Sure, things aren’t great, and yes, something really ought to be done about it, but dealing with it is going to suck.  It’s often doubtful whether there will be a clear resolution at the end, especially if the other person doesn’t work for you and hence you have limited options for adjusting the situation.   So, it’s easier to just avoid the whole thing and keep bumbling along.

Important but not urgent.  Creating that new market would be an amazing win for the company.  Hiring a senior architect could transform the ability of the team to build great software.  But there is no particular urgency – no deadline will be missed, there is no forcing function.  And there are a hundred emails to answer, and that milestone is coming up, and my schedule is packed, and …

Hard.  I know that I should really be working on this big issue or opportunity, but I don’t exactly know how to do it.  I have to go get educated in some new area, or break through a tough analysis, or learn a new skill that I secretly fear I’ll be lousy at.  One way or another, it’s going to be a ton of work, and I’m not sure that I’ll really get anywhere, and my plate is full of things I do know how to do.

I’ve found that these big issues that people feel bad about are often the most important things they should be focused on.  So, I get them to write down the list of those issues, and then I ask the key next question: what specific actions are you going to take about each one, and when?  Because feeling bad doesn’t accomplish anything .. you need to take action.  I keep track, too, and the next time we talk, I bring it up again to see whether there has been progress.

Are you ready to ace your exit interview?  Why not?  What are you going to do about it?

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

Do You Want To Work For You?

April 12, 2012 by Leave a Comment

So here’s your challenge: you just got a new manager and it is … yourself.  How do you feel about that?  I think it’s a good test to figure out what managers are for, and how to be a better one.

Say you are Worker Bee, pounding away on a daunting array of projects.  And your new manager is Fearless Leader, who happens to be your exact clone.

Are You Happy?

If you aren’t happy and excited about having yourself as your new manager, you should think really hard about why not.  Mostly, those reasons are things you need to fix, because they will bug other people who might work for you, too.  And no, you aren’t so fabulously special that you need a different kind of manager than all those “normal” people.

A reasonable sounding answer (that I think is bogus) is that you want a manager who is much more experienced and senior than you are, so you can learn from them.  Sure, maybe, but there is a good chance in life that you will be managing people who are just as experienced as you are, or more.  So you’d better find ways for managers to add value, even when you aren’t wiser and more expert than the team, or there are going to be a very limited number of management roles you are going to be good at.

You Won’t Be Clones For Long

One of the interesting side effects of a new role is that it inevitably changes your perspective .. and it happens much more quickly than you’d think.  As Mark Twain says, “You tell me whar a man gits his corn pone, en I’ll tell you what his ‘pinions is.”

Worker Bee will start grumbling that Fearless Leader doesn’t understand how difficult some of the challenges are in getting the key projects done on time and needs to back off.  Fearless Leader thinks that Worker Bee is mired in the details and just can’t get with it on the big picture.  Why can’t he understand what is really important, and why does he keep going dark on key issues and leave me, Fearless Leader, out of the loop?  And so forth.

That’s both good and bad.  It means that you will each have to do some work to understand the other’s point of view, but it is also the key that will solve our puzzle.

How Does Fearless Leader Add Value?

There is some notion that managers are supposed to be wiser and more skillful than the people working for them.  But often, they aren’t.  And especially as you get more senior and manage larger teams, it’s pretty much impossible to be better than all of your direct reports at their job.  You will have people working for you with years or decades of experience and deep expertise in their fields .. fields that you often know little or nothing about.  At an extreme, a CEO is very unlikely to be a better engineer than the VP of engineering, a better marketer than the VP of marketing, AND a better salesperson than the VP of sales.  But the CEO is still supposed to lead the team and add value, despite being (often) incapable of doing their job.

In our thought experiment, Fearless Leader is fortunate enough to start out exactly as skillful and capable as Worker Bee.  But, he adds exactly zero value from his additional expertise – he hasn’t got any.  In fact, very shortly he’s going to know less than Worker Bee.  He’s going to meetings (maybe useful ones, or maybe about exciting things like “building an empowered team and enhancing manager capability”) while Worker Bee is writing code or designing products or whatever it is that he or she does.  Fearless Leader’s “doer IQ” will probably be on a steady slope downward, especially if Fearless is a good manager and keeps getting more responsibility.

The more cynical among us might say that Leader’s job is to “do no harm” while others get the job done.  But that is selling the job of manager too short – there are a lot of ways that they should be helping the team:

  • Clearly articulate the mission, strategy, and execution plan.  Since we know that Fearless has no lock on expertise in the team, they aren’t supposed to be the all-knowing sage.  In fact, they generally will not (can not) be the most knowledgeable person about the details of most issues.  Sometimes the answers are defined by somebody else – maybe Fearless’s manager has made it clear what the mission of the team is.  Fearless might not be a programmer but has a lead developer who owns the coding plan and schedule.  Exactly how the mission and plan are determined can vary all over the map – that’s fine.  The thing that Fearless must do is make sure that there is a clear plan, that it has been appropriately validated, and that everyone who needs to know is kept informed.
  • Be a channel of communication up and sideways.  Fearless is in meetings with people up the management chain and in other teams, while Worker Bee is heads down getting things done.   Fearless should be acting as a communication network up, down, and sideways .. representing the team, getting information about what’s going on elsewhere, and bringing it back.
  • Be a fair advocate.  When people are being evaluated, Fearless needs to be a strong but honest advocate.  He or she needs to make sure that everyone in the management team understands the performance of the people on the team, that compensation and promotion are being handled well, and so forth.
  • Be a great coach.  As the manager, Fearless is “watching the movie” that Worker Bee is acting in.  Just like you get a totally different experience (often uncomfortable) watching a video of yourself , Fearless is in the audience for Worker Bee’s movie.  That puts Fearless in a great position to give honest feedback, push Worker Bee to go beyond the comfort zone, and hold Worker Bee accountable.  The best tennis or basketball players in the world have coaches, whom they could generally crush in one-on-one competition .. but still get tremendous value from.  It may be harder, but you can be a fantastic coach without being better at the activity than the person you are coaching.

These are things that I believe managers should be great at, regardless of whether they are more experienced than the people working for them.  Master them, and I think you will be able to say honestly that you’d be a great manager for yourself.

How do you stack up?

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

What Should Managers Do All Day Long?

March 5, 2012 by 3 Comments

What managers spend their time on is often the source of (frequently cynical) commentary by the people who work for them.  I have found that it is also a source of anxiety for a lot of managers.  They often aren’t quite sure what they should be doing to add the most value.  It becomes even tougher, I’ve found, as you get more senior and have larger organizations to worry about.  You become very detached from the real work that is going on and what you do seems pretty distantly related to anything concrete.

Let’s take an example.  When I was the general manager of a pretty large team (400 people), I had a clear idea what the team needed to do – deliver a high quality next release of the product and grow the business 20% this year.  Great, but since I’m not writing any code or carrying a quota, how do I contribute to those goals?  What do I prioritize Monday afternoon at 3pm to help the team hit its goals?

To keep my sanity, I needed something that was my north star.  I created a document which I called “My Job”, and I reviewed it at least once a week.  It has the activities that I did, not the goals of the team.  For example, the first one is “Inspire” – I want to inspire the people on the team with a vision of where we are headed and why it is important and convince them that it is within reach.  Another is “Drive Rhythms” – for a team at scale, you have to have efficient rhythms to review the state of the business, check in with the engineering team each milestone, manage budgets, etc.

I scheduled an hour every Monday morning to plan the week, and one of the most important things I did was to take the “My Job” page and walk through these four steps:

1.  What’s F-ed up?

For each activity, I asked myself the question, “what’s f-ed up?”  And if I felt ambitious, “how can I move this forward proactively?”  This was an opportunity to dump all the hopes and anxieties buzzing around in my head down on paper.  The key thing was not to hold back – I wanted to get it all out.  And I wanted to make myself think about each activity in case it needed more attention than I was giving it.

2.  What can be done about it?

Next, I went back through the list to figure out what could be done about everything I had written down.  I needed to be in a very different state of mind – to go from a free-flowing brainstorm to focusing on concrete steps I could take.  I’ve found that it can be hard to switch back and forth quickly – once I’m being detailed and practical, the ideas don’t flow as freely.  So that’s why I do the whole second column first, then go back and do the third.  The things in the third column are very straight-forward and doable (“next actions” in Getting Things Done lingo).  These are specific actions I can do right away.

3.  Should I be the one doing it?

One easy trap to fall into (I am highly prone to this) when you are a manager is to over-function .. to jump in and do work that properly ought to be done by the people who work for you.  It’s like the over-protective parent who does everything for their kids, so they never learn how to do things for themselves.  It’s very annoying for the direct report who wants to solve their own problems.  So before I start firing off emails and diving into all those actions, I look them over to make sure that I’m the right person to do them.

4. Am I doing the really important “only I” things?

One of my favorite questions on this front comes from Peter Drucker, who was one of the people who basically invented management theory.  He wrote many useful books (try “The Essential Drucker” if you are interested – it’s a good survey of his ideas across a variety of topics).   And he challenges managers to ask themselves a very important question: “What can I, and only I, do, that, if done well, would have the most impact on the organization?”  This is a great question to ask yourself.  I suspect that every action item you identified is a useful thing to do, and will be of some value for the team.  So the question shouldn’t be “what adds value?”  Most or all of them will, hopefully, if you have a clue.  The question is, “what adds the most value that nobody else can do?”  Make sure you do those, before you fritter away all your time doing random things that aren’t going to have as much impact or that somebody else can do equally well.

Once I’ve gone through this exercise, I really feel like I have a handle on what I am worried about, what I should be worried about, what I could do about it, and what I will do.  This exercise translates high-level goals like “grow the business” into “set up a meeting with Mary to adjust quotas” and turns “ship a high quality release” into “review the latest benchmark numbers on the performance issues with the new version of the database.”   And it (helped) keep me out of the way of the team when they didn’t need me.

Do you have a north star that tells you what your job is?  What tools help you figure it out?

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

The Sacredness of Ownership

February 24, 2012 by 1 Comment

sa·cred (sā′krid) – secured as by a religious feeling or sense of justice against any defamation, violation, or intrusion; inviolate

The word “sacred” is not one to be used lightly, but I chose it on purpose to talk about a principle I believe is at the heart of any healthy team culture: ownership.  I’ve spent most of my career building large scale software projects, and these are intensely complex systems.  No one person can understand all that complexity and track all the infinite detail of a large-scale project.  And it only takes one person writing a few lines of sloppy code to introduce a security hole that can cause tremendous damage to your customers and to your company.  The success of the whole venture rests on the decisions that the people at the front lines of the team are making every day.  So they’d better feel like they own their work, and they’d better be right!

What It Means to “Own” Something

Does “owning” something mean you get to do whatever you want with it?  No.  In defining ownership, many people focus on making decisions, which is important.  But to me, the most important thing about being an owner is that you are accountable for the success of what you own.  Therefore, the first and most important thing that an owner should do is to define success.  This sounds easy, but it isn’t, and many people do this wrong.  If you are a developer and own a feature, success doesn’t mean that you wrote good code and checked it in.  Success means that the whole feature team understands the feature and why it is needed, you coded it, you nailed the basics like performance and security, it works well, it shipped, and many happy customers are using it to solve real needs that they have.  A good owner defines success in terms of impact, not activity.  They include key stakeholders.  They feel accountable for the whole success, not a narrow part of it.

It is very tempting to define success in terms of what you control.  This is a classic mistake that people make, especially when they are early in their career.  They only feel accountable for the part they fully control.  “But I’m the developer .. isn’t it enough that I write great code that works?”  NO.  The customer does not care if you wrote good code.  The customer cares if you solved their problem.  Shareholders don’t care if you wrote good code.  They care if customers love the product and buy a lot of it.  You need to feel accountable for the whole success, even though you almost certainly don’t control it.  If you did everything right that you control, and the feature fails to be successfully used by many happy customers, then you failed.  The reason this is so important is that people generally try very hard to succeed.  If you define success broadly, you won’t settle for the excuse that “my part works – it was the other bonehead who blew it”.  You’ll go the extra mile, you’ll escalate if somebody else is screwing up and taking the whole ship down.  It doesn’t matter how beautifully you polished the handrail on the Titanic.  You still drowned.

Decision Making and Overlapping Ownership

One thing that’s confusing about ownership is that multiple people can seemingly own the same thing.  For example, the people designing a product and the engineering team that builds it all need to own what they work on.  Doesn’t that violate the whole idea of ownership?  No, if you internalize the accountability model.  All of the groups contributing must feel accountable for the whole success of their work.

Great, but then how do decisions get made?  The answer is that it depends what you are deciding.  For example, the ultimate decision maker about the way to code a feature better be the developer.  But there are other stakeholders – developers might have to do a code review with their lead or a fellow developer.  They might need to follow development guidelines set up by the development manager, so other people can understand the code and it fits in with the rest of the system.  The designer needs the feature to actually meet the user’s needs.  The developer still owns the code and is accountable for its success, but they must honor the (legitimate!) roles of other people in achieving that success.

Stakeholders

Let’s say you are the owner and hence the decision maker.  One of your responsibilities as owner is to understand who else has a stake in the decisions you are making and what their role is.  Sometimes this is obvious, or you can just use intuition and it all works out.  That’s often the case in small teams.  But as you own more important and complicated things and are part of larger organizations, you will run into the limits of the ad hoc approach.  That’s when it becomes useful to think explicitly about the other stakeholders and their roles.

Once upon a time, the Windows team realized that decision-making was a mess – people weren’t sure whom they had to consult, who was the butt on the line for key decisions, etc.  And so things fell through the cracks or there was gridlock, and accountability was lacking.  As a result, they created a role/stakeholder model that has been used with a lot of success at Microsoft (called OARP).  There are industry equivalents (a popular one is called RACI) – which one you pick isn’t that important.  The key thing is to be explicit about the roles in a particular decision and make sure everyone understands what their role is.  Writing this down will often reveal misunderstandings (“what do you mean I don’t get to review the decision before it is finalized??!!!”) and problems (“we have to review this with twenty people before we lock the decision down?  That’s not going to work.”).  In general, the owner’s life and the team’s efficiency will improve radically as you reduce the number of reviewers, approvers, and other obstacles to progress.

Dealing With Misbehaving Stakeholders

Just because you have done a great job defining the ownership model and gotten everyone to understand it and agree to it in theory doesn’t mean that’s actually how things are going to work out.  People will frequently violate their role, often through the best of intentions.  Maybe your lead says you are the owner but they don’t respect your ownership and are always micromanaging you or giving direction to your team without including you in the conversation.  Maybe people elsewhere in the organization who are supposed to review decisions start turning into participants or are making decisions on your behalf.  And so forth – the opportunities for misbehavior are legion.  Sometimes they happen because people are too eager to help, often because people are being thoughtless, and sometimes from malice.

Your responsibility as the owner is to treat these as problems and get them fixed.  That super-helpful senior manager who comes down and straightens things out for you without you asking for help?  Problem.  Either you blew it, or that very helpful manager did, or you both did.  The participant who thinks you are blowing it as an owner and second guesses your decisions without confronting you about it?  Problem.

If someone in your management chain comes in and starts proclaiming this and that, there are two common reactions: 1) denial/rejection/anger and 2) “yes, sir, thank you”.  Both are wrong.  The right response from the owner is “good input, thanks”.  Then YOU go take action.  Don’t ignore what the manager thinks.  Sometimes they are giving you new data, sometimes advice (hopefully good).  Sometimes you are screwing up and they feel a need to jump in.  But if you are going to be a good owner, then you have to get the dynamics right.  You own the decision until ownership is taken away.  That should always be an explicit act – you might ask the manager to take over, they might inform you that they are taking over; that can be the right thing, but it is a very important change in the state of the project.  If ownership is leaving you and going somewhere else, you are no longer accountable for success.  That’s a big deal, and everyone needs to be clear about it.  You don’t have the right to demand to stay on as owner if your manager becomes convinced that you are not up to it.  You do have the right to demand clarity.

Final Thoughts

In my opinion, ownership is a crucial tenet of a healthy team culture.  How to take action on it?

  1. Figure out what you own.  Make sure everyone (including your manager) agrees.
  2. Define success.  Don’t be narrow.
  3. Figure out who the stakeholders are and respect their role.
  4. Go own the hell out of it.  Everyone is depending on you to get it right.
Filed Under: 1000x, 100x, 10x, 1x, Managing People Tagged With: , ,
«Previous Page
Next Page»
%d bloggers like this: