Policies and Procedures 1 of 5; WHAT

In this mini-series on policies and procedures I am covering;

1. WHAT is a policy and procedure
2. WHY should you document a policy and procedure
3. WHEN and WHO should document a policy and procedure
4. HOW to document a policy and procedure
5. TEMPLATE for a policy and procedure

This post is on WHAT is a policy and procedure...

I thought I'd share some basic practical tips on Operations Management that I've learnt.  None of what I will describing is from a textbook.  It's all from real life experience from more than 20 years of testing things out in the real world.

A policy and procedure is a basic building block of the operation manager's toolkit.

A POLICY is a series of decisions made by the company about how they intend to handle certain situations.  It's a decision made by and endorsed by the managers of the company and you can think of policies as being like principles upon which actions are taken.

Examples;
- We will always attempt to acknowledge a customer complaint within 24 hours of receipt
- We will match any competitor price for the same goods if we receive notice within 2 weeks of purchase
- We will / will not cover shipping costs for returns
- We will ensure all new starters have a desk, computer and email account set up prior to their start date

A PROCEDURE (or process) however is a set of repeatable instructions that explain how individuals, teams and systems act out the policy. A procedure will describe step by step what is required in a particular scenario.  It's usually a scenario that repeats itself or that can be predicted.  People carry out tasks by following the procedures.  It usually explains who is responsible at each stage of the process.

Examples;
- How to process a cancellation
- How we recruit people
- How we handle complaints
- What we do when someone leaves the company

To describe a procedure without explaining the policies that underpin it risks that people following the instructions don't appreciate the context in which they are working.  Blindly following instructions means that should the instructions be missing a small point of detail or should the circumstances be so unusual that the instructions are incomplete, the team member would not know how to act.  However, if they can also understand the principles upon which the instructions are based, then they are more able to act in the interests of the company.

So, consider policies as a set of written principles and procedures (or process) as a set of written instructions.

Next: WHY should you document a policy and procedure (coming 11.02.14)

International Growth - 4 Questions To Help Choose Between Buddism or Catholicism

I was having coffee this week with a CEO of a marketplace business and we were discussing the ways in which he could organise his international expansion.

Do you create local teams that are independent, can act fast and adapt well to the local culture etc. Or - do you do as much as possible from HQ and have as few people as possible on the ground locally?

The truth is, there isn't a simple answer to this question.  Either methods can and do work. 

I've had this discussion many times over the years and seen different ways of doing it first hand. 

The way I see it there are a range of functions which are more suited to being centralised and a range which lend themselves to being more localised. 

Finance for example, needs a centralised team. There may be local bookkeepers in each country but usually in finance you'd have as much as possible in one location. Reason; governance and control. 

Same with tech. Having a multitude of tech solutions for similar problems means you end up with a spaghetti like mess of code to unpick down the line. Unless there's a business case to say otherwise, tech, design and product tend to stay centralised. 

Sales, marketing and customer service are the areas which sometimes can be done centrally, sometimes they need a local presence. There's no "right" answer here because it depends entirely on context. 

What I can suggest are 4 questions to ask which might help you decide...

1. Do you need an entrepreneurial mindset to launch in the territory?

If success requires a local entrepreneurial leader to build relationships locally, they will need to be empowered to move fast and independently.  They'll need more sales, marketing and customer service resources that they can call on at will. Shackle their ability to move quickly and they will fail. 

Later, once a local business is up and running you may choose to start standardising things across territories by sharing best practice but to start with it could make sense to just go hard and fast with an entrepreneurial approach and less standardisation. 

2. Do local conditions change the proposition, revenue model or distribution channels used?

If you can use exactly the same methodology in several markets to succeed, much if what is done can be centralised and shared across territories. If it's a very local play with local relationships and local adaptations needed, the set up will be less centralised.

3. Does the business run on policy or principles?

Policy driven companies can be dogmatic and have very specific controlled ways of doing things. Success requires rolling out a template systematically to create a predictable experience for suppliers and customers. (e.g. a hotel booking website)

Other companies can achieve the same results by basing their decisions around a  set of guiding principles and giving more autonomy to a local team. (e.g. a recruitment agency). 

The difference between these two approaches can be thought of as a "Catholic" versus "Buddist" approach. Great examples can be found in the recently published "Scaling Up Excellence - Getting to More Without Settling For Less" by Robert Sutton and Stanford colleague Huggy Rao.

4. What are the risks of giving up central control?

If a business has developed strategies to reduce risk (e.g. Health and safety risks reduced through certain processes or controls), to allow a local method to manage these risks may not make sense

Finally...

These 4 questions might be a good place to start. 

Ultimately, it requires a real life test to decide. If market development approach proves successful and can be replicated time and time again, that's worth something. 

As always, test, iterate, amplify or discard. 

MVP Feedback Tactics

In lean product development, there's the concept of a Minimum Viable Product, aka the MVP. 

