All teams I've been in and talked to have thrown around Big Ideas that would do something amazing for their customers or fundamentally remove very difficult development impediments. These are the water-cooler talks of how amazing it'd be if we did X or tried out Y. Maybe it's a new architecture (to speed up processing), or breaking a monolith into services (to make changes faster), or removing manual processes (to deploy faster and thus learn faster)… but whatever the specific ideas are, they are Big Ideas a team feels would be amazing to achieve but they are too big and vague to fit into a product backlog. And too often I see these ideas go exactly nowhere.

Instead a team may commit to one safe idea after another, the kind of ideas that are reasonably possible given the team's current context, because that's all very practical. I don't mean the team is rudely silenced by some evil External Stakeholder (that'd be a whole different blogpost to write), what I'm referring to is the team somehow decides to not even discuss their amazing Big Ideas. Maybe there's no room to bring up vague-but-important ideas that don't quite fit the roadmap, or don't fit the architecture, or aren't readily doable within the day-to-day work, and so the team self-dismisses their own ideas with "oh well" and "they'd never let us work on it anyway".

But such responses are learned helplessness, and if we only settle for solutions that fit within our current framework we can be forever doomed to deliver simple, iterative improvements without producing anything groundbreaking. It's a recipe for sucking out ambition and driving down engagement (in both customers and developers). At its worst developers stop talking about their ideas because "what's the point, nothing changes anyway", and that is a real goddamn shame.

At this point I think it's fair to call out I am writing this from the point of view of being a programmer, so my angle is an engineering context where helping the customer has many dimensions to it, including improving the developer experience because that lets us deliver customer-facing changes faster. So I'm intentionally blurring the lines of what a "Big Idea" targets to be inclusive of whatever it is developers bring up when left alone. Those ideas might be customer-facing, but it's also valuable to hear thoughts on new architectures, or vastly improved testing, or any of a number of non-functional capabilities.

By definition a Big Idea exists in a kind of Goldilocks zone: Neither too big, nor too small. I've always found teams have such ideas that promises to supercharge the product by offering an awesome feature or by removing some massive impediments. And because developers are practical people those ideas tend to be quite surprisingly tractable. A Big Idea isn't some pie-in-the-sky sci-fi dream (because that'd be too vague to discuss at the water-cooler), nor is it so small it fits as a normal backlog-project (because then it'd already be prioritized). It's in that middle-ground where it promises to fundamentally dissolve some big and immediate challenges and obstacles, but it does so by challenging fundamental decisions or core assumptions. And it isn't so aligned to the product strategy that it's already being handled by the normal product-improvement work.

If you have those ideas floating around I'm simply suggesting they deserve to be discussed! They deserve to be brought into some sort of process that can conclude with a commitment to making them real. I mean, what are the odds a group of highly skilled professionals would align on a terrible suggestion? Personally, I'd be very happy to put Big Ideas on a wall somewhere and regularly bring them up for discussion, to see if there's one idea in particular that really excites the team. If such an idea is identified I think chances are good it's worth investing into.

There's just tremendous potential in at least discussing these Big Ideas, and I hope you get to execute on them too.

Photo by Patrick Tomasso on Unsplash