More hats, hopefully pointing the same way

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.

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. And I'm not sure about the team size of just three people. But I like the direction they're in.

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, 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 the team that knows more about security and can help the team raise the 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.

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 that'd be really inefficient, but I think we could lose some of the alignment maintenance procedures if we made it a part of some roles.

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.

Product, a new hat. Security, an older hat. Depending on your context maybe Reliability is another hat.

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?