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
   

   View Slide

2. View Slide

3. I
   CONTEXT
   

   View Slide

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

   View Slide

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.
   

   View Slide

6. time passes by like in
   the most agile of shops
   

   View Slide

7. a demo dashboard appears in
   the conference room hdtv
   

   View Slide

8. the CEO approves
   

   View Slide

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

   View Slide

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)
    

    View Slide

11. View Slide

12. EVERY LINE OF CODE IS A
    DECISION MADE ON BEHALF OF
    SOMEONE ELSE
    

    View Slide

13. My job: to enable my org to make
    the best decisions possible with
    the limited information available
    

    View Slide

14. This was a process
    failure
    

    View Slide

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

    View Slide

16. MY PROCESS
    REQUIREMENTS
    

    View Slide

17. CTO doesn't stand for
    Chief Technical Officer
    

    View Slide

18. Managers don't always have all
    answers, nor should they dictate
    technical decisions to team
    

    View Slide

19. Teams are ephemeral
    

    View Slide

20. Experts have
    availability limitations
    

    View Slide

21. Risk should be
    manageable and visible
    

    View Slide

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

    View Slide

23. ... without making it
    design by committee
    

    View Slide

24. It should encourage
    responsibility
    

    View Slide

25. Allow for different levels
    of experience to come
    together
    

    View Slide

26. It should be welcoming
    for jr. folk
    

    View Slide

27. Promotes knowledge sharing
    

    View Slide

28. Increases visibility
    

    View Slide

29. Serves as snapshot of
    context
    

    View Slide

30. Helps balance between
    upfront design and fast
    iterations
    

    View Slide

31. Doesn't get in the way
    

    View Slide

32. Asynchronous
    

    View Slide

33. SEARCHING FOR SOLUTIONS
    IN THE WILD
    

    View Slide

34. ARPANET 1969
    

    View Slide

35. View Slide

36. EmberJS - Present day
    

    View Slide

37. View Slide

38. View Slide

39. THE RESULTING
    IMPLEMENTATION
    

    View Slide

40. It all begins with the
    need to engineer something
    

    View Slide

41. Should we write an RFC?
    

    View Slide

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

    View Slide

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

    View Slide

44. Write an RFC
    

    View Slide

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

    View Slide

46. RFCs are great for
    drafting contracts
    

    View Slide

47. Are you adding a new
    dependency?
    

    View Slide

48. Write an RFC
    

    View Slide

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

    View Slide

50. Next: Write the RFC
    

    View Slide

51. View Slide

52. View Slide

53. View Slide

54. Submit your proposal
    

    View Slide

55. View Slide

56. Set a reasonable approval deadline
    This has also proven to be tricky and subjective, ugh
    

    View Slide

57. Encourage discussion
    

    View Slide

58. View Slide

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

    View Slide

60. Crush all aggressions,
    passive or active
    

    View Slide

61. Remind team to assume
    good intent
    

    View Slide

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

    View Slide

63. Give insecure participants a boost
    for example, anyone can prefix comments with [newbie]
    

    View Slide

64. Promote trust
    

    View Slide

65. Let low risk mistakes happen
    

    View Slide

66. Process approval or
    rejection
    (the science on this is not in yet either)
    

    View Slide

67. Clearly designate
    approver
    

    View Slide

68. Another option is
    implicit approval
    

    View Slide

69. View Slide

70. Implement
    

    View Slide

71. May happen before approval
    if risk is low enough
    

    View Slide

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

    View Slide

73. Archive
    

    View Slide

74. View Slide

75. Maintain
    

    View Slide

76. Any contract updates
    should be made against
    original proposal
    

    View Slide

77. Conclusions
    

    View Slide

78. A note on tooling
    

    View Slide

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

    View Slide

80. Local context is more
    important than random mgt
    advice
    

    View Slide

81. If I help engineers make the
    decisions I hired them for, the
    team becomes stronger* and we
    write better* software together
    

    View Slide

82. *science is not in yet
    

    View Slide

83. View Slide

84. THANKS!
    Questions -> @buritica
    

    View Slide