Autonomy, Mastery, and Purpose does not imply Language/Framework Debt
One of the challenges in organizing development at software companies is how much freedom to provide in the choice of tools and languages. There is a widely held belief within software development companies that if every developer chooses their own language and tools, you quickly produce mountains of code that are maintained by a single system-critical developer in a language nobody else in the team has experience in. This article is how we partly challenge those assumptions.
Every software development organization strives to keep its developers happy, engaged and motivated. You could use the carrot and stick (Amazon!), but Dan Pink has argued persuasively for the carrot: people are happiest and most productive when you given them “Autonomy, Mastery, and Purpose”. For developers, this often interpreted as letting them use the tools they want and follow their own way of working.
Stop Worrying and Love the Language/Framework Debt
There is often an assumption that you must have mastery before you can program in a language or develop using a framework. Malcom Gladwell must take part of the blame for his massively popular book, Outliers, where he claimed you needed 10,000 hours of practice to be an expert in any given skill. But if you follow the old adage of “the right tool for the job”, and you build a complex enough platform, and you give teams technical autonomy, you invariably end up with a bunch of frameworks and languages to support.
But eventually, it will come back to bite you, right? Lots of languages/frameworks is technical debt on a Greek tragedy scale, right? No! You don’t need to pay that language/framework debt if you have no team turnover. There may occasionally be individual turnover, but if you can maintain the teams and they still have “Autonomy, Mastery, and Purpose”, you can expect lower turnover in staff. That, and generous shares/options should keep you from ever having to pay down that language/framework debt.