People build systems. The systems we have are the result of thousands of tiny decisions over time. Better decisions should turn into better systems. Right?
Earlier this year, I was upset with myself because I couldn’t drive a conversation into a sound technical decision. I knew that the final decision would introduce inefficiencies in the form of a future back and forth with customers and external stakeholders. We could avoid all of that on the get-go with minimal code changes. But I failed in communicating effectively.
We picked a project to address substantial tech debt. In the grand scheme of things, we were addressing the root problem was a significant win already. But I was stuck on the details of a technical decision. The decision was inefficient, but it was inconsequential. We would address it as soon as we received external feedback.
Why was I upset? I guess it’s painful to see inefficiencies and to let go. Important lesson: don’t lose track of the big picture. Let go of small battles. A team will become stronger by learning about the inefficiencies themselves rather than “blindly” following others’ suggestions. There is an interpersonal relationship aspect to this story but let’s table that for now.
Lesson 1. Let things fail
This scenario also got me thinking: “This doesn’t scale. No one can be part of every project or every decision”. Decisions should be pushed to the teams closest to the problems anyway. More often than not, they know better than anyone else. Even when they could be wrong, mistakes are opportunities to learn and grow.
Lesson 2. Systems are a reflection of our decision making
I started reflecting on the quality of our systems and their architecture. Our newer systems are in better shape overall, while the older ones suffered from outdated design choices. The next insight was: “Our systems are the sum of technical decisions made over time.” If we can improve our decision-making, we can improve our systems’ health and the health of the individuals in a team – who wants to work on bad systems after all?
The average technical decision of the average engineer is probably a good proxy to measure systems’ health. If you only trust your most senior engineers or top performers or the best title in the room, your systems aren’t probably in good shape. The next question that popped into my head was: “how can making good decisions become easier than making bad decisions?”.
Lesson 3. Architect the environment, not the system
At that point, the next insight was: “My job (as Staff Engineer) isn’t to make technical decisions, but to create the conditions so that teams can make good technical decisions”. Technical leaders create space for individuals to make mistakes and learn from them. Technical leaders also provide context and tools for teams to make informed decisions.
The answer is simple but harder in practice: focus on the environment.
Final Thoughts
Good technical decisions turn into better systems. Better systems turn into happier teams and vice versa. Happier teams and better systems turn into happier customers. They are all connected. The key is building rituals that improve the quality of technical decisions overtime. The rituals become your system.