Friday, 28 February 2014

Friday Feeding Vol 1.

Each Friday I will post an article highlighting the 5 best posts that I've read over the week that I'd like to share. 

Here's Volume 1...

Steve Blank @sgblank
- Steve explains the model he uses to explain the 9 phases a startup goes through from idea to being ready for investment

Guy Turner via Red Rocket Ventures Blog @guyhturner
- Great article with a simple framework that can be used to evaluate whether a startup business model is likely to work, particularly useful for considering sales channel versus pricing strategy

Nic Brisbourne at Forward Partners @brisbourne
- The exit of the year so far and one great photo sums it up

First Round Review @firstround
- tips from Oren Jacob, ex-Pixar and co-founder of ToyTalk highlights some great storytelling tips which if used well by entrepreneurs can really help a pitch come alive

John Maeda via KPCB @johnmaeda
- Product and design are increasingly core to success and will be the key comptetency that matters.  Thinking of design in a holistic way matters.  In terms of practically what that means, John suggests 3 great principles to bear in mind






Thursday, 27 February 2014

Running With Slack vs. Running Overheated

Arrivals board, Heathrow T5, April 16 2010

Would you run a train network at 100% capacity all the time? No - I don't think you would. There's no slack. If one problem occurs then there's no room to manoeuvre. There'd be a crisis, a meltdown.

In fact - that's one of the problems with London Heathrow airport. It runs at 98% capacity. When bad weather hits, big delays ramp up quickly unless some scheduled flights are cancelled. 

So, it stands to reason that as managers we shouldn't try and run our people at 100%. If we do, a crisis will easily happen. We'll then be firefighting instead of growing. 

Or - maybe not. The counter view is this: if we are running at less than 100%, we are doing everything with time to spare. Some of that work is less important than the rest. If we say no to things, let's say no to the least important things. If you're saying yes to everything you're not prioritising

One way to navigate this dilemma is to make a distinction as follows...

Does all the work have to happen within a fixed time frame. Or not?

Predicable fixed tasks with defined time frames - these are best run with some slack capacity to allow for unforeseen circumstances.  

Transport and logistics would fit this model. Or fixed deadline civil engineering projects. 

Unpredictable tasks with non-defined time frames - these are best queued in order of priority. They can then be worked through at 100% capacity taking a new task from the top of the list as soon as another is completed. If there's a problem, simply pause until the problem is dealt with and then get back to the high priority work. 

Software development and creative work might fit better with this model. 

Of course, there's no right and wrong here. I'm just highlighting that there are benefits to running with slack and benefits of running with no slack. 

Ultimately it boils down to a simple question, "what would happen if we can't complete this by a certain time".

As a startup you're usually running at way above capacity simply because the answer to that question is the amount of cash you have left.  At some point however  you might need to design slack in your system to avoid a crisis.


Wednesday, 26 February 2014

The Dancing Guy

When I think of inspiring people in business, there is one name that keeps coming back to me. It's not Branson or Zuckerberg or Jobs (not that they aren't impressive or inspirational).

It's Derek Sivers. 

Derek was the founder of CD Baby a startup that solved the problem of publishing and distributing music for independent artists. 

There's many things that inspire me about Derek. Above all he shows a great deal of compassion and humanity. He's tenacious and humble. He applies himself. 

He has a knack for writing and has an excellent blog at Sivers.org

I'd recommend anyone thinking of starting a business, anyone working in a startup or anyone managing a team to read his book, Anything You Want.  It's a simple set of lessons learned in startup life. You could read it in a couple of hours. 

If you just have two minutes to spare, there's a memorable video he did called "Dancing Guy".  It won him a standing ovation at a TED conference in 2010. It's stuck in my memory ever since. 

One of the most inspirational and wise videos on the subject of leadership I've ever seen. Fun. Humbling. 

Here it is..enjoy!

Tuesday, 25 February 2014

Traits That I Admire in an Entrepreneur

I've met many entrepreneurs and founders and wannabe founders over the years.  Some were convincing, some were not.  Some of the convincing ones persuaded me to work for them.  Taking the best of what I've seen so far, what are the traits that I admire in an entrepreneur?
  • They really understand the problem they are trying to solve
  • They have a strong vision of what the future will look like once they've solved the problem
  • Others follow them because they are inspired by the vision
  • They are humble enough to ask for advice and realise when they need help
  • They build a team where each individual plays to their strengths
  • They are frugal with money but generous in spirit
  • They systematically want to test every part of their business model and will change course based on feedback
  • They know their numbers; daily, weekly, monthly, quarterly, annually
  • They have relentless energy and tenacity
  • They speak with their customers directly
  • They are open and approachable
  • Their word is worth something and they follow through on their promises
  • They can be trusted
  • They can tell a great story
  • They find it difficult to comprimise on quality
  • They can react quickly, decisively; yet manage to make time to reflect and plan ahead
  • They are positive and enthusiastic
