Disruption Insights: Zero Technical Debt Is Usually Not a Good Goal
Bartosz has been with the company for more than ten years, which makes him an expert in software development, the business side of delivering digital solutions, and building engineering teams. He joined Netguru as a Ruby on Rails Developer, quickly becoming a team leader and then an Engineering Manager. See what you can learn from him.
We all know that well-defined goals and KPIs are crucial for the efficient organization of technical work, but we believe there’s more to that. The Disruption Insights series aims to uncover how household names manage their tech teams and how it translates into business opportunities.
🎯 Engineering challenges
Exciting engineering challenges right now
For years, it’s been an answer to the question “What should be the common denominator for our projects?”. With the right answer, our scale becomes our advantage. Wrong answers – and it becomes our burden. Our portfolio of projects is growing and becoming more diverse, which makes it a never-ending but exciting challenge to work on.
Main engineering challenges ahead
Our job is to create solutions for our clients. Depending on their future needs, it’s often difficult to predict what we will face in the future. It’s more beneficial to work on our flexibility and resilience to be able to work through whatever challenges the future will bring than to try to predict them.
💻 On the tech side
KPIs and missions essential to your role
I have a lot of metrics that ultimately are trying to answer the question: “Do we have an adequate capacity to deliver solutions for our constantly growing portfolio of clients?” Most important examples of those metrics are:
- People satisfaction and turnover
- Coverage of know-how (technologies/solutions, etc.) that our current and future clients will probably need
- NPS from our clients
- Revenue and margin – of course we need to achieve all of the above while still being a profitable company
Success in the software development process
My approach is simple here: If we reach favorable outcomes while keeping a satisfied team and a client, we are probably successful. For a more elaborate answer, I can highly recommend “Sooner Safer Happier” by Jonathan Smart.
Tackling technical debt
It’s a bit different in every project, but the ideal we strive for is clear: Technical debt is a tool to be used consciously.
A good debt is one that is used for investments, not for current consumption.
Same with the technical debt – if taken intentionally with clear understanding of outcomes for both the current business and future extensibility of the project, then it is a handy tool. Zero technical debt is usually not a good goal.
🤝 Internal cooperation
Engineering culture
Our goal is to have an engineering culture that supports the growth of an individual while providing an environment for the effective software delivery as a collective.
It’s a sum of our actions, our mindsets, and our decisions. We pay a lot of attention to what culture we are building.
Suboptimal engineering culture is like a headwind. While engineering culture is a very complex topic, it ultimately boils down to the motto: “Build things, tell people”. This is exactly what a great engineering culture is all about. Building great stuff and sharing the experience and lessons learned with others.
🧩 Hiring and team management
Making engineers satisfied and happy
First of all, ask them (regularly) whether they are content and, if not, what you would have to change for them to be. More often than not, they need something that is doable. So, I prioritize their expectations. If something is not doable, I explain why we can’t provide this or that condition. We all often feel bad about things that, once explained, become manageable.
Also, it is important to hire people that have needs compatible with what you can offer. A considerable amount of employee turnover is caused not by objectively bad projects, but by mismatch of expectations.
Recipe for preventing burnout
It’s possible to care a lot about your work but not to worry about it. It’s natural that if we care, we worry – but it doesn’t have to lead to burnout.
Employees should do their best, but then be able to let go of the expectations.
They can care, do hard things, but should not stress out about them. Having those feelings separated keeps me sane, and I recommend it to everyone.
Leadership style you prefer
It’s my role to adjust my leadership style to people’s preferences – not the other way around. My goal is to have as many styles as the number of people I work with. People are vastly different, there is simply no approach that works well for everyone. Adjust.
💡 Looking into the future
Upcoming technology trends
Outside factors are more influential in creating technology trends than the technology itself. What will the future job market for developers look like? Will it still be so demanding and finding talent be the primary bottleneck? What about access to financing? Will it be feasible to deliver big projects with a lot of risk – or will we tend to do smaller, less risky ones?
Factors like those actually determine which trend becomes a standard, and which one stays a buzzword.
Bets on the future of development teams’ organization
There is a huge pool of companies for which a hybrid model proves the most beneficial. Everything has a trade-off, but having both in-house and external teams can help in balancing factors like cost, flexibility, expertise, time to market, and operational overload.
The future will make us more risk-averse, which will put pressure on companies to be open to both models at the same time. Having two options instead of one typically helps us reduce the risk.
Want to be a part of the Disruption Insights series? Shoot me an email at: paulina.burzawa@netguru.com
Read the first post from this series and more:
- "Build Rapport and Treat Direct Reports Like a Sparring Partner" with Rodrigo Souto from CLARK
- "Promote a Quality Mindset Among Engineers" with Jenny Warnke from Delivery Hero
- "Pay Attention to Data Maturity" with Alexandre Lenoir from Spendes