Leadership tips
Time actually is money
And why your mid-levels often don't get it
Quinn Daley they/them or she/her
Technical leadership consultant
“Time is money.” It’s one of those old business sayings that sounds outdated and to me evokes a stern micromanager telling their team to stop slacking off.
But it actually does have a useful meaning in the workplace, and one that is surprisingly not well understood, especially by the members of your team who are a bit earlier in their careers.
What “time is money” really means
If you’re paying your staff well (and of course you are), then every individual team member is going to cost you a significant amount every single day just by being at work.
There’s no substitute for an internal team, but having one is expensive.
Given the choice between paying for a service and asking your team to do it “for free”, the “free” option is often not the cheapest option.
A worked example
A classic example in software engineering is the “Platform-as-a-Service vs Infrastructure-as-a-Service” question.
Let’s say a PaaS provider offers you hosting for your application with autoscaling, managed hardware and OS upgrades, and zero-downtime deployment infrastructure. To configure your app for their platform, you have to conform to their specification and then supply, for example, a YAML file containing your preferences and settings. For this, they offer the service at a price of $50 per month.
Alternatively, you could spin up all this yourself by building it in Kubernetes or Terraform, building pipelines for all the updates and scripts to manage all the infrastructure changes during a scaling incident. Maybe once you have it all running, your costs on AWS or another IaaS are going to be something like $10 per month.
That’s a substantial saving, right? 80% of the monthly cost, rolling over forever.
But how much effort did all the rolling it yourself cost? Let’s imagine you did it with one engineer and - somehow - managed it in 10 working days. Let’s imagine that engineer’s salary is $100 per day (actually, when you factor in other costs for salaried employees, it’s likely to be a lot higher than this). That means you’ve added on an upfront cost to this scenario of $1000.
If you divide that $1000 by your $40 monthly saving, you get 2 years of time. Now, maybe your application will run on this infrastructure for many more than 2 years, and maybe it doesn’t need any more of that engineer’s time to fix, debug, tweak, improve the built infrastructure. But the reality is that both of these are risks, and they might make that $40 per month saving seem much less attractive.
We really hate paying other people huh?
It seems to be a common line of thinking in this country - and maybe elsewhere too - that we should never pay someone to do a job we can do ourselves.
Don’t pay a cleaner when you can clean your own house, even if it takes the whole of one of your few free weekend days. Don’t order a takeaway when you can cook yourself, even if you’re tired and have no ingredients in the house. Don’t get an electrician to change those lights when you can watch a YouTube video with instructions, even if there’s a serious risk of injuring yourself.
Now obviously in our personal lives there’s lots else to consider here. The prestige of doing something ourselves, the chance to learn a skill, class & power dynamics, and more. But in a business context most of these can fade away to a simpler equation about cost vs value.
The free trap
Let’s say you’ve already decided that you want to buy a product from a service provider instead of building everything yourself. When coming to choose providers or plans, you’re given the option between something free (maybe open source) or something that costs a recurring monthly fee.
Choosing the free option can feel like an easy choice. You can at least evaluate the approach without any financial outlay, and if it requires a little work internally compared with the paid option, this is surely worth it.
This is often true! And there are often other advantages, especially to choosing open source over something closed and proprietary.
But free options can also be a trap. If you end up investing way more of your team’s time in the free option than the equivalent monetary value of the paid option, it might actually cost more in practice.
I’d suggest whenever you choose a free option over a paid option, it’s worth putting a strict “timebox” over the amount of effort your team puts into evaluating it, and then revisiting if it is good value-for-money.
The fun trap
Building something yourself is more fun!
This is the reason most engineers got into engineering. No newly qualified engineer wants to spend their whole work lives reading third-party documentation and then just installing and configuring stuff.
And the “fun trap” is the main reason your mid-level engineers are unlikely to ever understand that time is money. “Don’t pay for that, I can build it myself!”
If you think about it from the engineer’s perspective, they’re not in charge of any budgets… from their perspective, they do valuable work contributing to a product and money magically appears in their bank account at the end of the month.
If they take on the task of solving an engineering challenge, they’re saving you money from their perspective, because they’re unlikely to be thinking about their own time as a charge on your bottom line. They’re at work anyway, so they might as well do this, right? Except… they could be doing something else with that time!
Sometimes it’s the right call as a leader to let people do the fun thing. Everything is a tradeoff, and if the cost of paying someone to do this is a demoralised team then it might be the wrong call.
I tend to follow a rule-of-thumb that if something is “core” to your product - it’s part of the reason your product exists, like a end-user feature or design, it’s usually better to do in-house even if it’s more expensive. If it’s something “incidental” to your product, like infrastructure, monitoring or security scanning, it might be better to buy in. This rule doesn’t always work but it’s a good starting point.
What “time is money” does not mean
In this post, I’ve made the case that “time is money” is a true statement when it refers to the distinction between paying for a third-party service versus doing work in-house.
What it does not mean is that you can get more value out of employees by micromanaging their time. People only have a finite amount of creativity to give, and managing their time will have the opposite impact from what you might hope to achieve. I explore this concept more in my earlier blog post, “My team are slacking off!”.
How to balance this at work
The most important thing I find is just to remember that no work is “free” - if anyone is ever doing any work, it is costing your team money (unless you’re not paying your staff… then we need to have words!)
But sometimes being able to do the calculation helps. Try dividing a person’s annual salary by 1500 to get a rough hourly cost. People typically work more than 1500 hours a year, but remember the costs of a member of staff are actually considerably more than their salary, when things like employers’ National Insurance, pension, equipment and so forth are taken into account.
This can also be a good way to look at how much, for example, an all-hands meeting costs. Making that meeting 30 minutes instead of 60 could potentially save you hundreds of pounds if there are a large number of people present.
But in all things, don’t forget that people aren’t numbers. It’s always critical to remember why you’re doing something, and what all your individual team members’ personal motivations are. Sometimes the more expensive option is the better option. Time is money, but money isn’t everything!
Fish Percolator is a technical leadership consultancy based in Yorkshire.
If your team is not running as smoothly as you'd like, you have long gaps between releases or bugs in production, or your people are not excited about coming to work every day... we can help!