Learn to never have a good idea

At StaffPlus this week, I was talking with some other senior technology folks about the risks that come with the weight of our opinions ("never think out loud, people will think it's an actual plan") and the sense of pressure to get it right when talking to our teams. There's one tactic I use that I realize helps with both: tell people you're sharing a bad idea, and then share a bad idea.

Staring at a blank page is intimidating whether you're writing fiction or a blog post or a design doc or a technical vision. It's much easier to edit and rewrite than it is to write from scratch. One of the things I tell myself when writing is "write the bad version" first. It doesn't have to be good, in fact it shouldn't be good, because that would mean I'm putting too much effort into editing myself instead of getting the ideas down.

The same applies when brainstorming solutions or designs. It's much easier to start picking something apart ("that won't work because...") than it is to produce a perfect solution. It's a good way to suss out the hidden requirements or constraints early, without putting in a lot of effort.

As staff+ or management, we have institutional support to be wrong, and we should use it. Rather than taking responsibility for solving every problem well, start a discussion by saying "this is a bad idea and we should not do it: what if we..." and let the rest of the team start editing and critiquing. Interrogate the issue, and encourage the folks around you to do so, too.

"Success" here means your bad idea is thrown out and the team comes up with a good idea, together. You will have helped the team arrive at a good solution, included them in the process, and modeled a low-ego approach to technical design.