The high cost of seemingly small code changes can be explained by looking at an operations management concept called queuing. Every additional person or step needed in a process significantly increases the time and resources needed to finish a task. The problem can be broken down into two parts:
The cost of handovers
Every person involved needs to pick up the task, understand it, execute it and then hand it over to the next person. Note that only the middle part of it is the actual “doing of the task”. The setup and handover parts are fixed costs that need to be added to each person’s time to execute the task. For example, let’s say it takes 15 minutes to pull up and read the instructions for a task. If only one person is needed in a process, the total set up time is 15 minutes. But if 5 people are needed, the cumulative set up time is over an hour. Even if the cumulative time of the effective work is the same whether it’s done by one or 5 people. The more handovers, the more setup and handover time is needed.
The cost of queuing
Each step in a process requires a new queue. Each queue needs to be managed and prioritized, i.e. each team (and individual) needs to constantly figure out what to work on next. In most software development teams this is managed through an agile development approach that involves project managers, scrum masters and/or product managers. Each additional queue represents a certain waiting time for a given task to make it to the front of that queue (eg the top of a backlog or inclusion into a sprint cycle).
Applying these concepts to copy changes, it’s easy to see how a seemingly simple change can take a painfully long time. Each change might require multiple handovers and each handover means additional setup time and waiting in another queue.
So what can be done to improve this? We can create processes and training to efficiently manage the handovers and queues and decrease the time by 10%, maybe 20%? Or we can eliminate handovers and queues all together. We built Strings to do exactly that and allow teams to ship product improvement faster. To estimate how much time your team could save, we created this example which can be modified based on the specific circumstances of a given team:
Estimating time savings of using Strings
Let’s go through each step that Strings can eliminate or reduce:
Mileage might vary widely depending on the complexity and size of the app, the experience of the team etc.
Time is expensive
Hiring and retaining top engineers, designers and product managers is difficult and expensive. So saving time is valuable. To translate time saved into money savings we assumed ~$180k in annual fully burdened salaries. Fully burdened means not just the gross salary of a given role but all the additional expenses that come with an employee (recruiting costs, healthcare and other benefit, taxes etc). Again, this might vary widely depending on your industry and regions so you can scale these costs up or down as needed.
The time savings are significant but don’t capture the whole picture. Another aspect of time-consuming handovers is the frustration for everyone involved. Writers can’t effectively do the work they were hired to do because any change can take weeks to get to users. Or improvements never even make it into the product because other priorities keep coming up. On the engineering side, most developers feel copy changes are frustrating and tedious tasks that crowd out new feature work that is more exciting.
So next time you’re trying to get a copy change pushed through your product development process, talk to your developers how Strings can short-cut the process and save your team a bunch of time. Strings takes a couple minutes to set up - a fraction of the time it takes your team to make that next copy change.