Next up is @randyshoup, on Moving Fast at Scale. #DevOpsDays
Currently @stitchfix, previously doing CTO consulting as a service, and before that director of GAE at Google & eng lead at Ebay. #DevOpsDays
Is there a dichotomy between speed and stability? High-performing orgs can do multiple deploys per day. Time to release is 1 hour vs. 1 week, failure recovery is 1 hour instead of a day, <15% of changes fail. #DevOpsDays
High performing orgs combine both high speed *and* high stability. cue obligatory Gartner quadrant joke. #DevOpsDays
Same things that let us go fast also let us be stable. Also 2.5 times as likely to exceed business goals. 4 critical aspects to doing this: organizing for speed, deciding what to build, when to build, and how to build. #DevOpsDays
Remember Conway's Law that you ship your org chart. Need modular organization to get a modular set of infrastructure. #DevOpsDays
Not just a descriptive law, but also a normative law; "we can engineer the system we want by engineering the organization first". #devopsdays
[ed: this is why you sometimes see VPs reorging their directors, or directors reorging managers, because they want this effect.] #devopsdays
And the thing we've heard repeated to death: full-stack, "2 pizza" teams that have 4-6 people with all the skillsets needed to get job done. #devopsdays
and give the team a clear area of responsibility that corresponds clearly to the business. #DevOpsDays
Sometimes we need to perform cellular mitosis and split teams into two [ed: and John T. Reese at Google has proposed that you should split into *threes* to cover the gap between the two] #DevOpsDays
Ideally, 80% of project work should fall within a team boundary, so pick the boundaries carefully. #devopsdays
point 2. Figure out what to (not) build. Reread _Lean Software Development_. 100% of what we put into building the wrong thing is waste. "What problem are you trying to solve?" #devopsdays
Don't let people dictate *how* you solve the problem before you ask them the problem they're trying to solve. It might not need to be solved with technology. See as well. #devopsdays
[ed: sorry, should have note that that's me, the editor of the livetweets, plugging my talk, rather than the speaker shouting me out] #devopsdays
e.g. get people to *try* doing a process once before you write any code to automate it. "a problem half stated is a problem half solved" -- ??? from general motors #devopsdays
Buy, not build. Use cloud infrastructure. Prefer (re)using existing open source. It's often better than the commercial alternatives. #devopsdays
Stitch Fix uses >50 third party services: logging, monitoring, alerting, project management, bug tracking, payments, billing, fraud, etc. -- anything that isn't a core competency. #devopsdays
"soon it'll be as common to run your own datacenter as to generate your own power". #devopsdays
Finally: (3) iterate towards solutions through experimentation. Front-load the learning so we get on the right path quickly. State a hypothesis. Have measurements. What metrics will move, and why. Have a baseline. #devopsdays
Do real A/B tests. Obsessively log and measure. Write down what worked and didn't work to get insights for next time. #devopsdays
Two examples from Ebay: goal was to change ranking function for search results away from hand-tuned functions. Did incremental experimentation with predictive models and hundreds of parallel A/B tests. Took a year. #devopsdays
2% increase in eBay's revenue = $120M a year, at end of first year. in parallel, increased speed of site. Monitored metrics: time to first byte, time to click, click/purchase rates. Another 2% increase from that. #devopsdays
~20 people improved eBay's bottom line by 0.25B. [ed: and how much of that profit did *they* see?] #devopsdays
Takeaways:
Prioritization: scarce resources mean we have opportunity costs and tradeoffs.
Few things, more done. [ed: Google's infamous "more wood behind fewer arrows"]

#devopsdays
Clapback to @yesthattom's talk yesterday: deliver full value earlier. value now larger than value in future. #devopsdays
and deliver incremental value earlier. solving problem 1 promotes problem 2 #devopsdays
Finally, how to build: have discipline about quality. don't incur technical debt. Quality and reliability are a prerequisite to any pretty feature. Developers are responsible for everything: features, quality, performance, reliability, and operability. #devopsdays
Make sure people are incentivized to produce high quality from the beginning, and that they can fail-fast. Use TDD, so that we can be faster -- because you can be more sure about making changes [e.g. running on solid ground, not quicksand] #devopsdays
Without tests, you can't be confident things will continue to work, and can't be confident enough to refactor courageously. #devopsdays
Microsoft study: 75% of time spent reading code, 20% of time spent modifying code, 5% of time spent writing new code. #devopsdays
Investing in TDD makes 95% of your effort better. They're documentation as code of how things are supposed to work. #devopsdays
What if people say "we don't have time to do it right!" -- say "do you have time to do it twice?" -- the more constrained you are, the more important it is to build it right the first time. You'll never go back and finish. #devopsdays
"Build one right thing rather than two shitty things". Right = minimum viable product, not perfect. #devopsdays
Having a bug tracking system results in bugs lingering around; make sure there's time to just fix them on the fly, instead of having them build up and build up. Backlog is a list of *features* and *debt cleanup*, not a list of *defects*. #DevOpsDays
Finally, faster is better. [fin] #DevOpsDays
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Liz Fong-Jones [at #devopsdays NYC]
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!