Technical Decision Making for Teams

Slide 1

Slide 1 text

Technical decision making for teams the open source way - @buritica

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

I CONTEXT

Slide 4

Slide 4 text

The Dashboard Tragedy A screenplay by Juan Pablo Buriticá

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

time passes by like in the most agile of shops

Slide 7

Slide 7 text

a demo dashboard appears in the conference room hdtv

Slide 8

Slide 8 text

the CEO approves

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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)

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

This was a process failure

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

MY PROCESS REQUIREMENTS

Slide 17

Slide 17 text

CTO doesn't stand for Chief Technical Officer

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Teams are ephemeral

Slide 20

Slide 20 text

Experts have availability limitations

Slide 21

Slide 21 text

Risk should be manageable and visible

Slide 22

Slide 22 text

Everyone affected should have a space for input ...

Slide 23

Slide 23 text

... without making it design by committee

Slide 24

Slide 24 text

It should encourage responsibility

Slide 25

Slide 25 text

Allow for different levels of experience to come together

Slide 26

Slide 26 text

It should be welcoming for jr. folk

Slide 27

Slide 27 text

Promotes knowledge sharing

Slide 28

Slide 28 text

Increases visibility

Slide 29

Slide 29 text

Serves as snapshot of context

Slide 30

Slide 30 text

Helps balance between upfront design and fast iterations

Slide 31

Slide 31 text

Doesn't get in the way

Slide 32

Slide 32 text

Asynchronous

Slide 33

Slide 33 text

SEARCHING FOR SOLUTIONS IN THE WILD

Slide 34

Slide 34 text

ARPANET 1969

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

EmberJS - Present day

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

THE RESULTING IMPLEMENTATION

Slide 40

Slide 40 text

It all begins with the need to engineer something

Slide 41

Slide 41 text

Should we write an RFC?

Slide 42

Slide 42 text

Caution: this is very subjective and no formula has worked

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Write an RFC

Slide 45

Slide 45 text

Does this involve more than one system or team?

Slide 46

Slide 46 text

RFCs are great for drafting contracts

Slide 47

Slide 47 text

Are you adding a new dependency?

Slide 48

Slide 48 text

Write an RFC

Slide 49

Slide 49 text

If you have to ask, you should probably write one

Slide 50

Slide 50 text

Next: Write the RFC

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

Submit your proposal

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Encourage discussion

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

Managers beware. You must set expectations on civil conflict

Slide 60

Slide 60 text

Crush all aggressions, passive or active

Slide 61

Slide 61 text

Remind team to assume good intent

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Promote trust

Slide 65

Slide 65 text

Let low risk mistakes happen

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

Clearly designate approver

Slide 68

Slide 68 text

Another option is implicit approval

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

Implement

Slide 71

Slide 71 text

May happen before approval if risk is low enough

Slide 72

Slide 72 text

Deviations from original proposals should make it back to document

Slide 73

Slide 73 text

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

Maintain

Slide 76

Slide 76 text

Any contract updates should be made against original proposal

Slide 77

Slide 77 text

Conclusions

Slide 78

Slide 78 text

A note on tooling

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

Local context is more important than random mgt advice

Slide 81

Slide 81 text

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