Reflections on Week 3 at RV Tech

We had an incident this week. The team met to talk it through, but the meeting stayed on the incident itself; the idea of a Datadog dashboard never came up. After it ended, my mentor went and built one that captures the events when we get a spike of errors, and shared it with the team. That isn’t even his role, he’s not a DevOps engineer. He just saw something that would help and built it. That is when I truly understood what the Amazon Leadership Principle “Bias for Action” means.

My own week was the counterexample. After I got the first round of feedback on my design doc, I went back and refined it. At that point I could have created the Jira issues from what we already agreed on and started implementing. Instead I wanted to share the doc again, host another meeting, go over every detail, and only then start. A better move (what other engineers on our team do) is to create the Jira issue, post it in Slack, tag someone for feedback, and start building while the feedback comes in.

I think I was afraid the design doc or the Jira issue might contain errors. But the worst case is not that bad. If the doc is wrong, I fix it and start over. I have lost a little time, but by then I have already started implementing, so I have learned some details I wouldn’t have known otherwise. And most importantly, no other team member’s work is affected. A lot of details don’t show up until you start implementing anyway, so there is no point waiting for a perfect design doc. Implementation is cheap now with AI, which makes the cost of being wrong even smaller.