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.

Transcript

1. Technical decision making for teams the open source way - @buritica
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)
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
36. EmberJS - Present day
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
54. Submit your proposal
56. Set a reasonable approval deadline This has also proven to be tricky and subjective, ugh
57. Encourage discussion
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
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
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
84. THANKS! Questions -> @buritica