engineering is cost management
ideology
Throughout my time managing Engineering at NodeFlair. Besides learning to write better code, I have also always learning to be a better engineering leader. Not quite there yet for sure, but often when making decisions, I realized that my decisions are guided by these thoughts.
Disclaimer
These are my personal opinions and what works for me now, and may not be as relevant for you. Well, they might not even be relevant to me in a year time, but who knows?
Engineering is Cost Management
What I am gonna say next is probably uncomfortable and you may not like it, but neither do I.
Fundamentally, engineering is merely just another cost centre of the company.
What you need to know is that as the management (oh wait, that’s me too), the question I always ask is “Does it bring the company more money than it cost?”
Why write good software then?
No business dies from a legacy codebase. Well, at least not directly. A well-maintained code base with nicely modularized code that follows good software engineering practices and is easy to test and change, means the company can move a lot faster.
Need to expand your addressable market?
💰 Build new features and get more users → Profit!
Market changes (COVID-19 anyone?) and there’s a change in users’ needs?
💰 Adapt the product quickly to cater to new demand → Profit!
Hired a new engineer and want to waste no time in getting them building fast!
💰 Less time wasted on onboarding and be more productive → Profit!
Developers are happy working on the code?
💰 High retention and low recruitment cost → Profit!
In my other blogpost To test or not to test (Startup Perspective), I also explained the benefit of writing software test, even for a startup. TL;DR: Sometimes writing test can help you move faster.
What do you mean we don’t need Machine Learning?
Hey, let’s add Artificial Intelligence… and Machine Learning! Oh wait, let’s migrate to Microservices! No wait, let’s rewrite our codebase in Golang. Look, let’s try out that latest Javascript framework?
Stop it, just… stop it.
Those most likely doesn’t solve your problem.
Well sure, there may be some situations where it makes perfect sense to make these changes. Perhaps the product has grown to a size where the current architecture and design are struggling to keep up with the demand. Perhaps the language or framework you are using is rather outdated and it is getting increasingly difficult to attract the right talent.
But on multiple occasions, I have spotted teams adopting these new changes just because they are cool. Often, these bring about minimal positive changes, if any. On the other hand, it brings about a lot more unnecessary complexity to the software, and increase the onboarding time for new developers. Let’s not also forget the opportunity cost - the time could have been better spent on work that brings about actual impact!
Wait, so I shouldn’t hire the best talents?
Yes, and no - it depends on the definition of “best”.
Also, there are a lot of other factors to consider when building an engineering team. For us engineers, it’s always exciting to work with world-class talents - 10x developer, ninjas etc. However, for engineering leaders, you will face challenges building a team.
This is rather straightforward. Top talents are in high demand in the market right now. Companies are paying top dollars to fight for them. You can check out what companies are paying at NodeFlair Salaries, a product out team built to empower engineers to look up the latest salaries in the market.
In addition, you want to avoid hiring someone overqualified for the role. Think of it as server management - you want to avoid overprovisioning. While one may argue that it guarantees performance (and it’s true), the downside of overpaying for the unutilized resources is greater. Similarly, you are not probably utilizing the skillsets of someone that can invert a binary tree or reverse a linked list from FAANG if your application isn’t that complex.
Also, from a perspective of the cost-to-output ratio, it might make a lot more financial sense to hire 2 great talents rather than 1 engineer from the 90th percentile.
Conclusion
If you are an engineering leader at a larger company, or different industry, or simply has a different opinion, do let me know! More than happy to hear from everyone.
Cheers, and see you later alligator~
A little about what I do at NodeFlair…
The world today runs on code written by developers that solve the world’s problems and impact lives.
Now, imagine a world where developers get to code at a place where they find purpose in their work. This meaning could translate into drive that pushes boundaries to solve more of the world’s problems.
That’s why at NodeFlair, we make it our mission to improve the world by empowering developers to code() at where they love.