To find such a person is rare but when such a person comes into your life, the rewards of supporting them with your time, money, help or attention are exponential.

Monday, 24 February 2014

Why I became a VC

Today I am proud to join Forward Partners as a VC.  Having worked in VC backed growth businesses for many years, I'm now changing seats and changing gear, looking forward to helping the best UK entrepreneurs succeed.

Why I have taken on this challenge now, at this moment in time, really boils down to 3 reasons;
  1. The VC model is changing and I believe that the approach that we are taking at Forward Partners will become the future of early stage tech investment.  I am truly excited about being instrumental in defining that model.
  2. I have real practical experience having worked in multiple high growth international startups and I hope to provide sound advice that will really help entrepreneurs succeed.
  3. We are in the midst of the greatest disruption to civilisation since the industrial revolution; we're living through the 21st century gold rush and there's never been a better time to start a tech business.

In some ways, today reminds me of some advice given to me back in 1986. 

Mr Jackson stood in front of our 6th form class. "Many of you in this room in 20 years time will be in business and you'll be managers. You will be in charge of other people, many of whom will have not have the same opportunities in life that you have had. If you are to do your job well and be successful you will need your team to be on your side. You will need to understand the world from their point of view".  As we were about to head off to University he advised us to think about using this opportunity to live in the inner city, to get a part time job to pay our way and mix with the real world. "In 20 years time you will thank me for the advice, I promise".

I took his advice. I went to Manchester. I lived in a house next door to a B&B for ex-cons. I worked nights in canteens, waited tables with old Irish ladies from Moss Side. I worked in an Oxfam shop one afternoon each week. I constantly worried about money. I studied, graduated.

Living in the inner city of Manchester gave me the experience to draw on as a manager later in life.

I'm reminded of this because I now find myself in a position to help entrepreneurs having worked in startups myself.  I can draw on this experience because I know the stresses and strains of startup life.  I know what it takes to bring order to chaos and to scale a company.  I know how expensive it is to prematurely scale.  I've tested pricing models and conversion rates. I've hired and built great teams.  These are the details that are needed to turn vision into reality.

I've worked in digital businesses since 2000 as Product Manager, ECommerce Operations Director and most recently as Chief Operating Officer (3 companies). In the early days I had to apply myself to learn HTML and CSS (I built a hobby website), set up Adwords campaigns, learn SEO tactics and so on. Most of the technology we now have in the digital space wasn't here 15 years ago. (Nor does most of the technology of the future already exist).  I've worked as a COO in some fantastic high growth companies over the last 7 years. There's no textbook for that. I learnt a lot by simply getting hands on and trying things out.  I'm a great believer in the rewards of evolutionary methods. Take ingredients that exist, reform into new variants, test and measure what works. Keep and do more of what works, discard what doesn't.  

2014. Forward Partners, London. Here I now find myself looking forward to a great opportunity to work with and support some of the very best entrepreneurs in the UK. 

At Forward Partners we look to invest in early stage tech businesses. We don't simply provide the money. We can provide support, resources and knowledge. We maximise the chance that an entrepreneur will capture their opportunity. 

I've been lucky to work for and with successful entrepreneurs. I now know two important facts;
  • an entrepreneur needs a compelling vision of the future to disrupt the present
  • the path to that future is riddled with uncertainty 
At Forward Partners we help entrepreneurs systematically uncover assumptions in their business model and find ways to test those assumptions. By doing so early and by using our expert team of designers, product managers, developers and marketers they can refine their business model without needing to hire full time staff or find their own office space. 

This massively improves the odds of the vision becoming reality. 

With the use of our lean start up methodologies and design thinking an entrepreneur can increase their chances of success at a lower cost and arrive at a viable business model sooner. 

Equally, I am looking forward to learning from some of the most innovative and brightest entrepreneurial minds in the country, to continue learning and absorbing new methods and ideas.

When the time comes to grow the company, having people around that have done it before to be on hand to advise and help once again improves the odds of success.  I have real and deep experience in building and executing plans and this is where I can be useful. 

The VC model is changing. There have been a few VCs that I've worked with that have management experience in internet businesses. However they are the exception. Many VCs know only of their startups through board meetings and conversations with CEOs and their senior teams. They are not involved in the nitty gritty of getting stuff done.  The next generation of successful VC firms will combine robust investment experience with practical operational experience.

I'm not sure who said it, but it's a favourite maxim of mine, "Vision without execution is hallucination".  If VCs can help entrepreneurs with execution (and I mean really help, not just the odd intro to another portfolio company or refining pitch decks for the next round) and we can do it early in the life stage of the company, we can become real springboards for success. There are few VC firms in the US taking this approach and at Forward Partners we intend to lead with this approach in the UK and reinvent venture capital. 

