Emily Freeman
Principal Cloud Advocate, Microsoft
Denver, Colorado, United States
Emily Freeman is a technologist and a storyteller who helps engineering teams improve their velocity. As the author of DevOps for Dummies, she believes the biggest challenges facing developers aren’t technical, but human. Her mission in life is to transform technology organizations by creating a company cultures in which diverse, collaborative teams can thrive.
Links
Area of Expertise
Topics
The Intelligence of Instinct
Last year I got on a hotel elevator in Toronto with three men: a staff member and two others. I hesitated before getting on but thought better of it. There was a staff member. It was a nice hotel. But I did something that should have clued me in. I hit the button for the wrong floor.
The staff member got off on the fifth floor. I had 14 more to go. The doors closed. I felt the large man behind me grab my backpack. “Why are you wearing this cockblock?”
I did what every woman does in that situation. I made myself small. I tried to ignore him. 8 more floors. He persisted. “What’s in there?” The doors opened. His friend dragged him off. I went to the wrong floor, walked down the stairs to my room and cried. I got lucky. But the clues were there. I hesitated. I had a “feeling.” I pushed the button for the wrong floor. Why?
Fear is not a gut feeling. Fear is your brain delivering critical information derived from countless cues that have added up to one conclusion. Stop. Get out. Run.
But sometimes fear isn’t life or death. Often, it’s code smell. It’s a bad feeling before a deploy. There are endless dark alleys in our codebases. This talk will explore fear, instinct and denial. We’ll focus on our two brains — what Daniel Kahneman describes as System 1 and System 2. And we’ll look at how we can start to view “feelings” as pre-incident indicators.
This IS NOT Fine: Putting Out (Code) Fires
So the dumpster is on fire. Again. The site’s down. Your boss’s face is an ever-deepening purple. And you begin debating whether you should join the #incident channel or call an ambulance to deal with his impending stroke.
Yes, we know this is a developer’s fault. There’s plenty of time for blame later. Postmortems have a macabre name because they were once intended to be Viking-like funerals for someone’s job. But we’re civilized now. Sort of. So we call them post-incident reviews.
Fires are never going to stop. We’re human. We miss bugs. Or we fat finger a command — deleting dozens of servers and bringing down S3 in US-EAST-1 for hours — effectively halting the internet. These things happen.
But we can fundamentally change the way we approach fires. And that requires adopting the techniques of industries much older than ours.
Firefighting (the kind with flames) was created as a lucrative scheme by Marcus Licinius Crassus in Ancient Rome. Only we wouldn’t have considered his brigade heroes. They would arrive to the fire and do nothing while one “firefighter” negotiated the price of their services. If an agreement could not be reached, they would let the property burn to the ground and then offer to buy it for a fraction of the original value.
This is probably not a great strategy to use with customers. Though you could pitch it to a VC — just be sure to use the word “blockchain” in your proposal.
Firefighters have clear procedures and a strong hierarchy. The first truck at a scene immediately begins assessing the situation. They evaluate building construction, visible smoke, fire and flow paths. The Incident Commander gives orders to his or her personnel regarding fire attack as well as calling for additional resources, communicating with those not yet at at the scene and preparing an action plan.
Which sounds a lot like the tight, orderly process of a deploy rollback or hotfix. Just kidding.
This talk will focus on how firefighters approach a fire — before, during and after an incident — and how we can apply those strategies to our own (admittedly much less dangerous) fires.
Scaling Sparta: Military Lessons for Growing A Dev Team
Scaling systems is hard, but we’re developers — that’s kind of our thing. Scaling people? Well, that’s significantly harder. Humans are complicated.
Broadly speaking, companies have three stages of development: infancy, those awkward teenage years and — if they survive the trials of adolescence — adulthood. An infant startup is so drastically different from its adult incarnation that they can be considered different companies. Each will have a unique mission and culture.
Scaling isn’t just about making what you have bigger. An ant can’t be scaled to the size of an elephant. Because the internal structure is fundamentally different. Instead, companies have to evolve.
But companies aren’t living, breathing organisms. They’re collections of people — families, tribes and civilizations.
So how do you scale a team of two to twenty? The answer starts over 2,000 years ago in Sparta.
This talk will focus on three distinct military organizations: Spartans, Mongols and Romans. Sparta’s standing army numbered 10,000 whereas Rome’s peaked at half a million. We’ll look at the structure of each military and apply the lessons learned to our development teams and organizations.
Emily Freeman
Principal Cloud Advocate, Microsoft
Denver, Colorado, United States
Links
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top