The development team at my company grew considerably in the past year or so. One of the consequences of that change was the way we work. With a small team, you can make decision together without much overhead. With a bigger team though, we ended up breaking up into smaller, nimbler units for speed of decision and delivery.

Putting aside my feelings towards this change, my biggest concern was learning. With a group of 4-5 people deciding over an issue, I always felt interesting points were raised and everyone knew more by the end. Someone makes a suggestion, someone else shares their experience with it, another person tweaks the idea, and by the end we reach a good compromise. Besides that, we all learned something new, either technical or how someone thinks.

Unfortunately, I think this gets lost when you break into smaller teams (2-3 people). You have to develop processes to reflect over the decisions you took as an autonomous unit and bring that knowledge back into the larger team, so that every developer benefits from it.

Retros could be the place for this, but they can have other people besides developers to whom technical decisions are not relevant. My suggestion then is to have a decision journal where you (individually or as a team) record the paths you had to pick to address certain issues.

You can keep this personal (write down your own decisions) or team-wide (record team picks), the goal is to go back and reflect on these decisions whenever it’s time. Maybe at the end of a project or before deciding to roll something out to the larger team. The goal of this journal is to provide you with a truthful reflection of decision points so you can learn from them.

Developing features by itself won’t make you a better developer, it’s the careful consideration over them (and sometimes some temporal distance) that will bring you insights. I’m a fan of autonomous teams when I know they have ways of reflecting on what they did and they make an effort to share their learnings.