Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Technical Decision Making for Teams

Technical Decision Making for Teams

Juan Pablo shares lessons learned while implementing technical RFCs as a management tool in different sized organizations, going as far back as his first experiments delegating technical decision making while increasing visibility and take advantage of knowledge sharing for a 15-person distributed engineering team formed in less than a year. One year (and 10 new members) later, the team had produced about 60+ technical RFCs that were also used as onboarding material, documentation, and most importantly, interface design aids.

D7f0df31a2e02ffbb0e6a77b8099035c?s=128

Juan Pablo Buriticá

June 26, 2017
Tweet

Transcript

  1. Technical decision making for teams the open source way -

    @buritica
  2. None
  3. I CONTEXT

  4. The Dashboard Tragedy A screenplay by Juan Pablo Buriticá

  5. TECH STARTUP - NYC The CEO of a young ridesharing

    company finds itself with the need of gathering DATA for a investors and its board. A member of the EXECUTIVE team hires a DATA SCIENTIST for this task, and then hands off relationship the relationship to the new VP of Engineering to make happen. DATA SCIENTIST I need servers, I must build a data warehouse like no one has ever seen. We’ll use Pig, Cassandra, Dynamo, Redshift and this data will be BIG! VP OF ENGINEERING I have been told you’re quite the expert, I imagine you will be running all of this yourself? DS (gasps) No! You must provide me with my resources! VP Meet Nondescript Engineer, they’ll help you setup whatever you need.
  6. time passes by like in the most agile of shops

  7. a demo dashboard appears in the conference room hdtv

  8. the CEO approves

  9. a frontend engineer gets their hands on the source code

    ...
  10. A VIDEO CONFERENCE CALL - THE CLOUD After looking through

    the source code of the example dashboard, the frontend engineer complains in the private channel about his findings. The team requests an urgent team meeting with the VP OF ENGINEERING FRONTEND ENGINEER Did you know this was written in React??? VP OF ENGINEERING No, I did not. FE (rolling their eyes) Well, let us know when it's rewritten in Ember VP (hangs up call and withdraws to open office desk to meditate)
  11. None
  12. EVERY LINE OF CODE IS A DECISION MADE ON BEHALF

    OF SOMEONE ELSE
  13. My job: to enable my org to make the best

    decisions possible with the limited information available
  14. This was a process failure

  15. Process is the product I "ship" to enable my team

  16. MY PROCESS REQUIREMENTS

  17. CTO doesn't stand for Chief Technical Officer

  18. Managers don't always have all answers, nor should they dictate

    technical decisions to team
  19. Teams are ephemeral

  20. Experts have availability limitations

  21. Risk should be manageable and visible

  22. Everyone affected should have a space for input ...

  23. ... without making it design by committee

  24. It should encourage responsibility

  25. Allow for different levels of experience to come together

  26. It should be welcoming for jr. folk

  27. Promotes knowledge sharing

  28. Increases visibility

  29. Serves as snapshot of context

  30. Helps balance between upfront design and fast iterations

  31. Doesn't get in the way

  32. Asynchronous

  33. SEARCHING FOR SOLUTIONS IN THE WILD

  34. ARPANET 1969

  35. None
  36. EmberJS - Present day

  37. None
  38. None
  39. THE RESULTING IMPLEMENTATION

  40. It all begins with the need to engineer something

  41. Should we write an RFC?

  42. Caution: this is very subjective and no formula has worked

  43. Are you building from scratch? new endpoint, component, system, library,

    etc
  44. Write an RFC

  45. Does this involve more than one system or team?

  46. RFCs are great for drafting contracts

  47. Are you adding a new dependency?

  48. Write an RFC

  49. If you have to ask, you should probably write one

  50. Next: Write the RFC

  51. None
  52. None
  53. None
  54. Submit your proposal

  55. None
  56. Set a reasonable approval deadline This has also proven to

    be tricky and subjective, ugh
  57. Encourage discussion

  58. None
  59. Managers beware. You must set expectations on civil conflict

  60. Crush all aggressions, passive or active

  61. Remind team to assume good intent

  62. Written text has no tone, sometimes you must mediate in

    calls
  63. Give insecure participants a boost for example, anyone can prefix

    comments with [newbie]
  64. Promote trust

  65. Let low risk mistakes happen

  66. Process approval or rejection (the science on this is not

    in yet either)
  67. Clearly designate approver

  68. Another option is implicit approval

  69. None
  70. Implement

  71. May happen before approval if risk is low enough

  72. Deviations from original proposals should make it back to document

  73. Archive

  74. None
  75. Maintain

  76. Any contract updates should be made against original proposal

  77. Conclusions

  78. A note on tooling

  79. Use whatever gets out of the way for those involved

    in process
  80. Local context is more important than random mgt advice

  81. If I help engineers make the decisions I hired them

    for, the team becomes stronger* and we write better* software together
  82. *science is not in yet

  83. None
  84. THANKS! Questions -> @buritica