Tuesday, March 3, 2009

Employees should be masters of their own time

Every startup should have a culture of learning. That's easy to write, and I forgive anyone out there who thinks that is too much of a platitude to any meaning. I'm also skeptical of people who suggest "changing the culture" as a prescription to fix a company's problems, because that just begs the question of how company cultures change. Without entering into that theoretical domain, in this post I'd like to try and offer a specific and concrete suggestion for how to build a culture of learning into a startup.

The suggestion is that you implement one single company-wide rule. The rule is simple: every employee is 100% responsible for how they spend their time. If it sounds simplistic, let me try and make the case that it is actually quite radical.

For example, let's consider job descriptions. When I was a manager, I was once leading a cycle post-mortem. We were talking about what went right and wrong in the company's development process, when one (relatively new) employee said something like "I noticed that problem, but I couldn't do anything about it." I asked why. He obviously thought I was being dense, and told me "it's not in my job description." I asked, "how do you know what your job description is?" Now he really thought I was nuts, replying "from the recruiter who hired me, of course!"

It was my turn to be dumbfounded. Of course, we use job descriptions for recruiting, but it had never occurred to me that somebody would take them literally. But once I was confronted with the situation, it seemed obvious. What else was he supposed to go on? I realized that, although I personally believed in the policy of trusting employees to know what they are supposed to do, I hadn't taken the necessary actions to build that trust into the culture of the company. Oops.

So we instituted a new policy on job descriptions, which I would take pains to reinforce whenever I could find an appropriate segue. It was, simply, that every person in the company has this job description: in any situation it is your responsibility, using your best judgement, to do what you think is in the best interests of the company. That's it. Everything else is only marketing.

This is not an easy policy to implement. Most people think it can't possibly work; it sounds like a recipe for anarchy. But it's not. If you're hiring creative, resourceful and smart people (and you are screening for that, right?) you don't need to worry about them suddenly going off the reservation and deliberately harming the company. And if you're giving them all of the information they need to understand the company's strategy, customers, and processes, you can be confident that they'll be able to apply that understanding to their current responsibilities.

What's that you say? You're not currently doing all of those things? That's too bad, because if you don't keep your smartest people fully-informed, you're going to wind up telling them what to do. And telling knowledge workers what to do is one of the biggest causes of mistakes, waste, and general low morale that I've ever seen.

Taking this radical view thus leads directly to other important process improvements. In order to have everyone understand the company strategy, we opened up our board and board of advisors meetings to the whole company, not just a select few. In order to give people the data they need to apply the strategy, we were very open with our company metrics, making all reports generally available and easy to run. And we presented the full company P&L every month, as soon as we got it from our controller. And it requires a formal process for on-boarding new employees (including root cause analysis when it goes wrong) to make sure everyone understands their job description and what it means day-to-day.

If you've never engaged in radical transparency before, you may be anticipating problems already. What about when you have to present bad news, doesn't that impair morale? Board meetings are frenetic, doesn't that lead to confusion about what the plan is or who's in charge? Those are valid concerns, and I've had to cope with them and many more. But the coping is actually extremely useful. By forcing these issues out into the open, transparency teaches you what your employees are really thinking. Over time, your whole team will become much more aligned, and able to handle the inevitable curveballs that circumstance delivers. Mutual trust is a prerequisite for rapid response.

Let's return to my initial promise, that giving employees 100% responsibility for their own time will lead to a culture of learning. Part of the way it does that is by creating transparency. But it has a corresponding impact on employee responsibility.

This policy doesn't leave much room for excuses. Take a failed product launch. At IMVU, these were quite common (after all, we're shipping code 50 times a day). Lots of those features would turn out to be a bad idea. I expected a certain amount of grumbling, since nobody likes a failure. But I didn't have any patience for one particular complaint: "I knew it wasn't going to work!" There is no room for this idea in a company that insists that every employee owns their own time. If you know something isn't going to work, it's your 100% responsibility to speak up and prevent it from happening. That may lead to a lot of arguments, but that's what you want. When smart people clash over prediction of the future, two critical things happen:
  1. They are forced to make their predictions specific. This is a prerequisite for institutional learning. When you think a certain feature will give a 50% boost to a given metric, and it only eeks out a 5% boost, you can't spin that as failure. But if you weren't specific about the goal, 5% can be rationalized as success.

  2. People share their assumptions and prior thinking. Often arguments result in one side being convinced, because the other side has real data to support their conclusion. Other times, it will be revealed that one party or the other is making empty assertions, or relying on credentials. You want those situations to be painful.
