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.
At Logical Clocks, where I work, we have more frameworks and languages in our product than developers. Our product, Hopsworks, is a data-intensive platform for developing and operating AI applications. It consists of 23 open-source services, and our code is written in: Java, Python, Javascript, C++, Ruby, Bash, and Scala. Recently, we formed an internal team to build a cloud-native version of Hopsworks, headed by Steffen Grohsschmiedt (ex-Spotify where team (aka ‘squads’) are given full autonomy), and they added to the mix the Go language and several new cloud-native and serverless frameworks. The key point here is that the decision for adding a new language and frameworks was made at the team level. Teams have full autonomy for important decisions like choice of tools. Naturally, the team has a purpose that fits into the vision of our startup — they need to buy into that, too. And each member of the team must achieve or already have mastery on the problems they are solving.
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.
