@adlrocha - Establishing a Team Ideas Democracy

Generating ideas owned by the full team and not by individuals

I was in my yearly performance evaluation, a moment feared by many and to which others give no importance at all. It was time to collect some feedback about my work, and plan for the year ahead. I remember thinking, “it’s been a great year, we’ve achieved what we've set out to do and more, so there shouldn’t be any surprises”. Wrong! Actually, the feedback I received that day really opened my eyes.

We were a product-oriented R&D team, so what was expected from us was to ship a product able to generate value in the short term, but with an ambitious and innovative goal in the long run. This meant a constant flow of ideas between the operational team, in charge of scaling the product; the development team, responsible for shipping the new features and ideas tested in research; and the research team, exploring the uncertain long term landscape. So far so good. We were a well oiled team that got along great personally and was achieving amazing things professionally. Or so I thought. There was actually something that was creating friction within the team, a black cloud I wasn’t able to see until I received that specific feedback from my manager.

Ideas are worthless but they matter

I am among those that think that ideas alone are worthless (I already discussed it in this publication). I thought that what really mattered about ideas were their execution within a clear vision and mission. Albeit useless, ideas were being the source of friction in our A-team. That is what my boss conveyed to me in that conversation. A conversation that really opened my eyes. His statement was something along these lines:

“Look, I know you are all achieving amazing things. And the work you are doing is outstanding, but we have an issue. The team is losing their motivation, and part of that is because they don’t feel as valid owners of the product. Research is being the constant source of new ideas, and they feel like mere executors. They joined this team in order to be involved in the development of an innovative product, and consequently they want to be part of the idea generation and innovation process. If they would just wanted to be plain software engineers they would have joined one of our deployment teams. We need a way to involve everyone in the ideation process.” 

Usually the source of new ideas was the research team, not because we were smarter or more creative, but because while the development team was focused on developing new features, and the operational team on scaling our product, we were focused on the long term. Our flow of work was as follows: we received feedback from devs and ops about their most pressing problems, and in order not to bother them with our “crazy ideas” (which may end up not working and become a distraction), we usually brainstormed and tested our ideas before sharing them. We were keeping our work in the low until “it worked”. What this was causing was the feeling that the research team was “the owners of the innovation”, and devs and ops were only there to serve them. They didn’t feel part of the “innovation and idea generation process”.

Establishing a democracy through brainwriting

The reason why my boss shared this feedback with me and not with anyone else in the team was because I was the one more involved in the research efforts of the team. Fortunately, by being one of the roots of the problem I had more tools than anyone to solve it. I spent the next few weeks observing how our team was operating just to realize that the feedback was more than accurate. We had become an “idea dictatorship”. It was as if the only ones entitled to propose new ideas was the research team. And it wasn’t that the ideas were bad, that things weren’t working, or that we weren’t achieving our goals, but that it was affecting the team’s dynamics, motivation and morale, and it was something we couldn’t afford.

I started reading a lot about brainstorming, idea generation, and what people like to call now “ownership”, until I came across what seemed like a suitable solution to our problems, “brainwriting”. Brainwriting is like brainstorming but instead of everyone shouting out loud their ideas, they write them in a piece of paper before sharing them with the team. I chose to adapt brainwriting to establish what we liked to call “an idea democracy”. The process I came up with consisted of the following phases:

  • Phase 0 - Choosing the problem: The first thing we did was to establish an “open problems backlog”. Every time members of the team faced a technical problem or issue that they felt required an idea generation session, they would add it to this “open problem backlog”. Every two weeks (at the end of the previous session), a problem from the backlog would be voted and chosen as the next candidate problem.

  • Phase 1 - Brainstorming and writing ideas: In the two weeks period between sessions, every team member, alone, would think and brainstorm potential solutions to the problem, writing down every idea they came up with. They could do this in the shower, while having a quick jog, or in their spare time. The aim of this was to allow everyone to get obsessed with the problem and come up with their own solutions without being polluted by others.

  • Phase 2 - The idea generation session: It would be divided in these three stages.

    • Stage A - Idea recollection: Everyone would come up with their own ideas. We would do a quick round where everyone had a dedicated slot to share their ideas and solutions they had come up with. At this stage no feedback was allowed. Everyone would take notes for afterwards and that’s it.

    • Stage B - Discussion: At this point we would open a discussion on the ideas presented in order to consensuate potential solutions to the open problems. This is the closest thing to traditional brainstorming we had, but with the homework done. This stage would last approximately 30 minutes.

    • Stage C - Conclusions, voting, and planning: After the discussion, someone would objectively summarize the potential solutions on the table, and a voting round would be opened so that each member could choose their preferred solution/design or the one they thought was more worthwhile to try. Depending on the results obtained, the exploration and implementation plan for the idea would be determined, and a new open problem for the next session would be voted from the “open problems backlog”. In some cases, the ideas proposed may not ended up being good enough to solve the problem and an additional idea generation session would be required (in which case no new open problem would be selected). It might also had been the case that after the exploration and implementation phase, the problem returns to the backlog, but these are the beauties of research and innovation. 

Our goal was for these sessions to last at most an hour, but we were a small team, and this might change a bit according to the team.

What we achieved

Not every individual in a team is as creative or has the domain of expertise required to come up with valid solutions to open problems, but this “standard process of idea generation” achieved several interesting things:

  • A sense of ownership of ideas for the whole team. The ideas weren’t exclusively owned by research anymore because everyone was involved in the generation process. Everyone had a chance to be heard and do their bit in finding solutions to our most pressing problems.

  • Team alignment. We all have experienced those “fights of egos” between members of a team with strong characters. This process completely removed these fights. The fact that people had their own chance to talk and discuss in the process removed the one-to-one discussions in a group brainstorming. “In most meetings with traditional brainstorming, a few people do 60-75% of the talking. With brainwriting, everyone gets a chance.”

  • And one of the reasons why we didn’t go for traditional brainstorming, “As sexy as brainstorming is, with people popping like champagne with ideas, what actually happens is when one person is talking you’re not thinking of your own ideas”. We wanted disruptive ideas popping after a good understanding of the problem, not people “opportunistically jumping in the discussion”.

This process was standardized for the idiosyncrasy of our team, and may not be a “fits-all” solution. It also may not be the most polished system for efficient idea generation and team ownership, but for us it worked like a charm, and that is why I felt it was worthwhile sharing it with my dearest audience. That being said, I would love to hear your feedback and insight about this process). See you next week!