The hourly model (or daily rate) is the norm for most companies looking to interact with 3rd party companies. For years, it’s seemed logical for most services that you pay for a certain amount of time from a company, and expect certain outcomes in that time. The hourly model is, however, extremely broken.
Sentiment:
Let’s start with sentiment. An hourly model suggests that a company’s presence is what you’re interested in. It’s no different to the old-time illusion of being in the office later than your boss, to prove that you’re working hard. There’s no mention of what you’re doing during that time – they could have easily been playing Fortnite, but it’s their presence that companies deemed important.
Today, we look at this as completely backwards. People are afforded remote working, flexible hours, unlimited holidays etc. when salaried employees – all with the justification that as long as they get their work done, nobody cares about how long it took, where they were, when it happened, etc.
However, when we work with 3rd parties, this is exactly how we treat the relationship. Sure, we’ll measure outcomes to make sure our goals are met, but we’re still focused on having bums on seats for a certain amount of hours. And that’s the problem with the sentiment behind the hourly model – it says “we don’t care as much about how you’re spending your time – more that you’re here”. And that’s no good.
Falling short:
How many times have you had to have that difficult conversation about hours, whether as the client or the agency?
Starting first with internal conversations in agencies – I’ve been present at places where this has happened:
- “How long do you think this would take to build?” (developer: “25 hours”).
- “That seems like a lot… is there any way we could do it in 20?”
The nature of the conversation is a real problem. “Can you work faster?”. The answer should be “no”, but yet the pressure is felt on a regular basis from “doers” – developers, designers, etc.
Looking at the conversations customers have with agencies – it’s just as poor.
- “We want to do this really cool project – how long will it take?”
- “We’ve estimated 100 hours”.
- “Hmmm… we’ve only got 150 hours in the pool, and that means we’ll hit a stop really soon. Let’s look at something smaller.”
Good planning can try to avoid this, distributing hours throughout a 3, 6, or 12 month roadmap to ensure a stream of activity, but one good (but difficult) idea could completely derail everything. It’s fickle, and yet is the de-facto way most companies interact with their agencies.
Capabilities:
A problem, when working with any company, is understanding the actual resources you’re given to. The problem, moreso when paying for people by the hour, is understanding what that hour buys.
How often have you worked with a company where they charge, for example, £100 p/h for “development”. Is the person that builds your projects always the same? (probably not). Is the skillset of the people building the projects always the same? (almost certainly not – no two people are created equal). How junior might the people working on your account be? (you’d have no idea).
When billing for work by the hour in the old days, we calculated my time and that of junior developers on my team all as “an hour = an hour”. Stats collected prove that what my junior developers could deliver in a week, I could deliver in a few hours. That’s not to berate the junior developers – everyone starts somewhere and I have been in those shoes – but the point is that an hour of everyone’s time is not an equal unit of measurement. The output is what matters.
If a senior developer and junior developer were paid £5000 to complete a project, you’d expect the senior developer to complete it quicker. Their time is therefore worth more, and yet when companies bill it, it’s always a flat-rate.
Should customers worry about that – no. And it’s great that they don’t have to. But if you think about what gets budgeted for – the likely option is that everyone (or an unlucky someone) gets the larger estimates and any gains are considered profit.
The solution:
We use a tracks model, which defines N concurrent projects that we work on, usually for a year at a time. Instantly, this gives our customers two things:
- We’re working on things throughout the year. There will never be a break, which means we’re always going to have something to do. That takes away one of the worries of taking on big projects and “running out of capacity”.
- We’re working on N concurrent projects. Big or small, easy or not – things are always getting done. There’s rarely a discussion of having to simplify projects, because we’re worried about it stopping all work – other things will continue to progress in the other workstream/s.
Looking also at skillset, and the overall sentiment behind what we do, there’s a very different feeling. Instead of focusing on the input – how many people, how many hours etc. are we investing, we get to focus more on deliverables. We aim to deliver a certain amount of Tests through the year, to achieve certain goals as part of the CRO programme etc., and know that with a continuous stream of work, we’re bound to get there.
That’s no different to how most companies work with salaried employees, and it’s the relationship we certainly prefer having with our clients. There’s still accountability, still goals to hit etc., but it’s done with a focus on those goals, not on hours invested.
The results speak for themselves:
We’ve done some recent studies into what our managed-service clients get as ROI, and it shocked us to see how great it was.
Across a range of industries and different sized clients this averages out at an astonishing 26x return on their investment.
When we work together in the way we’ve described, and really focus on hitting goals (whatever it takes), we really do smash our targets. While customers ask for 5x or 10x ROI, we consistently smash those targets.
If you’re growing weary of the hourly model:
Come and have a chat with us. Our managed service really is best-in-class, and the way we treat workload is just one of the reasons why we do so well.