(A MVP is intended to prove (or disprove) assumptions made in a business model. It's a product which aims to solve the core problem with as few features as possible.   Spending time building a product is expensive and in the earliest phases of a startup that expense hurts unless there are paying customers that follow quickly. So, you build a MVP).

But just how can you test out the product and get customer feedback?

What are the feedback loops? 

How can you be scrappy and learn fast with minimal investment?

Here's an excellent article giving a few great examples; "Minimum Viable Feature Analysis" by Alistair Croll (@acroll), co-author of Lean Analytics: Use Data to Build a Better Startup Faster.

In the article, Croll gives us suggested tactics such as

• Survey (just one question though)

• Phone a friend

• Headcams and stop motion cameras

• Watch someone use a competitors app

• Button to nowhere (my favourite)

• Sign Up Form 

• Prototype

• What would Bob do?

• False payment (sneaky, but very smart)

They're all great tactics, they all find ways to validate assumptions before investing too heavily in a finished product.

I've always been a fan of testing something to see if it works, then tweaking based on early feedback.  It's an evolutionary mindset that requires me to apply myself to a problem and learn from experience. This works not only in software development, it works in almost all areas of work.

I never truly understand a problem until I try to solve it.

Between the Variables and Constants, People are the Operations - The Mathematics of Team Performance.

In mathematics, "operations" are things like add, subtract, multiply, divide, squaring, etc. If it isn't a number it is probably an operation.

In business operations however, people are like the mathematical operators.  It's people that add, subtract, divide and multiply.

As any business owner will tell you, dealing with people is difficult to get right.

So - here's a tip for any managers out there.  If each of your team member were an operation (+, _, X, /), which would they be?

+ ADD +
Someone who adds, adds value.  They do their job well, consistently.  You need to reward, motivate and nurture these important team members.

- SUBTRACT -
Someone who subtracts is not providing value.  They do not do their job well (for whatever reason).  You need to address this performance and attempt to turn it around. This may not be possible.  If you fail to turn a subtract into an add, you need to remove this person from the team.

/ DIVIDE /
Someone who divides not only does their job badly but causes others to do their job badly as well.  They suck up your time.  They are a bad influence.  They are poison.  If you have a divider, you need to realise this quickly and remove them fast.  Your team will thank you for this.

x MULTIPLY x
Someone who multiplies not only does their job well but causes others to do a better job as well.  They are a catalyst for success.  Success breeds success and so if you can have more multipliers on your team, subtractors can become adders and adders become better adders.  You need to listen to and empower your multipliers.  You also need to make sure they don't get bored or disillusioned.  They need to believe in your vision and they will amplify that vision for you.  Look after them like the gold that they are.

So, think about your team.

Are you team A?

xxx++++

Or team B?

X++---//

This simple perspective can really help when tough decisions are needed and can help you remember to look after your stars.

Why Growth Companies Struggle With Hierarchy

The way a team works together effectively will change as the number of people in the team increases.

An organisation of 10 people acts very differently to an organisation of 200.

Getting from 10 to 200 can be a difficult journey to manage at the best of times, although in a venture-backed start-up the growth rate is often accelerated artificially such that the number of people joining the company builds the team size quicker than otherwise would be the case.  A company who relies on organic growth will not add people as quickly and the adaptation time is slower.

I've experienced this growth challenge several times.  It's not easy.  Here's why.

I like to use an anthropological analogy to illustrate the point.

A group of 4-10 people will act like a "hunting party".  Together they go out on a hunt with a prey in mind but they are very tactical, communicating in real time as the circumstances dictate.  There may be a leader and the leader emerges as being the person that all the others defer to and they are happy to be the leader.

A group of 10-40 people will act like "family huts".  Imagine that each family has a hut around a central fireplace.  Each family has a leader and these leaders and the elders will sit around the fire to share stories and make plans.  Life is relatively spontaneous.  Everybody knows everybody else, they communicate directly with each other as needed yet they spend more time with their own family than anyone else.

A group of 40-150 people will act as a "small village".  In the village everyone has specific roles and there are people in charge of various things.  Someone might be in charge of security, another in charge of energy, another in charge of the harvest.  Everyone knows everyone else to a degree but things start to get done effectively by using a light hierarchy.  Each function has a leader.  To get that function to operate effectively, you need to get the leader to instruct their team of specialists to do the job required.

A group of 150 people+ is like a "town" and the default organisation is a strict hierarchy.  Large groups like this work through the power of the hierarchy.

(See also "Dunbar's Number, Cross 150 With Caution")

There is a reason why a hierarchy works better when there are more people.

Imagine you have 10 people.  10 people communicate directly with 10 people, verbally, via email, on the phone.  That's 10 x 10 potential lines of communication open at all times.  100 threads.  If there are 50 people and they do the same thing, it's 50 x 50 = 2500 threads. 5 times as many people creates 25 times as much noise.  We can't cope with so much noise.  To organise ourselves we naturally create groups and communicate with the group leader who then coordinates the activity of his or her group.  Less noise.

The type of person that operates effectively in a hunting party may not like town life.  In fact the reason they are a good hunter is because they are not townies.  People have preferred methods of organisation and communication, learnt behaviours and default reactions to situations.

A startup might hire some great people when they are small.  These great people might not like the environment they find themselves in a couple of years later when a new mode of organisation would be more effective.  They still act like it's a hunting party.  Those new hires who are used to living in a village or a town join the company expecting things to work like a village or a town because that's the size of the organisation - but they are confronted by hunters who act in a way that they need to adapt to.

The challenge for growth companies therefore is to adapt and change whilst maintaining effectiveness as well as acquiring and retaining talent.  Simply being aware of what is happening with the group dynamics helps, as does anticipating changes that might be needed as a result of a changing group size.  Communication structures work well if adopted by the majority, that's challenging if there are different expectations within the group.

There's no magic formula, this is human nature we're dealing with.  Awareness is a great first step.