{squeaky lean}

Beat the competition. Be a slave to your development team.

In a company that has managers responsible for the success of a product, and developers who produce that product, the company's hierarchy normally places the managers 'above' the developers.

'Above' implies that it is the managers who request things of the development team, and the development team who respond on demand. Not the other way around.

And that, in the main, is how things are.

Thing is, it is this situation that damages the quality of a product and reduces the speed at which it gets to market. 

To fix this, once a manager has handed a project over to the development team, he or she should be answerable to that team, on demand, until the completion of the project. They should expect to be interrogated as and when the team require answers, and should be quick with decisions as and when the team need direction.

Why? Well, a few reasons, but the one I want to talk about here is context switching.

What is Context Switching?
Imagine your mother has asked you to bake a chocolate cake for a party this evening. You've not baked a cake before, but you're pretty excited about it.

  1. You get started, and soon realise you don't know which type of flour to use. You call your mother. She's playing poker and says she'll call back in an hour.
  2. You mow the lawn in the meantime. CONTEXT SWITCH No 1
  3. An hour later, your mother calls and tells you about the flour. Great, back to the cake. CONTEXT SWITCH No 2
  4. You spend 15 minutes going back over what you'd done so far to get yourself back up to speed. Baking and gardening require different mindsets after all.
  5. 15 minutes later you're wondering if it's ok just to use the chocolate egg you got for Easter.
  6. You call your mother again.
  7. She's spending her poker winnings on a spa treatment and can't be disturbed for the afternoon.
  8. You sigh, and decide to go and varnish the garden fence. Not as pressing a task as the cake, but it needs doing, so why not. CONTEXT SWITCH No 3
  9. At about 5pm your mother calls back.
  10. She says you need to get special cooking chocolate.
  11. You violently smash up the Easter chocolate with a rolling-pin. CONTEXT SWITCH No 4
  12. You trudge to the shop and come back with the chocolate. CONTEXT SWITCH No 5
  13. You read the recipe and retrace your steps for a third time. CONTEXT SWITCH No 6
  14. Your excitement about the whole cake thing has diminished substantially and suddenly you're not interested in how it will taste anymore, just about getting it done.
  15. Later that evening as people eat dry chocolate cake, your mother tells you you shouldn't have cooked it so long.
  16. You love your mother, but you spike her coffee with laxatives all the same. CONTEXT SWITCH No 7

What went wrong?

The cake went off track because when you needed more information, your mother wasn't available to provide it, so you had to stop working on it.

Your only choice was to switch to a different task and a different context.

Different contexts require different mindsets, knowledge and skill sets. Putting one set away, taking out another and getting the hang of it again can be exhausting and confusing if you have to keep doing it.

Context switching like this also makes it very difficult to keep tuned-in enough to spot mistakes, or to find those extra improvements that make a product great.

Is overall productivity effected?

Yes, because the context switching itself takes time. People don't move seamlessly from one to the other without losing momentum. Losing momentum by switching often can slow down projects drastically.

So what would have made the cake better?

Your mother answering your questions the moment you needed them answering. That way you could have just got on with it, keeping your momentum along with your excitement and pride in the quality of the cake.

Stop beating yourself up. The bad cake was her fault.

Anyway… back to business now please?

Yeah, sorry. Enough about cake.

As I've said, when 'management' hand the development team a project, they should then be answerable to the development team until the project is finished.

They need to be available to answer questions and to make decisions. Not at the next meeting, but as and when questions need answering and decisions need making.

But 'management' have things to do as well. Aren't you just passing the context switching problem to them?

Yep. And that's how it should be.

What?! Why?!

Because protecting those who produce your product from context switching, by swallowing it yourself, is what good managers do. It's what good management IS.

Good managers tell their team that they can call them or go see them when they need to. If you don't have time for these calls or visits then either:

  • Delegate this authority to someone who will, and forego the right to complain about the end product
  • Acknowledge that if the project isn't important enough for you to make the time, then the team shouldn't be working on it in the first place
  • Make time

Like this?


By Kevin Heery.

Google

Trust vs Control – Why big companies are slower than startups

