When I say “you”, I mean owners and managers of software development companies.
The events of the last 3 years have brought many changes to the business of selling and delivering software development services in Central or Eastern Europe.
(btw, it’s been 3 full years almost to the day since the pandemic started in this part of the world. I vividly remember my day at the office on Friday, March 13th, 2020, the last day at the office before the lockdown. Time really flies fast.)
The big impact of WFH
About 12 to 14 months in the pandemic I started hearing one common complaint from friends and clients:
“It’s very difficult for us to retain good software engineers in our companies, because they receive insane salary offers from companies based in Western Europe and the US, which are now able to hire them directly, because all their employees are working remotely anyway.”
If this would be the problem, I would not be worried too much. Many of you have found solutions and workarounds for this challenge.
I see a bigger iceberg just over the horizon: the mismatch between the metrics in your business model.
Learning from other’s mistakes
To illustrate this, I have to make a small detour here and tell you a personal story.
In 2016 we started a renovation project for a building.
We hired a construction company after a long due diligence. An established company, in business since the 1990s, with more than 50 workers, doing multiple projects at the same time.
We started with very detailed estimations of activities, steps, timeframes, materials and labour costs.
The requirements did not change at all during the construction, because the building context (listed historical building) and the planned function (kindergarten) would not allow us to make any changes from the approved plans.
Our contract was based on square metres of walls, floors and ceilings built. The prices we paid and the total estimated budget was based on calculations of surfaces and areas.
The problem?
They were paying their employees based on time, not tasks or activities.
So the longer it took to finish the work, the worse for the company.
We started work on-site in August 2017.
The initial estimation was for 12 to 14 months to complete the project.
When was the project completed?
In August 2020.
The owners and project leader of that company were:
- Competent engineers
- Very experienced
- Well meaning
- With a long history of successful projects behind them
- That did a very good job on our building, both from a quality of construction perspective and the personal relationship with us and communication throughout the project
They finished work on our site in August 2020.
In October 2020 they went bankrupt and the team disintegrated.
I don’t have to see all their financial history in detail to know why that happened.
A company that quotes a project with prices per square metre,
pays their employees for time (monthly salaries),
and delivers a project in 36 months instead of the estimated 14 months
cannot stay in business too long.
I know what you might be thinking:
“Ha, that’s why we never do fixed-price contracts with our clients for software services!”
That’s true and a lesson well learned by most software development companies around the world.
But that’s not the moral of my story.
Because there are very successful software development companies that choose to sign fixed-scope-fixed-price contracts for certain types of clients and certain types of projects.
There is another lesson in this story.
How remote affects software companies
What I am now seeing in the industry:
Quiet quitting = employees who put no more effort into their jobs than absolutely necessary.
Hacking remote work = “how can I significantly decrease the footprint of my remote job without anyone noticing”?
Work-to-rule (also known as an Italian strike) = a job action in which employees do no more than the minimum required by the rules of their contract or job.
Parkinson’s Law in time management = work expands to fill the time allotted for its completion. This may mean people take longer than necessary to complete a task or they procrastinate and complete the task right before the due date.
When all your employees were working together with you in the office, you could always go in front of your clients with a straight face and say “Yes, John has worked on your project for 8 hours a day, every day of last month” and send the invoice.
When most of your employees work remotely at least some days every week, if not all the time, what does this mean for T&M (Time and Materials) contracts?
What are you paying their salaries for?
8 hours of work per day?
A number of tasks or stories documented in JIRA?
Lines of code written?
Or outcomes? Deliverables? Activities?
Can you still maintain that straight face in front of your clients?
Even if you know for a fact that your employee worked for 8 hours every day, will all your clients believe you?
Will they believe you enough to be willing to pay the high price you are now forced to charge, to cover the increase in salaries?
Metrics, metrics, metrics
When you analyse your client relationships you will see that you have 3 types of metrics to think about.
Pricing metrics: the unit used to charge clients and what you put in your rate card.
Value metrics: what clients use as a measure of the projects’ performance. Not always explicit.
Usage metrics: how progress is reported and measured.
Here is an example of misaligned metrics in a typical software development project.
| Metrics | For the customer | In relation to employees |
| Pricing | Hourly rates | Monthly salaries |
| Value | ? | Perceived level of effort (“being busy”) |
| Usage | Tasks in JIRA | ? |
For a business to be sustainable, you need to find the right balance and alignment between these metrics.
This is not a question of right or wrong. There is no universally applicable rule.
Some metrics are not better than others on their own, in a vacuum.
There is surely no moral or ethical dimension here.
It’s just a matter of maths.
You need to find the right combination based on your strengths, business objectives and current constraints.
The events of the last 3 years have thrown a big wrench in the wheels of software development as a service business model.
It’s in times like these that tomorrow’s winners are born.
When everything seems to be in flux, when entrenched habits are overturned and entire industries change almost overnight, this is when it’s the right moment to take proactive action.
WHAT THIS MEANS FOR YOU
Remote work comes with many benefits and advantages.
I for one am extremely grateful that I can work from anywhere I want, when I want, on what I want.
However, anyone managing a software development team in this new context needs to think hard about juggling:
> employees working from home
> delivering projects for demanding clients
> and finding the optimum pricing metrics and contracts structure to maintain and grow a sustainable business.
PS.
The inspiration to write about this topic came when I listened to Episode 236 of the podcast “Deep Questions with Cal Newport”, titled … “Hacking remote work”.
You can listen to it here on Youtube.