Finally, there's been no better time to build a tech business. Now is an amazing time in human history. We are in the midst of a technological revolution. 

In the last 15 years, the cost of production has gone down, distribution has gone mainstream.  This means that entrepreneurs can very quickly and easily validate business models using lean startup methodologies.  Knowledge gained 15 years ago that would have cost millions, now costs tens of thousands.

What can go digital will go digital.  There are thousands of businesses waiting to be born to exploit and succeed in the new competitive landscape.

In this new world, startups that learn early by rigorously testing assumptions in their business model can succeed with relatively small capital outlay.   When capital is then later invested in earnest, it is for growth and exploitation of a proven model.  

Forward Partners is at the heart of this new approach and I am excited to be part of the team.

Friday, 14 February 2014

Policies and Procedures 5 of 5: TEMPLATE

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

[04.03.14 - After I published this blog I had positive feedback. COO Danny Mash recommended that I add a point 6.... “ Assembling, indexing, referencing and evolving the P&P binder”.  I agree.  Whether it's physical or digital, a definitive checklist of all P&P's in circulation is a useful help]


This post shows a TEMPLATE that you can use for a policy and procedure


Policy and Procedure Template 

[Process / policy name here]



Process authored by:     [Name]

Last updated:                   [Date]

Version:                             [Number]





Introduction



In this section explain

1 – why this policy / process is needed

2 – explain the context, background information so that a new team member can understand the detail



Terminology



Describe any relevant terminology / vocabulary or abbreviations



Policies



State any policies relevant to this process.  These are company decisions which shape the policy





Process



Describe the process, step by step in numbered points



Measures



State any measures or reporting that is done (by whom and when) to ensure that this policy and procedure is being followed

Thursday, 13 February 2014

Policies and Procedures 4 of 5: HOW

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 HOW to document a policy and procedure...

Whenever I document a policy and procedure I tend to 
- put them in one document together
- use words to clearly explain everything 
- use numbered points for structure
- use diagrams if need be
- publish the document on "the path most travelled" so that is is easily accessible by all team members (e.g. Intranet, CRM system, Yammer, email, notice boards). Wherever it will get seen. 

In terms of structure there are 5 main sections;
  1. Explain the context
  2. Define vocabulary and jargon 
  3. State the policies
  4. Describe the procedure
  5. State how compliance will be measured

A few details on each of the above...

1. Explain the context

Why is this policy and procedure important? What benefit is there (to the team, to customers, to suppliers, to the company) if this policy is followed? To whom does it apply? Who is responsible for making us sure it us followed? 

2. Define vocabulary and jargon 

If there any words in here your Mum wouldn't understand, define them. If the are any abbreviations, define them. A complete newcomer to the company should be able to understand thus document. 

3. State the policies

Try keep it simple. What are the main policies. Put them in bullet points. 

4. Describe the procedure

Step by step describe the procedure. Explain who does each part of the process. Explain how to use the relevant systems. If the supervisor were unable to show the team how to do their job, they should be able to follow these instructions. 

5. State how compliance will be measured

If you can, find relevant metrics to measure whether it not this policy is being adhered to. Measure. Share. Improve. 

Every policy will need reviewing on a regular basis to improve and keep up to date. 

Tip: if you can publish your policies as a "live" document such as a web page, it's much easier to ensure everyone has access to the latest version of the policy at the click of a mouse. So much easier than emailing out attachments. 

Next: TEMPLATE for a policy and procedure (coming 15.02.14). 

Wednesday, 12 February 2014

Policies and Procedures 3 of 5: WHEN and WHO

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 WHEN and WHO should document a policy and procedure...

I'm coming at this topic from the perspective of high growth tech startups as that's my background. 

A startup let's remember is an organisation whose purpose is to uncover a viable and repeatable business model. Once a viable and repeatable and business model is understood and proven the task is to exploit that opportunity and become profitable. 

In this context a team may grow from the founding team to 10 people to 30 people to 100 people to 200 people very quickly. 

In the earliest stage of a startup, policies can be controlled by direct real time decisions by the founders. Procedures are not yet known as the business model is in flux and the whole team is in experimental mode. 

There's little point in creating a body of policy or procedure until..
i) the business model is understood
ii) the team is growing and more than 2 people are doing any one job
iii) processes and methods start to become stable and repeated 

The WHEN dimension therefore coincides with the point at which the company starts to scale. That's what makes it challenging. Studying the policies and procedures at the same as growing a team is a demanding task.  There's enough to do (interviews, training staff, setting up office space and tools) without having to worry about writing down policies and procedures. There comes a point at which the payback in the medium term is worth the sacrifice in the short term. The task of a COO is to judge that moment and prioritise creation of policies and procedures appropriate to the stage of the company. 

Not everything needs doing at once. There are customers to serve and revenue to generate. Inevitably some policies and procedures are more important than others. There's no formula for that, only good judgement. 

WHO should write the policies and procedures?

This will depend on the organisation of course. The way I think about it, the person accountable for the quality of the work should draft the policies and then delegate the drafting of the procedures to the person responsible for the team carrying out the majority of the activity. 

(For more details on the difference between accountable and responsible see this post. In short, accountable = "the buck stops here" and responsible = "the do-er"). 

By asking the person responsible to write up the procedure it achieves 3 things;
1. That gaps of knowledge are uncovered and details are added 
2. That the person writing the procedure will more likely adhere to it
3. That the person writing the procedure will more likely make others adhere to it

The accountable person needs to read, question, review simplify and/or elaborate upon the draft and approve it for publishing. 

Both people need to then create a plan to instill the policy and procedure within the team with education, training and controls. 

In the example of a customer care team, the customer care manager (responsible) might draft the procedures based on policies provided by the COO (accountable). 


Tuesday, 11 February 2014

Policies and Procedures 2 of 5: WHY

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 WHY should you document a policy and procedure...

There's a few good reasons. 

1. The obvious reason: so that people have instructions to follow. It's a good reason and certainly makes a lot of sense to document instructions, especially when you have lots of different people involved in making something happen - or when you have lots of people doing the same job and you are looking for consistency. However, just because you wrote it all down doesn't mean people will follow the policy. 

2. The less obvious reason: by writing everything down it becomes clearer what the procedures are, any uncertainties are uncovered and discussed. The act of writing is an act of clarification. You may think you understand everything but until you've written down all the details you won't know for sure. Writing uncovers gaps. 

3. The unspoken reason: to cover your arse. Sometimes a company will publish policies and procedures to show they are compliant with legislation. By asking staff to sign a declaration that they are gong to adhere to published policies and procedures, the liability of the company might be reduced in the event of a rogue employee defying the policy. In this case it was the employees fault m'lud, not us. Don't fine us. We're the good guys. A lot of HR policies seem to have this concern underpinning them. 

4. The most important reason: to improve the process. This for me is the key reason. By writing something down you can start to measure it, observe it and improve it. In fact, I'd go so far as to say that it is a failure if policies and procedures do not change. They must change, especially the procedures. A set of procedures that have not changed for years mean only 2 things; either i) that they are perfect and therefore require no changes or ii) that they are imperfect and there is a failure to improve them. I generally have a disbelief in the existence of perfection because the environment in which we exist is continually changing. Perfect would mean a constantly adaptive and predictive system. A written set of policies and procedures can be measured, understood, improved and changed. Unwritten ones cannot. 

Monday, 10 February 2014

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)




Friday, 7 February 2014

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. 




Thursday, 6 February 2014

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.

Wednesday, 5 February 2014

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.

Tuesday, 4 February 2014

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.

Monday, 3 February 2014

Why a Facebook Like Has Very Little Effect

Facebook recently made an earnings announcement showing that they are making significant progress in generating revenue.  As reported here by Forbes, Facebook said fourth-quarter net earnings jumped more than eightfold from a year ago, to $523 million, and importantly mobile ad revenues constituted 53% of overall ad sales.  An impressive set of numbers.

I find it unusual now to find a brand without a Facebook page.

The discipline of social media marketing is still underdeveloped however, partly due to the fact that the success metrics are not clear and as obvious.  What makes a success?  Someone seeing a post, reading it, liking it, sharing it?  What ROI are advertisers looking for when they run a Facebook campaign?

In an interesting article just published entitled, "Brand Comparison Study: What's Really Happening on Facebook?", Thomas Baekdal looked into the engagement patterns of 8 brands over the past two years to try and unpick what trends if any could be found.

It really is a fascinating article, albeit someone inconclusive.  I'd recommend any digital marketing specialist to read it as it will probably challenge many assumptions.

One key takeaway is that the more brands and publishers use Facebook, the more people like each brand, the less chance there is of any given brand getting a share of visibility.  It becomes more difficult to get the attention of users the more users there are and the more brands there are.

The graphs below show views per unique dropping over two years.

Analysis by Thomas Baekdal

And - remarkably (well done Facebook) - page likes per unique reach are up during the same period.

Baekdal goes on to go into some detail and helps us to realise that a "like" is not enough.  What really matters in social media marketing is if people talk about your brand in a positive way, for example, recommending your products or talking about their experience with their friends.

He says, "You need to get people to talk about you, because just liking your posts on Facebook has very little effect."

Those "likes" are just the tip of the iceberg and actually don't mean that much. They might make you feel good and make your corporate ego shine.  Just like in the real world, what matters is not how many people know you or say they like you but how many say good things about you behind your back.

That's tricky to measure and it's why social media marketing measurement has some way to go.