Stop getting stuck in the feature build cycle: Why engineers need space for success
If you’ve worked on any technical team then I’m sure you understand the struggle of explaining the importance of non-feature driven technical work to non-technical people.
Sometimes it’s called “buying back technical debt”, sometimes “maintenance”. But in reality, it can often appear to some as technical black magic that seems easier to leave alone than question.
It’s a common dance. Engineers are given features to build because users generally like them. And at the start of a product’s life this is fine. A feature is developed and with any luck people start to use it. However, before long — after receiving feedback or analysing tracking data — another feature is requested. Now the product team faces a fork in the road. Do they continue looking at the existing feature and how to improve it, or they build a new one?
Time is finite, and so inevitably these kinds of compromises have to be made every day.
But there’s a consideration we haven’t yet mentioned: the technical consequences of how we built each feature and the architecture that supports them. This is the silent killer that very rarely gets included in the build cycle mentioned above. Technical architecture tends not to have any direct relation to a user’s interaction with your product…until it does.
At Birdie, we have a variety of different types of users. Care managers, care givers and concerned family members. Each of them has a plethora of ideas about how the product can work for them. From these ideas branch myriad features that in very little time saturate the totality of our days. It was therefore very easy to fall into a request → build cycle.
We realised that we’d ignored the sleeping giant for some time. We needed to act.
In this article I hope to explain to both technical and non-technical people the reasons why we decided to solidly allot time to only non-feature driven technical work and the learnings we gathered at Birdie from our own engineering improvements period.
The warning signs
Perhaps one of the most important parts of understanding engineering improvements is being able to notice the signifiers of their necessity. I say necessity with some hesitation, as many engineers will stress a consistency of importance to this kind of work. One that would leave any listener with the impression that it is always necessary.
Whilst an argument can be made for this, we have to acknowledge that the dance between feature work and engineering improvements is one of compromise, and therefore we must throw away absolutes.
With this in mind, here are the significant precursors that led to us focusing solely on engineering improvements for a time.
Feature fatigue
There is a certain lethargy that creeps into the engineering team that solely works on features. A psychological drain whose root lies in having to produce over and over again. Imagine a factory worker. Each day they are asked to produce. Day in, day out, they receive a specification and they use what is available to them to complete the task.
Whilst this may seem simple to them at the start, soon they are asked to build a different product, and then another, and then another. All the while they are doing this in the same building, with the same tools, using the same process. With each day that passes, these factors become blunter and duller. Eventually the poor factory worker finds himself trying to cut a sheet of metal in half with a hammer.
This is the burden that consistent feature-driven work places on engineering teams. It does not only place a practical disadvantage on an engineer’s capacity to work, but also a mental one. Many developers are perfectionists by nature. We like to do things the best we can with the best tools and process available.
If something goes wrong with a feature, developers can often see this as a reflection on themselves, which in turn affects their mental health. To the emotionally observant person this most often converts into a lack of enthusiasm over new features.
Developers begin to see new features as a paradigm for complaint of the state of the current system. If a request for a feature is met with little enthusiasm and debate over how the current system will struggle to take it, this is your sign for feature fatigue.
Slow down
One of the more obvious signals of needing to dedicate more time to engineering improvements is the general speed of your release process. A team that is in need of engineering improvements often suffers from the following ailments:
- More bugs in the sprint
- Releases being blocked
- A reduction in the velocity of feature turnaround
Whilst these may have roots in other causes, if you begin to notice a worsening in any of these you should look to see whether a lack of engineering improvement work is the cause.
Much like the factory worker analogy in the previous point it’s relatively clear to understand why these symptoms may come about. Worse tools most often lead to lost time.
Performance problems
Any feature your technical team outputs is massively dependent on the technical foundation upon which it is built. Whether this be your API, version of React Native, or design system, these are the pillars upon which the success of your feature rests. At Birdie we deal with a LOT of data. Our architecture utilises event sourcing that leads to the generation of roughly 700,000 individual events per week.
No feature request is going to explicitly improve the way we process and handle this data, and therefore a focus on solely pumping out features (in our case) will only lead to more event generation. This will impact how efficiently we’re able to fetch data from our API.
If you begin to notice slow load times on your products or general sluggishness, you need to start considering that your product team has been disproportionally pushing for features over engineering improvements.
How much time should you set aside?
So let’s say you’ve spotted the red flags and decide to dedicate time to engineering improvements. The next question you need to ask yourself is: “How much time should I set aside?”
Whilst some may begin by suggesting incorporating this time into your sprint, we found at Birdie that if it gets mixed in with feature-driven work, it will always play second fiddle to it and be deprioritised when required.
The idea here is to pump the brakes on your feature work so that your developer team can change their thought process to one of maintenance and scale. This means, therefore, that you’ll need to allot a solid block of time. For us, we decided that four weeks was optimal. This gave us an initial week to clean our backlog of bugs so that we could enter the next three weeks with a clean conscience.
We chose three weeks for improvements because Firstly, it enough time to be able to see the consequences of the improvements we had implemented at the start, and their impact on any improvements that were planned for the end.
We were partially inspired by Basecamp’s six week work cycles, where they would take off two weeks after every cycle. However, since it had been some time since we had last done this (definitely more than six weeks) we felt we needed more hence why we landed on three weeks.
Our learnings
We found that performing this month of engineering improvements remedied all the aforementioned red flags at the start of this article. There was a noted vigour in the way developers approached new features. The speed of our release flow improved and there were significant advancements in the performance of our applications.
However, that does not mean to say that things went perfectly. As with everything we can always improve — here are some of our learnings.
Framing
We found ourselves falling into the trap of seeing this period as one for mainly buying back technical debt. Whilst this comes with its own benefits, it misses a large opportunity for developers to start approaching systematic problems creatively.
A lot of the improvements felt like very natural paths for improvement — upgrading React Native, bringing more of our data structure into event sourcing or adding more components to our design system. Whilst they were exceptionally impactful for the way we work, they were also very much inline with decisions that had been made some time ago and therefore didn’t require developers to think very creatively.
If we look at Basecamp’s model, they see this period as a chance for “pet projects” to be picked up as well as buying back technical debt. An engineering team that encourages this kind of thinking is one that grows leaders in the industry as well as within their own company. This is vital for growth and outdoing competition and therefore should not be sneered at.
Refinement
For the technical debt we bought back, one of the biggest regrets the team had was not refining it properly before starting. We held a large meeting before this period kicked off and it was within this that most of the refinement was done. Whilst developers had the opportunity to refine before this, no actual time was provided for them to do so as they were still working on features.
The result was that developers who were starting improvements found themselves losing time being on-boarded because they themselves had not thought of this improvement. In some cases, this ended up in improvements not being finished within the period and having to be wrapped up afterwards — a great source of frustration for all involved.
Metrics of success
To many at Birdie, the idea of a month with no feature-driven work is scary. Whilst this can initially be argued for with analogies like the factory worker used earlier, that will not be enough. People want results and simply saying that we’ve improved the developer experience won’t cut it. As well as this, if you spend time on something it’s vital to know the return you got for the time you spent. This allows you to assess the priority of similar improvements in the future.
Unfortunately, we did not do this in our recent period of improvement and therefore could only really explain the benefits and impact by presenting them to the company.
We could have shown them a metric to follow. I say follow, because naturally some of these improvements were only recently built and would not yet have had enough of an impact. However giving them a metric to follow would have allowed for a greater investment from non-technical company members into the purpose of an improvement.
These metrics also would have matured by the time we held our next improvement period, and would act as anchors for prioritising any further improvements.
Conclusion
Taking a break from feature-driven development is not only vital to the robustness of a product, but also the stamina and sanity of your engineering team.
I hope that this article encourages you, whether you’re technical or not, to consider engineering improvements within the context of your own product’s situation, and whether now might be the right time to put down the feature wand.
We’re hiring for a variety of roles within engineering. Come check them out here:
