Getting big things done by being clear about what they are

This resource first appeared in issue #48 on 30 Oct 2020 and has tags Managing A Team: Documentation/Writing, Technical Leadership: Other

Getting Big Things Done - Marc Brooker
Architecture Decision Records - Upmo

Brooker, who leads development on AWS’s Lambda product, writes about his approach to getting big things done and done well; his approach is outlined below:

• Is it the right solution?
• Is it the right problem?
• Engage with the doubters, but don’t let them get you down
• Meet the stakeholders where they are
• Build team(s)
  • The builders
  • The stakeholders
• Be willing to adapt

This maps pretty straightforwardly to research computing work too.

Key to Brooker’s approach, I think, is the centrality of writing a document in the early stages, both for communicating the problem and proposed solution to others (and having something concrete for them to give feedback on), but also to clarify his own thoughts and realize where gaps or problems lie.

This lines up even with smaller decisions; we’ve talked about architecture decision records before as a way both to flesh out an idea and communicate it, both in the present and to the future (“here’s why we did it this way - the tradeoffs and constraints we faced”) so that future knows the why’s and so therefore when it would be worth revisiting.