Big companies, when they started out, consisted of a few people who:

1. Were extremely excited about the vision of the company

2. Were considered by each other as the perfect people for the jobs they were tasked with

3. Cared very much about whether or not the company succeeded

Because of these 3 key facts, they all trusted each other implicitly. And because of this trust, no-one considered putting in processes and controls to make sure they behaved themselves properly. They didn't need them. As far as they were concerned, there was no risk.

The company grew fast. People were hired quickly. And as time went on, the odd mistake was made. None were devastating, but some were bad enough to make someone introduce a process to ensure no-one made the same mistake again.

The bigger the company got, the more there was to lose, and the more processes were introduced to protect itself from that one mistake that might end in disaster.

Protection became more important than innovation.

Control replaced trust.

And there you have it. The velocity of the company in relation to the size of its workforce, had begun its inevitable and never-ending decline.

Why would this slow companies down?

  1. Each new process or control amounts to extra work for a company's staff
  2. This extra work doesn't create ANY incremental value for the company
  3. Even though this extra work is intended to limit mistakes by a company's LESS trustworthy or LESS talented people
  4. It's in fact its MOST trustworthy and MOST talented people who are most affected. It's them who will push on through these controls, when others might give up. So it's them whose time is being used up most by risk reduction rather than value contribution

Now imagine if one of these companies decided only to hire people who fit the 3 criteria at the top of this post. In theory they would decide to add far fewer controls and their velocity per person would not decline.

The speed of a company like this, once it had become large, an enterprise, would be astonishing.

'But what you're suggesting simply isn't realistic! It would take forever to fill vacancies and they'd grow too slowly. And they'd have to pay everyone a fortune!'

Perhaps. But, if you want to be leaner, or if you are a lean team within a big organisation and want to stay that way, then I suggest a different mindset for hiring new staff.

How to recruit so you don't slow down

When you're hiring, the first conversation you should have with any candidate is about your Vision and Values.

Watch and listen closely as you discuss them. By the end of the conversation, can you tell if that person could be put in a room with some strangers, talking them through why your vision is so smart, answering any awkward questions about it eloquently, because they genuinely get it, and believe in it? If so, regardless of whether they have the specific skills for the job you're hiring for or not, you might want to consider hiring them.

If they DO have the skills for the job, hire them immediately.

You can be confident that they will deliver at least 2x the value of someone with similar skills who doesn't have an appreciation of WHY you are asking them to do the work they are doing. If they don't know WHY, and especially if they don't mind not knowing WHY, then I promise you'll be looking at their work in future and wondering WHY on earth they think you should be impressed with it.

Someone who does know WHY, who cares WHY, who can't stand working on something without knowing WHY, someone like that will have a constant conversation with themselves as they work, about wether or not their work will deliver what it truly needs to deliver.

They will end up knowing more about the effect of their work than you do, and they will suggest better ways of delivering the objective that their work is aimed at delivering.

They will end up being critical to your business, so you should pay them well. Not market rate. Top rate.

If, however, you decide you only need 10% of your workforce to display this behaviour, then you will be forced to have them manage the other 90%, just to make the 90% deliver something average.

So now your superstar 10% aren't delivering brilliant stuff any more, they're working too hard turning poor stuff into average stuff. Happy with yourself?

You can even help yourself decide which candidates are worth talking to in the first place by following Nir Eyal's advice and abolishing the usual reference check. Replace it instead with a carefully worded email, that tells referees to reply only if they consider the candidate:

'to be an exceptional employee, in the top 10% of the people you’ve worked with'

..and that..

'if you found their work to be less than exceptional, go ahead and disregard this message and have a great day'.

Nir calls this his "average-need-not-apply method"

And if you think this can only work for startups then read this (pretty long, but worth it) Netflix presentation titled 'Freedom and Responsibility', and you'll see that it seems to be working pretty well for them too.

Essentially, you need the majority of your workforce to display the right values. Companies that follow this path are able to trust their workforce enough not to have to control them and slow them down with extra process. They therefore move quickly towards their vision.

True, they look smug, but forgive them. They can't help it.

Like this?

OR

By Kevin Heery.

Google