I prefer to build teams that own the whole lifecycle of their work. They get involved in the design, understanding the problems of their customers. Everyone pitches in to build the solution, whether it’s describing possible features, writing the software or packaging it up to deploy.
Most importantly, the team run and operate the systems they build. There might be supporting ops teams, but if something goes really wrong, the team is on hand to fix it.
This model encourages the team to work in balance. No one behaviour is over incentivised. They are encouraged to solve problems rather than build systems for the sake of it, and they feel the pain of something being broken straight away.
Maybe it means that new features are not delivered quite as quickly as they could be if the team are just building them and having someone else manage them. However, this split model causes more dependencies. The management teams are often a bottleneck, so when things go wrong they can be harder to fix, and if it’s not an urgent issue, it may never be looked at all.
So, if you are just starting out you can drop features at pace, and if you are running them as well you can fix up what you need to immediately. You have fast feedback loops.
In bigger orgs, you move at the pace of your customers, you cut dependencies and aren’t at the mercy of an overstretched ops team.
Carrying the pager instils the philosophy of care and concern in your team, forces them to feel the pain of their users and to resolve issues when they come up.
You should then also take a turn. Leaders should also carry a pager. Maybe an escalation rather than sitting on a single rotation, but in the same way that the team feels the pain, you need to feel the pain of being on call. You make sure that you don’t let this pain get too much. An occasional page for a real issue is fine, constant noise of a system working as expected should be squashed immediately.
We should all carry the pager at some point, it’s one more way to stay connected to what’s going on!