Motivation
I’ve recently read some interesting articles on how technology teams can be organised, and how closely observing product usage can help companies realise what pain points customers have with their products and how to solve them. Some of the techniques are listed below.
Organising teams to be autonomous
Having more than one team and needing them to interact with each other introduces friction. This friction kills motivation, momentum and speed.
This is where we can remove dependencies between teams by introducing autonomous product teams, so no cause for friction. This requires a team to be cross-sectional by nature, equally skilled in the customer, technology and the business. You may model two employees as blue and green in the diagram below.
At the end of the day, your team is smarter than you (the manager) are, it has more information than you do, it is closer to the problem than you are, and closer to the customer than you are. So why are you telling your team what to do?
Providing autonomy motivates people intrinsically by building them up, trusting them and allowing them to drive decision making - a bottom up approach. This is backed up by Daniel H. Pink in his book Drive and TED talk, who uses scientific research to show that once companies pay us enough, we are motivated by Autonomy, Mastery and Purpose.
High quality observability
The team at Wise describe in the above article how they knew customers wanted to send USD to Asia by observing how they were using their product. They noticed how customers were consistently trying to create transfers to countries that were not supported.
The first step would be to make sure your product can capture and accurately provide this information in the first place. Putting the future of the product first when creating services is also key. Then it would be about getting buy-in from internal stakeholders that this needs created, what it might cost, what the upside may be etc.
Developer product responsibilities
There is a need for engineers to work in a cross functional way, to have a real interest in the product being built. Whilst you are developing, researching, user testing, you must be able to stop and ask why are you being asked to write it in the first place, and have a real opinion on the product.
This means defining the solution well before you start writing code. How can you create something exceptional if you don’t have a clear idea of what the solution should do? What kind of motivation does it provide developers if you are just a code monkey and don’t actually understand where your contribution is being made.