Don’t let fear of feedback undermine your technical design

Let’s begin with a hypothetical scenario: You’ve spent the last two weeks perfecting your pitch. You’ve thought through every possible objection anyone might have to your plan.

You’ve carefully justified your choice of programming language and why you just need to use a complex gossip protocol to build the system – it is theoretically the “best” language, but it’ll be tricky to get right (and yet really fun to build). You arrange the meeting and present your plan at the altar of the architect. They’re distracted and don’t fully follow what you’re talking about. You avoid a grilling and walk out with the “sign-off” you came for. You got through it! You get to move on to the fun part. You have sign-off. You start building.

The months pass and the project starts to falter. Questions are asked: is this really the best approach? You have sign-off, though. You stay the course.

More time passes and it’s still not live. Priorities shift and you move on to something else. The code you’ve spent so much time on never ships. Months of time and effort have come to nothing. You had sign-off, though. It’s not your fault.

Fear of feedback

We try to merely survive getting feedback on our work instead of embracing it.

This is a dispiritingly common scenario, and it has one major cause: fear. We’re all a little bit reluctant to get feedback on our work and we’re even more reluctant to seek it out when it’s most useful: early on, before any biases towards a particular solution have set in, before we’ve already invested a ton of time into our preferred approach.

We can feel like it’s our job to lock ourselves away and come out with something that’s fully formed. We want to know we can do it on our own. We could go ask other people, but would that mean we’re not able to do the job?

We abstractly know that feedback is supposed to be a positive thing, but in reality our egos are fragile. We try to merely survive getting feedback on our work instead of embracing it wholeheartedly as an opportunity to make things better.

Favor collaboration over sign-off

The idea of carefully preparing something and submitting it for approval and sign-off immediately puts people in the wrong mindset: if they get feedback, with suggestions to change things, then they’ve failed. So they carefully argue, persuade and politic to get people bought-in to their approach and to smooth over any feedback on it.

Then, when sign-off is given, it can encourage the antithesis of ownership. It can allow for an abdication of responsibility, a way to pass the blame. It offers an excuse to ignore useful pieces of feedback via an appeal to authority.

Instead of submitting your work for review, afraid of the amount of feedback you’re going to get, embrace the process and seek out the opinions of those who will give you the most feedback from day one. Brainstorm potential solutions with them. Agree a best course of action. Keep them up to date as your thinking evolves. Favor collaboration over sign-off.

Owning something means being responsible for ensuring a good outcome.

Owning something means being responsible for ensuring a good outcome. It doesn’t necessarily mean having all of the ideas yourself, having all of the answers yourself or doing all of the work yourself. To own the best possible outcome of any project means using input from wherever you can get it, rather than trying to get it all done without help.

Our technical design process

We’ve intentionally structured our technical design process to encourage collaboration and early feedback and shied away from introducing a “sign-off” step.

We also explicitly call out that the individual engineer owns the technical design process for their own projects. This doesn’t mean that they need to have all of the answers. Instead, it means that at an early stage they should proactively seek out engineers to collaborate with and get feedback from, to get the best possible outcomes for their projects.

Here’s what our process looks like:

1. Assemble a working group of other engineers to help you with your design.
   Get the right set of engineers collaborating from the very beginning of the process when it’s easy to shape the design, rather than a formal design review and sign-off at the very end when it is no longer easy to alter the design.
2. Collaborate with your working group in front of a whiteboard.
   Collaborating early in front of a whiteboard is a quick way to narrow in on a possible set of solutions and is critical to avoid solution bias.
3. Write/update your documentation.
   Writing a document to precisely describe a technical approach in detail will force you to consider edge cases and will prevent you from hand waving over the key issues.
4. Iterate repeatedly through steps 2 and 3.
   Repeated attempts to communicate and collaborate your plan, both in person and in writing, will help you to achieve clarity and zero in on the best solution.

Own your technical design…to the end

Though we know it’s extremely valuable, we all fear feedback on our work. Seeking to collaborate early with other people can make it less daunting.

Our technical design process favors collaboration over sign-off to encourage our engineers to really own their projects and to seek feedback to make sure they’re successful.

By prioritizing collaboration in this way, we make sure that engineers don’t pass responsibility for their technical design to a higher authority in the form of “sign-off”. Instead, it ensures they own that technical design, and the project as a whole, to the end.

If you’re interested in working with a collaborative process that embraces and values feedback like this, join us. We’re hiring.