A story about how I reconcile the notion of “time” versus “productivity”.
As a developer who has worked primarily in software development agencies for my career, I am used to the notion of “tracking time”. Historically (though not currently in my team), this looks something as follows:
A request will come in for some sort of change to a system that we manage. I will draw on my expertise to make an assessment of the difficulty of this work if I complete it, and I make an estimate.
The estimate gets returned to the project owner along with a price, and the project owner decides whether this work should proceed based on that estimate.
I proceed to complete the work, tracking the time I spend completing it in some system. This is usually tracked against the estimate, wherein if I do not complete the work by the estimate I gave I inform the project owner and give a revised estimate, at which point that project owner decides whether to proceed.
Rest, and repeat. A conceptual model that works fairly well, is easy to understand and keeps all stakeholders fairly aware of the costs, and expected return on investment that they can expect.
Choosing the one master instead of the many
As the Sitewards company in combination with our project partners has grown we have shifted how we allocate developer and project management resources.
Initially, when working with project partners without the budget to purchase a developer or development team for a fixed period of time we would have many developers touching many different projects. The work items would come in, be estimated by one developer, sit in a queue until completion and then be deployed. This system worked satisfactorily, and we delivered the requirements to spec.
Over time and as we up-skilled, the projects on which we would work would become larger and larger. Each developer would, by happenstance, gain experience with a certain project. This developer would thus know a great deal about this project, and be able to deliver a greater level of value for a smaller period of time.
Eventually, the projects became so large we allocated several developers and a project manager to a single project full time.
Blurring lines between producer and consumer
With the allocation of developers to a single project for months at a time some remarkable properties were noticed. Developers would specialise in that particular application, learning the software, the particular project owner requirements, the projects end-users, the vision of the project owner and their team and what they wish to accomplish over the long period.
Additionally, a very human attachment would grow between the project team and their project. Not only would we learn, in an abstract sense, what the project was about — but we would also learn who each of the people were behind that project, and begin to value them as comrades working to improve the project on which we work. We, as a team, would collectively “buy in” to the projects mission.
This increasing ownership would give rise to an increasing transparency into otherwise opaque development processes. Not only would we wish to take an interest in the project and its customers, but we would also invite other stakeholders into our contribution, detailing how we, the project development team, were able to contribute to shared vision between the project development team and other project stakeholders.
Determining billable time
By nature, this investment of the project development team in this shared vision gives rise to a remarkable amount of considered time and effort. Not simply in the completion of a given set of tasks like in the aforementioned service mode, but in the idle time given to each project team member.
In my team, at least, we are passionately driven to improve the project owners product. We are reshaping ourselves, our processes and our policies to increase the value of what we are able to deliver to the projects goals. We each do our own research, reading and writing to better understand each other, common technical challenges and how they apply to the project and to further understand the projects end-users and how we can improve their lives.
The problem with this otherwise virtuous process of investment and iterative learning is that it is difficult to map into a billing model in which we are attempting to work for a given amount of time for a given result. While previously, with no investment beyond the required by the development team there was a clear line between what should be billed and what should not. When the project teams are truly invested in a project it is both extremely difficult to map how each chunk of their time contributes to the well being of the project such that it should be “billable”, and short sighted to try and increase the amount of “billable time” as it will negatively impact the value delivered by the project team.
Consider the following examples:
Reshaping a requirement to build an XLS import to take advantage of existing import tooling
Recently a story ticket was created by the project owner based on internal requests to create a “XLS import”. As necessary background, XLS is the “Microsoft Excel” file format, used for storing tabular data.
Understanding the Excel format is a complex undertaking. Excel is such a powerful tool that designing an import process that factors in its peculiar file format is an extremely expensive and complex exercise, and given it’s complexity will give rise to a large number of edge cases (bugs)
However, because this ticket came down through the team who had already done the work of establishing a relationship and trust directly with the project owner, we were able to further pick at this story task to understand the requirements that generated this story.
In the end, this story was reduced down to a CSV import for which there is already well tested tooling, albeit with some minor extensions to handle some bespoke data. A dramatic reduction in the investment required by the client for a superior technical result, but one that came at the cost of many hours of potentially billable time by Sitewards.
Doing research on the implementation of performance and reliability metrics with a view to implement explicit and clear trade-offs during development
Many of the engineering challenges that we face as part of our work are essentially the same, or at least very similar to those that other organisations have faced. As such it behoves the motivated software engineer to find the developers who have faced similar challenges in these other organisations, and either read material that they have read or talk directly to them about the problems that they have faced.
One such example who’s implications are by nature unintuitive and quite hard to understand is the implementation of “service level objectives” (SLOs). A brief explanation is that these SLOs are numeric goals that indicate the project health, based on previously established “service level indicators” (SLIs).
To establish these SLOs allows clear trade-offs between project performance, reliability and feature development. However, because they are unintuitive and require a certain amount of understanding and buy-in from all stakeholders, it is impossible to get funding for them — despite their reported retrospective necessity.
The majority of understanding, experimentation and learning for topics such as these SLOs happens in (at least the initial) developers “personal time”. However, when applied to a given project it becomes immediately apparent of the value of these objectives.
Accordingly, it it thus reasonable that the entire period of learning associated with understanding SLOs be billed immediately? Or a portion of it? What topics are suitable to be “billed”, given their inherent greenfield (or uncertain ROI) nature?
It is a simpler conceptual model not to think about whether this given time was a worthy investment, but rather to make the decision that those team members who research this and other similar topics in balance with deliverable feature work are a good investment at the arbitrary rate they charge on a weekly basis. In this way we are assured that we will gain both the continued improvement associated with such research, but at a reasonable cost.
Implementing tooling designed to decrease investigation time
Lastly, a well invested project team understands that the time they’re given to investigate, understand and resolve issues and develop new features is finite and is thus is motivated to find ways to better make use of this time.
One such example of this investment is to add tools that are designed to expose information in a simpler format that the project team might either not otherwise have access to, or not have access to as quickly or easily. Such examples of this tooling include:
Log aggregation
Time series metrics instrumentation
It is both possible and not possible to implement these changes, and still complete work to a satisfactory way. However, if a project team understands that their time is expensive they will add such additional tooling to the system such that they’re able to debug issues more efficiently, as well as provide more accurate information to the project owner.
Such a project development team driven change is something that is intuitively hard to justify for the project owner, particularly absent the experience to compare projects that have this instrumentation and that do not. However, a motivated development team will continue to push this topic, knowing that the investment will pay off for the client even at the expensive of billable hours.
Another (better?) model for determining value
To return to the genesis of this article, we do indeed work for an Agency who sells a fixed amount of development time (often months at a time) for a given rate. Accordingly, it’s a shockingly easy trap to fall into to determine that we should be increasing the amount of billable time to a given amount to ensure the businesses success, and make the trade-off to absorb some of the cost of the aforementioned innovation. However, I believe this to be a poor model of performance for the company. There are two alternatives I would suggest that are superior:
Project owner business metrics
More generally, we work for other for-profit companies attempting to increase the quality, amount or efficiency of a service they provide in turn to their end customers. Accordingly, it stands to reason that in order to understand the impact of our work we should be evaluated against our contribution to those metrics. It is perhaps the simplest, clearest form of this relationship and makes it extremely straight forward to both establish ROI and a framework for managing the relative worth of the project teams contributions. Such metrics would look like:
Total transactions through an e-commerce store
Leads generated through a free, online service
Performance, reliability and latency characteristics of a given service
This would further allow each story to be evaluated in the context of such metrics.
Velocity
It is also a reasonable position given our agency nature that it’s perhaps not wise to pass across internal, private business information to an agency to allow them to evaluate their own performance.
However, it is also difficult, given the limitations identified above to say that time is a reasonable measure of project or team performance. Accordingly, I would conjecture the best proxy measure of performance would be in how much “complexity” we’re able to ship in a given period.
“Complexity” is a difficult thing to define, though my colleague Tom attempted to do this in another post. However, it represents a developers understanding of how difficult a given task is to ship, given the benchmark of another task. For example, if i was to say the benchmark task was to “Add a new terms and conditions checkbox to the checkout” I could say that “Adding a MySQL read replica authenticated by mTLS is 5x more complicated than the checkout task”.
These units can be tracked over time and compared across teams with common software stacks. This would allow a reasonable measure of which teams are more effective, and allow research into how and why they’re this way. However, it is still limited in that it does not capture the reshaping of requirements to reduce complexity and increase business value.
Arriving at a final, billable rate
This brings us back to the initial question of how to bill time, given that it’s the fundamental unit that we, as an agency, sell.
In our case we have the luxury in many cases of being booked for many months at a time. Further, we have built such a level of trust with our clients they are simply booking our development teams, in a similar conceptual model to hiring employees. The requirements of the projects often evolve, and we are always invested in generating the best possible return for the client.
As covered, it is difficult to allocate which tasks should be determined as billable and which not, particularly in a team that is invested in the clients success and is thus reshaping themselves to best fit to the clients requirements.
Accordingly, it would be my suggestion that it is worth simply selecting a period of time per day that seems suitable (perhaps 7 out of 8 hours) and assigning that as the billable period. It is practically how much time we’re able to allocate to the projects, and not distracted by other internal concerns such as maintenance on shared systems, general meetings and other information sharing.
It is additionally worth noting that time is not the only lever that controls what these project teams are worth; there is additionally the rate at which they are billed. While such high billable rates can seem daunting, especially compared with the rate/time given by other providers, a motivated development team will work several times faster than those that are otherwise not allowed the luxury of investing in their projects.
In Conclusion
The nature of our business is predicated on the notion that we will bill a given amount of time for access to a project team. However, as we and our partner projects grow we are able to invest further into these projects, and where we spend each unit of time becomes less relevant than the value we’re able to deliver for that project over the larger span of time.
Accordingly, it is my thinking that granular tracking of time is a poor representation of utilisation, and while collecting the data may be academically useful it is not a reasonable set of data on which to make organisational decisions.
Thanks
The team at Sitewards, for putting up with me continually pushing back on granular time tracking.
My team, for the discussions around value and time.
Antonius Koch for an early review.
An amusing aside
This post took around 2 hours to write. But, it took considerably longer to think about. Indeed, I’ve been thinking about this for months, and I’ve been making notes for ~2 weeks.