How to introduce technical improvements. Part 1
“It’s a properly engineered system, everything is good there”
© Nobody.
We have all been there — you see something that is not right in current architecture, codebase, you see flaws in technologies used, processes happening, and you want to improve them, to make things better. You see, that using NoSQL database or a new frontend framework can bring tremendous benefit to the current system.
You wrap your proposal to the one short message, post it to the one of company group Slack channels…
And receive immediate pushback. A lot of people coming to the thread, posting things like:
- Are you aware of the scope of changes requested?
- We use current technology/framework/process and we are completely ok with that
- We don’t have enough capacity to implement this.
- It’s not in scope right now
- It’s too expensive
- It’s too risky
- We’ve tried something similar before and it failed
…. and many more
What went wrong?
First things first, unless you are implementing a top-down improvement decision from the upper management (which, actually, often a result from well-developed bottom-up initiative), going head-on to solve the problem is the worst approach you can take. Let’s see why, and what you can do to increase chances of proposal being accepted.
Everyone is busy with their business priorities
It’s natural for the business to utilise their workforce at the maximum capacity. Unless this is pre-2022 Google, where the amount of engineers were more than demand for them, you will probably see all the teams in your company are fully packed for the next quarter. Or half-of the year. Or the next year completely. Because engineers are meant to solve business problems, most of these roadmaps will be purely product-related, to increase revenue, retain customers, perform proper business experimenting and so on.
The system already works somehow — understand the history and respect what came before
Utilising cutting edge technologies, frameworks and processes have little-to-none correlation with company financial success. Current system works and brings money! Why we need to change anything? And the bigger and more successful company is, the more resistant to change it will be. Furthermore, there will be people who will directly tie current way of doing technical things to the business performance. As you already know, it’s a false assumption, but it’s a very widespread one, and that is something you need to consider.
“Netflix is successful because they use Cassandra”
“Amazon is successful because of the rigorous deployment process”
And so on. Usually, there are very good decisions been made at some point. (If it’s not falling apart — probably it’s ok?)
The key idea here is to understand the history behind the way current system works, down to the very beginning. It’s very good, when all decisions are documented in form of RFC/ADR so anyone can read about all the milestones company walked through, but if there are no documentation, there are always people who remember why it was built certain way, and the key decision drivers at that point of time.
Maybe, while digging deep into this, you will understand that there is no need for change, because there is always a reason why system works that way it works. Fixing the aftermath after shortcuts taken is one thing, but trying to amend deliberate, planned and verified decision — it’s completely another story.
We all stand on the shoulders of giants. You need to know these giants.
The “Why” part — is this actually a problem ?
“Selling” technical initiative is absolutely like selling product on the market — there is a demand and there is a supply.
If there is no demand for the improvement — selling is almost impossible. Of course, there can be cases where the problem and the solution are very obvious and explicitly stated, but nobody can/willing to pick it up, in those cases everything is much more simple.
But, apart from that, the most important part before selling technical initiative is to understand why you want it to be implemented.
Here are some completely legal reasons — technical improvements, that can also play a crucial role in supporting and enabling business objectives, directly and indirectly:
- Performance improvements (reduce service response time, reduce amount of hardware resources needed, increase throughput)
- Security & reliability improvements (eliminate breach/improper usage risks, improve uptime score etc.)
- Engineering process optimisation improvements (Invest in reducing support hours so people can spend more time on product features)
- Cost reduction (If this an issue — sometimes companies trading this off for 100% product focus — thing to keep in mind)
So, first things first, you need to understand the benefit of what you are trying to do. If you can express this in numbers (and almost every improvement can be expressed in numbers), you should do so. It will be easier to convince people that this is needed.
A note about “Enabler” and consolidation improvements
“Never perform a refactoring unless it’s consolidation” ©
Sometimes the improvement doesn’t make things better directly, but enables a new way of doing things, or simplifies current system by unifying shattered approaches under a common one. Stitch all the API’s under one api gateway? It’s a consolidation. Introduce new message technology to work more efficient/fast — It’s an enabler.
Usually these are the things that affect a lot of teams and don’t bring direct value, so they are hardest improvements to sell, and I would advise to not go for them unless u have a lot of experience selling simpler stuff, credibility and/or an explicit mandate from the upper management to do so.
The management mandate
As you know already, everybody is busy. Usually it’s the result of careful planning and alignment process, a lot of effort was spent to make tasks properly lie on the timeline. And, as u remember, the business tends to utilise engineering time in full, so there will be very hard to find gaps in the schedule.
However, a good manager always leaves capacity for unplanned/emergency work. And a good manager always knows the pain points.
So, if you need to venture into the territory managed by somebody else (it can be your team as well), you need to align your intentions with the person running things there.
Actually, once you understand what are you trying to build, and what benefit it will bring, it’s the first thing u need to do. Why?
- There can be more prior technical work, e.g. low-effort high-reward tasks, and u can bring more benefit for the company and team by doing these things.
- The solution you propose can carry unacceptable risks, which will slow down feature delivery, hurt reliability etc. (and the manager is accountable for that).
- You might need engineering time of your peers. Remember, engineering time is the most precious resource in tech companies and it won’t be given without proper reason.
Who to align with?
Usually, it’s very easy to determine the person u need to align things with. If it’s within your team boundaries — you need to align with your direct manager. If the solution touches other teams/domains/tribes you need to follow all the way up to the top. Just ask your manager. They know the way.
It’s better in written form — document things
Once you aligned on the need and benefit, and received a green light on the improvement, it’s time to write an RFC. What is it?
RFC stands for Request for Comments - It’s a document, which describes the proposed change, benefits, drawbacks and alternatives in concise and understandable form.
Why do I even need to write something if we aligned everything with the manager?
Being right once doesn’t mean you don’t have to say it again. Even if you had some conversations and you managed to convince some people on the need of your technical improvement, there are lots of other people out there who can benefit from your decision, provide valuable insights, or present an opposing view.
And, is worth to be stated again — everybody is busy with their priorities. Writing things is a best way to scale your thoughts, because people can read at their own convenience despite your schedule. Also, as you remember, it’s always better to have history of decisions made.
Plan, prototype, plan
While it’s very common to see people try to plan things down to the very little detail without writing any piece of code (and sometimes, it’s even a company way of doing things), it rarely works for multiple reasons:
- If there is a new technology being introduced, the low level of knowledge of it usually can lead to wrong assumptions and wrong design decisions.
- Architecture alterations can be both under- and over- engineered. Latter is more often.
- There is always a missing piece, not covered edge case, or, otherwise — some point of design process, when wrong decision was made because of edge case.
- Often, thorough planning tries to cover up as many aspects and pathways as possible, because often we, software engineers tend to build “one generic system to rule them all”, which bloats the scope of our technical improvement and reduce chances of proposal going live.
- There is no maintenance & support experience gained, so it’s very hard to estimate costs on it.
What to do with it?
Always go with a prototype in multiple iterations, revisiting RFC after having some results from the prototype testing.
Even a small working example can give far more information than any model. It’s not unusual, that after first pilot, many points of the RFC will change, some will be added, some will be thrown away, and even the whole RFC can become obsolete after quick test.
Just remember — even well-defined, strict-scope projects, like spaceships or cars, go through countless test iterations and adjustments. It’s natural that new insights and understanding are gained through design and implementation.
In my opinion, no RFC should come without small, easily measurable proof of concept.
The fear of throwaway work
One of the reasons technical improvement proposals without prototyping don’t get any attention or approval, is that people usually don’t want to do things, which can be thrown away in foreseeable future. And it’s very logical — why do even start something that will eventually be discarded?
Having a good incrementally-verified prototype can mitigate this problem, as usually next step is to make this production ready / scale on higher level.
Summary
In this part, we covered basic concepts of introducing technical improvements. Of course it’s much more than can be covered by one short article, and the process itself can differ significantly from company to company, but, hopefully, it can give some perspective on how to approach things from the very beginning. Stay tuned for further updates, an happy hacking!
