So, we’ve grown from 16 odd to around 45 in the space of 12 to 18 months. In that time we’ve grown with all sorts of people from all sorts of backgrounds. Key lesson as been that e-commerce requires lots of types of people, so you can’t hire like you would for a tech team, just doesn’t work.
Today I posted something on our team site which I’ve been stewing on for a while, thought I’d post it here for others to see and perhaps utilise in their companies.
Key issue is that when you don’t explicitly state things, then people make assumptions. When they make assumptions, then often the way you think things should / would / could be done, are not the same as the assumptions… Be prepared for fuckups to ensue.
So, you have to make things a bit more explicit to make sure that people know where the boundaries are.
And without further ado (some stuff removed to take out competitive intel):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All,
A quick update on what to do and what not to do in situations where decisions need to be made, and where (some) overall responsibility, accountability and decision making lies.
Product imports:
Problem:
Bulk importing often upsets indexing / caching on the servers; communication that it was happening could have solved the issue
Solution:
This is your responsibility if you are doing an update. Let tech & ecomm teams know you are doing an import / export to rest of the team.
Caveat emptor:
Flo is working on solution for this not to be an issue, which will go live with AWS. This may negate the above.
Conversion rates on site:
Problem:
Sometimes we do things which knowingly or unwittingly which affect conversion rates. Case in point is the red box on the product pages over Xmas, which resulted in 50% or more decrease in site conversion rate.
Solution:
Gareth has overall accountability for this. If the conversion rate is materially down ( more than 30% reduction for more than a day ), needs to be raised immediately with Gareth.
If there are material changes in the conversion rate ( more than 30% reduction for more than a day ), we should expect to drop everything to work on analysis and a fix.
On-site changes, features, user experience
Problem:
I want to bring some consistency to the features & UX we release from now on – and will only let new features go live when I am happy with the UX.
Solution:
All website changes to the frontend need to be run through Gareth for foreseeable future.
Posting onto the team site is great for feedback, but does not constitute approval / decision making.
Caveat emptor:
Excludes merchandising tactics like banners & product labels etc.
Site issues, site down, pages not loading
Problem:
We encounter pages which don’t load, sites which are not live, caches which are broken etc etc
Solution:
Flo has overall accountability for this. If this is a significant problem, we should expect to drop everything to work on analysis and a fix. If Flo is in a meeting, then that meeting should be interrupted. If Flo is not available, first port of call is Gareth then Martijn. If it is a weekend, then first person to contact is Gareth to triage severity of the problem. If it needs to be fixed immediately, Gareth will get in touch with Flo. Do not attempt to contact Gareth via anything other than a phone call or txt message. Skype and email are not reliable enough for this.
Bugs / issues / tech problems
Problem:
We encounter problems with BrightPearl, Magento, SagePay, PayPal, etc etc
Solution:
Do not send the problem directly to one of the developers in the tech team. Ever.
First port of call is Anish for triage. If Anish is not available, then Gareth. If Gareth is not available then Flo.
If the problem is threatening our ability to transact, fulfil orders or complete payments to suppliers, then this takes priority. If this is a significant problem, we should expect to drop everything to work on analysis and a fix. If Anish is in a meeting, then that meeting should be interrupted. Do not attempt to contact Anish via anything other than in person, a phone call or txt message. Skype and email are not reliable enough for this.
Traffic
Problem:
We encounter a drop in traffic to the websites, for whatever reason (ads down, ads paused, ad position poor) etc
Solution:
Jacob has overall accountability for this. If this is a significant problem, we should expect to drop everything to work on analysis and a fix. If Jacob is in a meeting, then that meeting should be interrupted. If Jacob is not available, first port of call is Ed then Gareth. If it is a weekend, then first person to contact is Jacob to triage severity of the problem. If it needs to be fixed immediately, Jacob will sort it out, or get in touch with Ed for help. Do not attempt to contact Jacob via anything other than a phone call or txt message. Skype and email are not reliable enough for this.
Deliveries
Problem:
We have a problem with stock deliveries to our warehouse or Colchester. Or we have a problem with stock in warehouses. This materially affects stock availability for our sites, or photography of the products for the sites.
Solution:
Alan has overall accountability for this. If this is a significant problem, we should expect to drop everything to work on analysis and a fix. If Alan is in a meeting, then that meeting should be interrupted. If Alan is not available, first port of call is Tom then Jacob. If it is a weekend, then first person to contact is Alan to triage severity of the problem. If it needs to be fixed immediately, Alan will sort it out, or get in touch with Tom for help. Do not attempt to contact Alan via anything other than a phone call or txt message. Skype and email are not reliable enough for this.
Meeting notes not comprehensive enough
Problem:
We make decisions, make commitments within teams, agree direction or allocation of people, or ask people to do things for us and then we don’t document this. This then runs the risk of things being forgotten, “he said, she said” arguments, running around like headless chickens doing things which are not important, or worst case people not aware of what is going on.
Solution:
All meetings should have: (1) agenda, (2) meeting notes, (3) actions.
All meetings must go into calendar.
Agenda goes into calendar description, or team site before the meeting.
Meeting notes go into the team site; comments go into replies.
Actions go into Asana; comments and collaboration goes into Asana tasks.
Any project changes must go into intranet spec / project page so they are documented as such.
With respect to external people:
All meeting notes via email and then onto the team site as a reference.
Actions into asana as usual.
Saying No! is as important and sometimes more important, as saying Yes!
Problem:
We see something shiny and new. We get excited. We ask people to look into it, we spend a day chasing it, we start getting into email threads about it, we do some work on it, try something new out.
We start going down rabbit holes. We chase too many rabbits. We chase lots of shiny things but we don’t get the important things done.
We end up with lots of rabbits, but nothing else.
Solution:
Do not do anything unless it is in a team project, and associated with a team deliverable. Do not go off piste. Do not add projects to Asana unless you are clear that they are a part of the larger company objectives. Do not assign tasks that send people down rabbit holes.
Gareth has overall accountability for direction, deliverables, deadlines and focus. If you want to change direction, go for a different deliverable, change the deadline, or change focus, it has to be run past Gareth first.
If you do not, you run the risk of losing your job, missing out on a bonus, missing out on a promotion, or worst of all letting your team and the company down. Stay focussed.
If you are not sure of what you should be doing, then the first thing to do is ask, and there is absolutely nothing wrong with that. In fact, asking for help, asking for direction, and getting help with focus is one of the first signs of greatness.
And to be clear (this will be fleshed out more in the coming week), these are the general objectives for 2014:
1. get XXX down to XX% or less
2. get revenue up to £XXm per month
2a. get XXX up and contributing
2b. get XXX contributing more
2c. get SEO and other performance marketing channels contributing XXX% of revenue
3. Add XXXXX as transactional site
3a. Get Wedo brand ready for XXXXXX
4. Add XXXXXX
5. Add XXXXXX channel
Any effort into anything else is superflous. Period.
Some general principles / points:
Learn to think if your time as rocks, pebbles, sand and water. Start with the rocks. If we do not get the rocks done, but we answer lots of emails / do lots of small things / focus on the unimportant work, the rocks will still not get done. Start with the rocks.
Email is asynchronous. Sending an email does not mean you have to get a reply. If you want to speak to someone, speak to them, do not rely on email.
Get into the habit of posting meeting notes during meetings; or directly after meetings
Get into the habit of allocating enough time to work on projects so that they are done to completion. I am guilty of this because I’m chasing 25 things at once, so I’m going to start being more ruthless with my time and focus – so should everyone else.
Get out of the habit of ad-hoc interruptions. This is a great little primer for anyone who thinks that ad-hoc interruptions are OK.
Posting something onto the team site and asking for feedback does not mean it will be done, not that it will be remembered – that is what Asana is for.
Adding someone as a follower to a task does not mean they will do it – you must assign to that person if you want them to do the task.
Get out of the habit of using Skype for conversations; Get into the habit of speaking to people. Use your legs and feet to walk over to people when you’ve agreed to discuss something. Accept that you will have to schedule time with people to have these conversations, because the best time to discuss things is when you’re both ready to discuss and can think clearly. Accept that a quick 5 min conversation is waaaaaaaaaaaay faster than a 30 min Skype conversation which interrupts work flow.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~