Do you have innovation debt? What happens when companies do not invest in their developers
Surely you’ve heard of the term Technical Debt something you incur when you don’t invest in a clean code basis from the very start. With time, hastily pounded out code becomes more and more complex and difficult to maintain, it no longer scales, etc., such that costs escalate disproportionately.
Technology evangelist and Github trainer Peter Bell has drawn an interesting analogy between these technical debts and the innovation debt of a company: Just like you buy more and more disadvantages with time if you don’t invest in a clean code basis, a company will acquire more and more issues if it doesn’t invest in its developers.
Maybe you already know this: Your team is so busy preparing all the top features for a super app on a tight schedule that it doesn’t have the space or time to learn more about current developments in languages, frameworks, libraries or tools. Bell argues: Just like a bad code basis becomes a money burning machine in the long-term, unavailable free space and lack of training turns a productive development team into troops which are no longer in a position to properly maintain the in-house legacy application. Innovation debt becomes very expensive for a company:
- The best developers will run away
- It will become more difficult to find new forces
- Team productivity will drop
- The software will become more and more stale
Get out of debt!
How can companies avoid this innovation debt mountain? Bell suggests that components for continued training should be anchored in the corporate structure:
- Once a month, a team member has a morning available to attack something interesting. The results would then be presented in a team meeting.
- All developers should participate in at least one conference per year.
- Introduce hackathons in which once or twice a year, the team works on a project which promotes corporate goals. And at best with the requirement that a new technology needs to be tested.
- Include external consultants on a regular basis, which can open new horizons.
Aside from including external knowledge sources, pair programming is a good method of sharing know-how and raising the level of the team at the same time!
Bell leaves what is probably most important for last: Incorporate failure in your calculations. This is because trying out new technologies does not always necessarily lead to direct success. In the long-term, invaluable learning effects can appear as to which technologies are better suited for certain purposes. And the fact that a failure will not necessarily be followed by a lecture is an experience that will exponentially increase the desire for innovation in the team!
What does your day-to-day work look like? What innovation debts have you accrued in your job? And what is more interesting: How does your company go about avoiding such innovation debt in the first place?