Over time, a team that feels this level of responsibility gets used to using data to justify their decisions. What other basis is there for achieving reliable consensus? And it really cuts down in interdepartmental warfare, because everyone is considered qualified to understand the arguments used to justify decisions. In a level playing field, people's true expertise becomes evident. If your marketing team actually uses data to make decisions, your engineering team will be impressed. And if not, at least now you know and can do something about it.

I honestly don't know how startups survive without this sense of responsibility on the part of the people doing the actual work that affects customers. It's just so easy to check out, follow the plan, and not rock the boat. That may make it easier to get everyone to follow the plan, but I also think it makes it much more likely that you'll achieve a failure instead.

No, I do not mean masters of their own domain. Don't even go there.

Reblog this post [with Zemanta]


  1. This comment has been removed by the author.

  2. One of my favorite posts ever. This topic has been on my mind a ridiculous amount lately. Well done.

  3. I like this model. You should also read "Robert Noyce and his Congregation" by Tom Wolfe, Intel was apparently run this way in the early days as well.

    Richard Ackoff proposed a "Decision Record" model where managers write down their expectations for the outcomes from a strategy or course of action and their reasons why. They are collected and reviewed after an appropriate interval (e.g. 6-12 months for many major decisions.) When confronted with your own prior expectations and reasoning you learn a lot faster.

  4. love your openness at IMVU. have you heard of semco? they've implemented even more radical transparency (along w/ decentralization and accountability measures):

    keep sharing the great insights!

  5. In response to Sean - Intel still runs a very formal process of setting expectations, evaluating employees and reviewing progress on a quarterly basis. Most departments do this to track progress on specific work items and project deliverables for each employee. Our own performance review contains strengths and development areas -- in which they are careful to point out development areas and not necessarily weaknesses. We, Intel, are far from being transparent when it comes to other's pay and performance, but our managers are very hands-off, non micro management, and try to set an expectation that you own a particular domain (set of related applications & servers such as data warehouse) and are encouraged to spread into other domains.

  6. I found this post intriguing, and it will make me think differently about how I allocate responsibilities going forward. It seems like this strategy would only work if all of your employees are superstars, and thinkers as well as doers. It seems like when you commit to a free-form culture like the one you outline, you also need to simultaneously commit to a higher standard of who you hire and keep on staff.

  7. Great post! Just beginning to build a team and this perspective is extremely helpful.

  8. Eric,

    Right on - as usual - a lot of what Honda does (from an older News.YC post) is very similar, I think the key is to hire smart people first, though.


  9. Interesting point of view, I'm sure it will cut through a lot of cubicle ducking, finger pointing, red tape.

    A question for you: do you think this radical transparency can be stretched further to apply to your customers and general public as well?

  10. @gerdien - the simple answer is yes, although I caution that radical transparency is not a goal in and of itself. It's a tool that can be used in the service of improved strategy-formation and execution.

    For example, in the early days of IMVU we basically published our whole plan, development methodology, and strategy to our customers and the general public. You can still see these early manifestos thanks to the wayback machine:



    We did that not just out of principle but because it served a very specific purpose: giving early adopters in our community a reason to invest in our success and give us strong feedback. It worked incredibly well for us. Your mileage may vary.

  11. Are you hiring sysadmins?

    Andy: It's not so much the need for superstars... In an environment like that, people would rise up. So much of the time, people just feel trapped... If they touch someone else's silo, they're smacked down like a child, so they stop reaching. This is the ultimate 'anti-silo' method... when transparency is expected and encouraged, you CAN'T have a silo... the first time you're called out and can't defend your assertions, you're silo is breached.

    Also, I gotta add... 'commit[ting] to a higher standard of who you hire and keep...' should this be ALWAYS the case? The last thing you want is for a bright engineer of any experience level to disappear... it'll just lead to worse brain drain later.


  12. This is great - unfortunately, it's not so easy to get all the employees on the same page.

    "And if you're giving them all of the information they need to understand the company's strategy, customers, and processes you can be confident that they'll be able to apply that understanding to their current responsibilities."

    Good knowledge workers will question this, too. How do you get everyone on the same page? I rarely see everyone come to same conclusion.

  13. This all sounds fabulous on paper. Can anyone point to real life examples where these ideas have been put to work? Or at least have someone from IMVUE post a comment here explaining how this works on a day to day basis. With due respect to the author’s obvious smarts, these ideas are too logical to be new. My experience tells me that the day to day realities of team management and organization size work against these ideals.
    Utopian theoretics make great blogs but not great managers.

  14. @Clement - your comment made me sad. I think you are reading much too much utopian zeal into my post. I posted this suggestion, because it's worked for me. I was trying to build an organization with a culture of learning. Other organizations have other goals.

    I hope I'm reading too much cynicism into your comment. But in case your question is sincere, several IMVU'ers who used to work for me are active bloggers. Maybe their experience will surprise you.

    Here are five:


  15. The core ideas seems almost self-evident, those being:

    "every employee is 100% responsible for how they spend their time."

    and that within a company this is manifested as:

    "in any situation it is your responsibility, using your best judgement, to do what you think is in the best interests of the company."

    If people have better information, and better training, and good experiences then they will, I believe, make better choices.

    One area of team effectiveness that the posting doesn't delve into is how the idea of responsibility for oneself relates to the relationships one has with ones' teammates: Being 100% responsible for the choices we make within a team environment places a lot of emphasis on considering how our choices effect other people.

    The essence of effective teams is effective collaboration, and collaboration requires, in my view, 4 things: communication, trust, safety, and shared goals.

    When we consider what we "...think is in the best interests of the company" that must include considering what both what we know about the other people in the company, their plans and activities, and also we muct consider that our knowledge is limited - our "situational awareness" is always less than 100%, so we should must work to maintain nessecary levels of trust and safety in our relationships with teammates, so that we may all move forward effectively towards our common golas.

    A specific example of what I'm talking about might be this: Suppose a team has decided to implement some new product or system, and during development one team member sees an opportunity to increase the efficiency of development on one aspect of the product (the one they are working on) with some changes that necessitate changes in how other parts are built. When this team member thinks about what is in the best interests of the company they should consider not only how the change will make themselves more efficient they should also consider the impact of the change on everyone else in the team.

    Evaluating impact on other people almost certainly means communications and discussion with other team members, either directly or through representatives, perhaps there are people within the company who specialize in facilitating this sort fo communications or perhaps the number of people involved is small enough to make direct communication reasonably efficient. Either way, good decisions require that team members take one another into account when making decisions.

    Beyond the impact of decisons on other team members there is of course the impat of decisions on customers, and in most companies the number of customers far exceeds the number of team members within the company, so evaluating impact on customers requires especially efficient forms of communication, and there are many people who spend their whole careers specializing in this area. In a small startup this may be the founder, or this may be less of an issue because the custmer base is much smaller than it will be by the time the compay is profitable, but eventually the task of evaluating the impact of choices on customers needs to be addressed as a critcial area of expertise within the company, and any team member making choices about how they spend their time should avail themselves of that expertise.

  16. Eric – Please forgive me for hurting your feelings. I absolutely love your blog and have a high degree of respect for your ideals.

    I have a genuine interest in learning more about your management style and recommendations and how they apply them to the real world. Most of the entries on your blog are very practical with obvious real life examples on how they have worked for you or others. The list of IMVUE employee blogs your recommended clearly detail how this team of obviously smart people are living your culture of iteration and continuous improvement.

    What their blogs lack entirely is any concrete reference to the style of management you described on this post. When you asked me to review their blogs I was honestly expecting to read about home much they loved the IMVUE culture because they felt super empowered, knew exactly the direction the company is going and had complete freedom to do what they felt was right for the business.

    In one of the blogs you recommended the author talks about balancing his time between “company” projects and side projects. I would expect that if the management tactics you recommend above were really working there would be no need for “side” projects, it should all be part of what is best for the business.

    Eric – I truly, sincerely, want to believe these ideas work, but if I am to follow your advice I have to ask for the metrics (or any evidence) that it works.

  17. Clement, not to worry. My feelings are not hurt.

    I continue to believe you're reading more claims into my post then I have made. I do not believe the purpose of this policy is to increase productivity, deprive employees of having a life (I encourage side projects), or even to have them "love the culture." The goal is simply to establish a culture of learning. That is often not fun, actually. Who wants to be constantly reminded that they are wrong?

    The only evidence that counts is: does the company have a culture of learning? You'll have to judge for yourself whether the company or its employees seem to exhibit that trait. And in order to find out if that is due to this specific recommendation, you'll have to try it yourself.

  18. Hi Eric,

    that's what I think for myself, for a long time now. But it does not work out 100% of the time. For example, I have a programmer in my team. He is a brilliant man, coding very fast something that is a little better as everybody expected. But I never ever could persuade him to write just one fraggin single unit tests.

    So, if you think about it. Unittests are vital to a startup. How can you have faster loops, how can you react to failures without having a single unit test? I don't know how to handle such a situation. I can't even fire that guy. He takes no money and if he's gone there is just a clean chair.

    What would you do in this situation? Let him not writing tests? That's what I did until today...

    Erik (with 'k' ;])

  19. Wonderful explanation of how to implement this concept effectively. The military teaches a similar concept from day one, but approaches it slightly differently, something along the lines of, "If one of us fails, we ALL fail."

    Teamwork and a vested interest in success of the whole group is crucial. Of course your risk is a bad apple causing strife (don't want a "Code Red"); but as you stated, proper hiring will mitigate this risk.