Engineering leadership knowledge and tips straight to your inbox?

Scaling Engineering Teams via Writing Things Down and Sharing – aka RFCs

By John Lafleur 3 minutes read

TL;DR: Writing things down is still an undervalued skill in the software engineering field, while it can align incentives (titles and compensation) and help scale the organization. This engineering leader at Uber addresses this issue often during his talks. Here is a great article summarizing how they do it at Uber.

  • Do planning before building something new.
  • Capture this plan in a short, written document.
  • Have a few, select people approve this plan before starting work.
  • Send this planning document out to all engineers in the company and let anyone and everyone comment on it.
  • Have everyone follow the above steps for every project that is beyond some super trivial complexity and iterate on a lightweight, RFC-like process so it works well for your org or company.

“Writing and sharing that writing with others creates accountability. It also almost always leads to more thorough decisions. A simple way to increase code quality? Do code review in writing, before merging. A simple way to have a meeting be less of a waste of time? Have a written agenda before the meeting, then write up and send out decisions and actions afterwards. A simple way to run projects with fewer surprises? Have the team write down what they are planning to do and share it with others.”

The power of writing things down

  • If everyone agrees how the project should be done then writing the approach down should be a piece of cake.
  • What about when people don’t agree with how the project should be done or there are just a lot of changes? That already sounds like a project that will take a lot longer than people think – writing down things at least should give a clearer picture.

Reviewers and spreading knowledge across the organization

  • The type of information pushed to people in an organization shapes the culture considerably.
  • Having an organization with a culture to push engineering plans to everyone – for example, via email – and invite anyone to comment sets a tone of trust and responsibility.
  • Allowing anyone and everyone to chime in is a key part of keeping a consistent engineering bar across the organization

Tailoring the process via iteration

  • An interesting part of the iteration I’ve seen is the evolution of templates. People who review many engineering proposals often had the same type of questions. Questions like “What is the motivation to do this work?” or “How will this be tested?” or “Will any archtiecture changes be made here?” were very common questions.
  • Iterating and customizing to the needs of the engineering team is key. In our case, the templates started to include important things we cared about. Things like reliability, scale, security.

A process that scales

  • At Uber, we called this process RFC – Request for Comments, given the many similarities it has with the Request For Comments publication process in the tech community.
  • One of the things that will help engineering scale greatly is having a type of RFC process in place early on. Just give it a try and iterate on how you do it. That’s how it always starts.


READ THE FULL BLOG POST

Want engineering leadership and productivity tips?

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.
-->
%d bloggers like this: