What was your mission at talpasolutions? How did you notice there was technical debt?
Talpasolutions guides their partners through digitalization by providing analytical insights and industrial intelligence, as well as fostering an ecosystem of machine manufacturers, operators and service providers.
I was hired to solve the problem of technical debt. This did not only include the technology and the product, but also the teams and organizational structure. Talpasolutions was working mainly at the level of Minimum Viable Products (MVPs) and trying to collect the most valuable use cases around which to provide a unified product.
The management team already had an intuition that the teams could be more effective at evolving the product further. There was a strong commitment to devote resources to redesigning the data pipeline according to state-of-the-art concepts of microservice architectures, cloud-native, infrastructure as code. We also needed better data governance
What is technical debt and where does it come from?
Starting a new business is very challenging, and one of the biggest challenges is to find somebody that is willing to finance it. Finding funds for pure research is hard. The only way is to develop an MVP with very little resources and validate your value hypothesis.
You don’t have any other choice other than accepting risks inherent in developing in fast iterations. That is because whoever gave you the money wants fast results.
These are the rules of the game with early product development.
Technical debt originates from the many compromises and things you are willing to sacrifice in order to develop quickly. You need very good intuition and experience to know what can give you troubles and what you can tolerate.
When does technical debt become a problem?
All the corners that we have cut are going to pose problems of various types, such as complexity of maintaining the code and evolving it.
Complexity of maintaining the code
- Quality is often sacrificed in favor of speed. Poor quality code is much harder to maintain.
- Knowledge sharing and documentation are often sacrificed, so knowledge resides in maybe one person’s head. This is often one of the first corners that get cut.
Evolving the code
- Sometimes you have cut so many corners, there is no way to evolve the code. You have to start from the beginning.
- Sometimes the value hypothesis validation gives unexpected results and that makes the code that you have developed less relevant.
The real problems arise when the product gains traction and you don’t do anything about the things that we have described, because they are going to bite you back.
What is the biggest mistake companies make handling their technical debt?
If they don’t identify early enough the point when they have to stop sacrificing code quality for development speed. After a certain point, you should not take on the additional risk of technical debt, because it doesn’t pay off in the long-term.
You accept this risk in the early stages of the company, because everything is short-term. Once you reach the level of maturity that obligates you to develop a long-term strategy, deprioritizing quality has a very low reward/risk ratio.
Why is not doing anything about the original tech debt so bad?
It is like the deadly sin of sloth.
The sin of sloth is that you have some talents and you don’t do anything with that. The sin of sloth is a waste of an opportunity.
At some point in a start-up’s life, technical debt is a waste of an opportunity. You waste the opportunity to invest time and money in productive activities. It’s bad because it is not only very costly, but those costs keep increasing. You pay an interest in those costs in the form of time you have to spend managing the technical debt. This time is taken away from R&D and other productive tasks.
Tech debt sloth also breeds a culture of unstructured and sloppy operations.
What should be the first steps in tackling technical debt?
There is a technical component and a people management component. You can’t solve the former if you have not solved the latter.
You need to establish the importance of quality within your teams. After that you can start identifying the biggest pain points, which normally are at the infrastructure level. It’s a mechanistic consequence of developing with a short time horizon.
When you can’t afford developing a long-term strategy, core infrastructural development suffers the most.
What challenges did you face in your role at Talpasolutions?
The first challenge was to give structure to the team and to establish domains of expertise within the team, also improve data governance.
The next challenge was to build a strategy for core infrastructure development, which for us meant a big data and analytics pipeline. The hard part is to align the tech strategy with the product strategy and explain the challenges to non-tech stakeholders.
What continues to be a challenge?
Finding and prioritizing things on the tech side that can bring business value to the company. Business value can be in terms of growth, tools that enable better workflows, many things.
Which manifestations of sloth are important to avoid, even in early stages of a company? Why?
Only cut the corners that you really need to cut.
Make things as simple as possible, but not simpler. Don’t become naive in trying to reduce complexity. There is an inherent level of complexity in the problem that you are facing that you can’t get rid of.
To add value, you have to solve the inherent complexity of the problem. Otherwise everything can become so simple that it is not interesting anymore.
What are some top learning from this experience?
Your prioritization needs to change fundamentally when you build a long term strategy.
Building a product goes through different stages. There is a creative stage and then an execution stage and the way you manage these stages are completely different.
Sometimes in-house technology performs better than open source, but it is costly to develop and you need a clear long-term strategy.
Who is Daniele Marmiroli?
Daniele is VP of Tech at Talpasolutions, the Essen-based analytics company delivering analytical insights and intelligence to the heavy industry and building a community of operators, manufacturers and service providers. Dan is outcome-oriented and resolute, he has a visceral passion for building and leading teams of talented individuals and for making an impact in the world using data, code and science. He is an advocate for investing heavily in AI research and confident that broadening our understanding of the field will improve people’s lives. Dan left his academic research career in 2014 in favour of finance and since 2017 he focuses on bringing deep tech startups to thrive and succeed
