Baking Developer Experience Into Your Culture (with notes)

for Heavybit's DevGuild, on July 27 2016

Transcript

1. BAKING DX INTO YOUR CULTURE HEAVYBIT DEVGUILD @CYEN honeycomb: a fast, flexible tool for exploring your event data before that: 2 1/2 years at parse and facebook building out parse analytics and leading our web team. - like to share some thoughts around building a culture that values developer experience, even as the company itself grows and evolves.
2. - love developer tools - love the multiplicative effect: make life easier for folks who are building the smash consumer apps or the industry-disrupting platforms - when hear about some awesome co/org/class, doing sth cool w/ the tools i've built - this what impact feels like. this is what real influence is. - not just my little corner: others to build on top, to make their lives and their corners better. - love thinking about how to make their lives _easier_. - the average human using a developer product is not used to a consumer-quality experience. - hacking their solutions together - think that the AWS console is the pinnacle of good product design.
3. - another love: how naturally they spring out of brain / fingertips. - few set out to build devtools. working on something else, hit some wall. sucks/broken -> why not, let's go fix this other thing. to make your own life easier. - that’s what’s so fun: despite unsexiness, more than any other, devtools *start out* as passion projects. - you = only customer. - nothing to lose, completely empowered -> fun to try things out -> instant gratification - custom-built solution, for you and your workflows, you're incentivized to make the experience of using it as awesome as possible
4. - ... but once you start to share - ... and once other people, w/ diff needs/habits, start to use it, - ... experience tension between what made so great + what's necessary -> accessible. - tension between the immediacy of solving your own problems... and the impact of being able to benefit someone besides yourself. -> let’s break down what looks like:
5. SURFACE AREA TINY INTIMACY INFINITE FEEDBACK LOOP SHORT-CIRCUITED - maintain high-quality DX during this expansion (of product surface area + influence), two axes - near the origin: - you on your own, happily scratching your own itch - the most in tune you will be w/ the DX, and there are a few parameters that make this spot GREAT for that: - short-circuited feedback loop. (instant gratification) - small surface area (literally focused on just solving your problems, and you can keep the whole project in your head) - infinite intimacy (familiarity with one's problems, habits, processes). this! is what matters. -> DX - anywhere we go -> move away from perfect setup for evaluating DX, we lose this intimacy/familiarity with the problem. - as we move along each axis, we’ll need different tools to get back intimate understanding
6. EARLY GROWTH INTERNAL EXTERNAL - x axis: stage of your company, "early" -> "growth stage" - characterize that as < 10-20 engineers, obviously vary from co to co - "early" vs "growth"just characterizes the change from lots of hats -> stricter boundaries, specialization - y axis: level of exposure you're willing to deal with -"internal" only needs to involve your team,"external" involves potential customers. - think about this as how much forgiveness, karma, or flexibility you have - internal opportunities can be seized without risking your brand - each quadrants has a set of qualities that set it apart from the others —> characterize opportunities available to learn/optimize DX - as we move through these quadrants, thinking about how to prioritize DX in these diff stages must be conscious decision
7. EARLY GROWTH INTERNAL EXTERNAL SURFACE AREA SMALL INTIMACY HIGH FEEDBACK LOOP SHORT - founder/sole maintainer -> heading up an early-stage team. - team is still small and tight-knit - might have hired from network / folks who share background - just starting out -> likely that they feel the pain of developers firsthand, share your point of view - might be pre-release. want to evaluate experience without leaking anything - quadrant is same, but slightly looser than, the solo case: - FL: still very short - SA: probably still pretty small - I: familiarity with the problem is still quite high
8. EARLY STAGE + INTERNAL DOGFOODING ▸ Integrate as tightly as possible into essential processes ▸ Goal: be intimately familiar with the pain points + problem being solved ▸ Don’t forget docs: docs should be reviewed along with code - may or may not have customers, DOGFOODING going to be obvious win (because we don’t have much else) - integrate into essential processes - natural progression from origin: built to suit your needs - goal: expose self to as much pain a.p., stay intimately familiar w/ problem being solved, rough edges, etc. you should be the power users - includes dogfooding DOCS: another person runs through + validates docs. - never just one person's job to write docs, never just one person’s job to maintain and assess quality / clarity - ex: sentry — crash reporting service, tracking errors and exceptions across various platforms - whole team uses sentry to build/maintain sentry - by living it themselves every day, keep that feedback loop really tight, and ensure DX of sentry smooth a.p. -> everyone else
9. EARLY GROWTH INTERNAL EXTERNAL SURFACE AREA SMALL INTIMACY MEDIUM FEEDBACK LOOP LONG - team -> same size - starting to pick up adoption, be beholden to customers (not friends) - quadrant: - FL: anybody external to company -> feedback loop gets longer (though, easier to close with fewer people) - SA: starting to have to build out functionality not just for us, but for external use cases - I: will see intimacy change as a function of FL and SA - can still feel focused, -> start to build for customers, our own feelings aren’t enough for our more shared experience, we have to start listening
10. EARLY STAGE + EXTERNAL SUPPORT ▸ … is everybody’s problem. Keep as much of your team on the front lines ▸ Goal: complement dogfooding, outside perspective corroborates/contradicts ▸ Feeds back into documentation DAY O’ SUPPORT - best way to listen to your users at this stage? really excellent support. - not just to help your devs, but to intimately understand what devs struggle with, and improve their exp. - is everybody's problem. folks on the front line a.p., talking to users, staying familiar with what's like use your product - can't intimately understand all parts of DX firsthand, but can make sure hears about secondhand - story time: parse, BaaS (beginning: object store). day o’ support, one of the best things we did. rotated through eng, once/handful of weeks - anyone building/affecting users - "backend," "client," "push," etc - rotate, full day managing support tickets - set aside: 1) task queue, 2) preconceived notions of responsibility, 3) ego; focus on listening to dev problems - sometimes meant debugging in areas not your strong suit. cross-pollination - gave snapshot view of problems devs run into - rotating through the next time: problems/concepts that don’t go away - start to understand own docs really, really well + how to improve - sending the same docs? -> undiscoverable // adding caveats / context? -> incomplete // sending sample code to illustrate? -> sth fundamentally missing
11. EARLY GROWTH INTERNAL EXTERNAL SURFACE AREA SMALL INTIMACY HIGH FEEDBACK LOOP SHORT SURFACE AREA SMALL INTIMACY MEDIUM FEEDBACK LOOP LONG - before "made it," hard to invest time in th aren't *building product* - i get it - we're engineers. writing prose != writing code. - dogfooding + support = intimacy ^. impress upon team importance of good DX - where you fall short, will feel it. + hear about it. - make a conscious decision to invest the time. state as priority early. - remember: intangibles matter! style matters! idiomatic code, following conventions -> easier to orient self, use new product w/ existing workflows - not being nitpicky. good DX now -> less fallout later. - embrace opportunities to rotate through your team and cross-pollinate like this. so that anything that sucks about your DX... is everybody's problem. and everybody is empowered to fix it.
12. EARLY GROWTH INTERNAL EXTERNAL SUFACE AREA LARGE INTIMACY MEDIUM FEEDBACK LOOP MEDIUM - grown a bit. making money, more comfortable, attracting different folks - mb specialists <3 scaling problems - mb consider a job well done = tests pass, inputs produce expected outputs - something other than optimizing the end experience of developers relying on your product - in an ideal world, hire only people who feel problem themselves - in reality -> conscious decision to encourage team to seek out opportunities to enhance intimacy - exposure: starting to be bigshots, can’t make many mistakes externally -> leverage bigger team and explore DX internally, lower risk. - quadrant: - FL: team is large, but it’s all internal so responses are still relatively quick - SA: growth stage means -> product grew. likely varied demand, varied use cases, verticals - I: your stack might be consistent, but growth/evolution -> dilutes the closeness with problem
13. GROWTH STAGE + INTERNAL ENCOURAGE EXPERIMENTS ▸ Specialization reduces efficacy of dogfooding ▸ Starter Projects: orient with respect to your developers ▸ Hackathons: permission to step out of day- to-day roles - dogfooding: still valuable internally, not as effective - specialization -> select few exposed to specific problem - larger surface area -> hard to get holistic view of DX - how to scale effectiveness of dogfooding -> making folks understand what it’s like to be a dev using product -> to larger team? - starter projects: address issue with new hires head-on - shouldn’t be just a baby task to get started with their full-time pos, but instead to orient wrt your DX - says: "this is what you signed up for; this is the real problem we’re trying to solve, that you’re trying to solve as part of this co" - favorite - internal hackathons. all about giving folks permission to step out of roles + use product - dropbox: hack week - API team - viewed as huge opportunity. API huge usage during hack week, and team found useful for experimenting safely - feedback on DX sounds like early stage support feedback: learned devs’ sticking/confusing points - yes, cool things got built, everyone leveling up on familiarity API -> tons of docs fixes, expansions, upgrades
14. EARLY GROWTH INTERNAL EXTERNAL SURFACE AREA LARGE INTIMACY LOW FEEDBACK LOOP LONG - team is the same - "external" isn’t small stakes anymore. forgiveness much harder to come by w/ strangers - quadrant: - FL: strangers much harder to get feedback from. drop off the face of the earth, whether solved or not - SA: large. these strangers have unpredictable use cases, enterprise practices, etc - I: low. you’ll have totally unexpected devs doing unexpected (or undesirable) things - honestly, less about taking advantage ^ than compensating. - natural progression ends up with a team who: - removed from devs who are suffering - don’t have the bg to understand why - can’t keep track of how (too many entry points/SA too high) - find opportunities for DX despite these qualities?
15. GROWTH STAGE + EXTERNAL GET SOME FACE TIME ▸ Everybody should have a chance to be a user, talk to users ▸ Growth brings more opportunities to reach developers ▸ Events: remove the wall (literally!) between your team and developers - in beginning, dogfooding/support: idea of be a user, talk to users - with growth comes more opportunities to talk to/engage dev community - events (meetups, sponsored slots, user groups, etc): fight the feeling of "not my problem" - harder to not care about terrible DX when have to explain face to face why sth is a #wontfix
16. EARLY GROWTH INTERNAL EXTERNAL WHAT ABOUT ADVOCATES + EVANGELISTS? SURFACE AREA SMALL INTIMACY HIGH FEEDBACK LOOP SHORT SURFACE AREA SMALL INTIMACY MEDIUM FEEDBACK LOOP LONG SURFACE AREA LARGE INTIMACY MEDIUM FEEDBACK LOOP MEDIUM SURFACE AREA LARGE INTIMACY LOW FEEDBACK LOOP LONG - maintaining a high-quality DX is a conscious decision, which requires different techniques as circumstances change - advocates/evangelists - jetpacks, not crutches - fantastic to focus on your devs and their stories - doesn’t let the rest of your team off the hook - end goal should be for your whole team to be more aware of DX, not less - not a substitute for team talking to users - not a substitute for team understanding + anticipating developer pain
17. @CYEN THANKS CHRISTINE@HONEYCOMB.IO doing something cool -> i’d love to hear about it!