So it seems my last post wasn't the last post on this new blog after all.
Short version:
Introduce Product Champions into your teams, and maybe Reliability Champions too, to increase increase alignment. And look at shrinking your teams.
Long version
I've been thinking a bit more after a friend sent me https://www.linkedin.com/pulse/introducing-pulse-post-scrum-manifesto-ai-native-teams-hanke-tilfe which was an interesting read. I think they might be on to something, certainly it's a good first step. Just don't only put security review at the end, some security issues can only be fixed on the architectural level. Most serious reliability problems are most easily solved there as well. At first when I read this article I wasn't sure about the team size of just three, but it turns out they're onto something.
Anyway, say you implement a version of pulse that you think fits your context and after a few months you've got your team humming like a well oiled machine spinning at 18 billion rpm, you get features in prod before you've clicked send on the message. But, what to build? Why? for whom?
This is something I haven't seen nearly as much talked about, this is quite probably just my bubble but I've only seen it once, in a post by Melissa Perri. It doesn't matter how fast you're going if you're going in the wrong direction.
I think we can use tooling solve the review bottleneck that's now growing steadily. Agents help catch a lot of the small / medium stuff, leading to 3min turnaround rather than 3 hour turnaround for all of the small stuff, so when it finally reaches another person they can focus on the big picture for knowledge spreading and catching problems that requires looking ahead etc. But, I don't think there's any such silver bullet for figuring out what to build, for whom, when.
But, if you're at an established company some people there hopefully have a decent view of who you're building for, why you're building for ( Yep, I'm handwaving it away, I don't know how to solve that ) and you're probably struggling more with alignment, spreading that knowledge out to the organisation.
Overall I think agentic development code becoming faster has surfaced a core problem of any large organisation: alignment. Creating it and maintaining it. If everyone is perfectly aligned there's no need for meetings or reports or other kinds of overhead. Everyone is sprinting full speed in the same direction. Of course you run into reality where there's confusion and misunderstandings and forgetfulness etc, and then you need your procedures (weeklys, dailys, whatever format you're using) to make sure people are building the right thing.
I think that the concept of Security Champions (someone in each team that knows more about security and can help the team raise their overall level) can be expanded to Product Champions, that would help keep the team aligned with what customers need and why they need it and when etc. Everyone in the team needs to know the overall direction, but I think making developers T-shaped in a new way can make the whole organisation work smoother. Usually developers are T-shaped between e.g. frontend, backend and networking, I think we should also make them T-shaped in product, security and other aspects too.
This isn't about turning developers into Product Owners or Sales or Customer Engineers. This is a about adding another perspective into the mix to help developers make better decisions faster, which in turn helps them build better products faster with fewer meetings and documents involved. The meetings and documents are primarily to make sure everyone is working in the same direction after all. These new Champion roles is about clear responsibility and making it explicit. If a new product/design/... direction needs to be communicated, who goes to those meetings? And so on.
We're adding more hats to the developers, but I think that's a good thing. Solving specific technical problems can be fun but if we can keep an eye on what the user really needs, which as we know might have a loose correlation with what they say they need, and can help their team mates stay closer aligned with that. Not everyone likes talking to customers, not everyone should talk to customers, but I think we could lose some of the alignment maintenance procedures if we made it a part of some roles.
Another way of looking this is pushing the TDP (Tech, Design, Product) trio from leadership level down through the organisation. It's formed on the leadership level because previously only the direction was handled there, now teams need to act more independently to keep moving at speed so the direction and that means pushing awareness of the overall direction deeper down into the organisation.
Product, a new hat. Security, an older hat. Depending on your context maybe Reliability is another hat. What about Design? UX? What else could be a hat?
How much could you push down into your organisation to reduce alignment procedures and help your teams move at speed?
So, if we push more context down into the teams with new hats for everyone we can reduce the cost of alignment between teams and leadership, and if we shrink the teams we reduce the cost of alignment inside the teams I think we could start to really move.