One caveat: The usability of self-service tools is of absolutely paramount importance! There are few things worse as a dev than needing some piece you’re not allowed to write yourself (as it’s — likely rightly — been determined to be a specialist activity) and having the tools provided being a nest of RTFM vipers. At least common cases need to be trivial for folks who are not in a specialized system domain on a daily basis.
Is this transformation inevitable? Going from no specialist teams to specialist team and then to self-serve tooling once specialist team is overloaded?
Building self-serve tool might be considered wasteful at the start of the specialist team, but might be good with some hindsight?
Depends on how far in The Forest you are. Someone on a team building features would need to see the need for self service and sacrifice/invest the time to build and evangelize it.
I'm experiencing this firsthand! Our team is working on the idea of "balance in the roadmap", ensuring that Product, Customer Success, Sales, and Development each have a fair share of the roadmap pie. Every month (or whenever it feels right to), we review whether our Roadmap Now and Next states are balanced. If they aren’t, we decide if it needs changing (#agile?).
To address overhead tasks (or "unplanned work", if you like the phoenix project lingo), we treat self-service tools like roadmap features. This approach helps everyone understand the knock on effects to the other work and the longer term benefits to everyone.
We've been working on a similar visual approach in the scope of Org Topologies, please take a look at: https://orgtopologies.com/. We've just released a Primer depicting more details of the method.
One caveat: The usability of self-service tools is of absolutely paramount importance! There are few things worse as a dev than needing some piece you’re not allowed to write yourself (as it’s — likely rightly — been determined to be a specialist activity) and having the tools provided being a nest of RTFM vipers. At least common cases need to be trivial for folks who are not in a specialized system domain on a daily basis.
Is this transformation inevitable? Going from no specialist teams to specialist team and then to self-serve tooling once specialist team is overloaded?
Building self-serve tool might be considered wasteful at the start of the specialist team, but might be good with some hindsight?
Depends on how far in The Forest you are. Someone on a team building features would need to see the need for self service and sacrifice/invest the time to build and evangelize it.
I'm experiencing this firsthand! Our team is working on the idea of "balance in the roadmap", ensuring that Product, Customer Success, Sales, and Development each have a fair share of the roadmap pie. Every month (or whenever it feels right to), we review whether our Roadmap Now and Next states are balanced. If they aren’t, we decide if it needs changing (#agile?).
To address overhead tasks (or "unplanned work", if you like the phoenix project lingo), we treat self-service tools like roadmap features. This approach helps everyone understand the knock on effects to the other work and the longer term benefits to everyone.
Hi Kent!
We've been working on a similar visual approach in the scope of Org Topologies, please take a look at: https://orgtopologies.com/. We've just released a Primer depicting more details of the method.
Shouldn't sincerely cross-functional teams embed the specialists rather than have an external dependency on them? Is that just an Utopian concept?
I’m talking about how to break that dependency. The software must be secure at some scale.
Nice post. Could Gen Ai be a good tool to create the self service capability?
Maybe? Try it!