The Lead Developer Conference (NYC 2018)

On Tuesday, April 24 I attended The Lead Dev conference in New York. This was a single-track conference that mixed 30-minute indepth talks with 10-minute "sampler" talks designed to whet your appetite on a topic while being densely informative.

A talk summary and most of the slides are online, they used the #LeadDevNewYork hashtag on Twitter for livestream-grade detail, and there is an excellent conference summary by an attendee here.

A few recurring themes came up repeatedly during the conference:

• Management is a career reboot. Your old developer context helps, but it's functionally an entirely new skillset.
• No one should ever feel compelled to choose management as a career-advancing move. Generally speaking, it is a lateral move into an entry-level job.
• Studies have concluded 10% of folks have the skills required to become a manager, and 20% more can get there with enough training. The rest would require extraordinary effort. This is especially worrying because...
• The overwhelming majority of companies provide zero training to become a manager.
• A manager cannot make up for a bad company at all, but at a good company they are often what makes or breaks a team.

I'm going to give a quick overview of a few key sessions and my takeaway notes & thoughts. I suggest reading the summaries linked above if my notes seem a little out of context.

Choosing Tracks by John Rivello: He went into developer management at Comcast without really knowing why, and recently returned to a purely technical individual-contributor role. He had some great thoughts on when to not go into management (including the mistakes he made in his assumptions that errantly led him there). He also talked about Comcast creating a purely-technical track since that time. Some key points I wrote down:

• Make it clear there is a path back from management to technical roles, or else folks feel trapped and leave the company to do it. (This is definitely something we'll do.)
• Write a full transition plan to go from technical to management, or vice versa. (This is basically on me as the first one over the hurdle to help the next person if/when we get there).
• Talk to people ahead of you on BOTH tracks before deciding (good advice at larger companies, but difficult at Vanilla since the sample pool is like 1 person each).
• Immerse yourself in management BEFORE changing roles into it (books, conferences, articles), and practice skills like mentoring and public speaking. (I did a ton of this.)

I think he had a very common tale of how folks slide into management because someone pitches it to them as a natural extension of being a developer. I've always believed that was complete bullshit, so thankfuly I knew what I was getting into.

Service Reliability Engineering (SRE) by Liz Fong-Jones: Lots of notes on this one because I think it looms large in our future for the latter half of 2018 thru 2019.

• Investigating long-term costs reveals 40-90% of effort / business costs is AFTER code is deployed.
• Agile is to Biz <-> Dev as DevOps is to Dev <-> Operations. It's the process glue that creates transparency and feedback.
• Establish an "error budget" to determine when issues need to be escalated and how much time can be spent. Use what customers care about to establish this.
• Before the SLA (Service Level Agreement) is the SLO (Service Level Objective) and SLI (Service Level Indicator). What is the measurement (SLO), what is our goal (SLI), and what are the consequences (SLA)? Establishing these in more areas than "Is the site up, yes/no?" can create clearer communication between teams and set expectations that can be documented.
• Avoid triggering any alerts that don't require immediate human intervention.
• DevOps is fundamentally about change management: progressive rollouts, problem detection.
• Emergency responses: Pull in help immediately. Empower others to declare an incident and get the resources they need.
• Blamelessness is table stakes. Complex system require sufficient safeguards that humans cannot inadvertently break them. Find the missing safeguards and add them.
• Roll out SRE to one services at a time, don't try to put them everywhere at once.

Maggie Zhou expanded more on the ideas of DevOps in a 10-minute talk that practically addressed the above:

• Instrument the code (ex: our database query timer). Add info collection BEFORE making changes to a system to establish a baseline.
• Use feature flags for infrastructure. Make the toggles accessible to non-developers via config / UI to make the socialization of how to address problems from a deploy easier (communication to & empowerment of non-developers).
• Segment metrics by ramp-up key (break out where is HAS been deployed vs NOT) to see problems earlier in graphs.
• Measurement code has bugs too. This leads to bad decisions being made based on the data.

Beth Long (New Relic) followed up with another short talk about being an Incident Commander. They:

• Coordinate the response to an incident - the human systems problem, not the technical one.
• Establishes process, medium, human & technical contexts, and priorities.
• Regulates the flow of:
  • Emotions (calm, methodical, moving - the opposite of fight/flight/freeze response)
  • Information (context and making connections between what people are saying)
  • Analysis (ask questions, challenge assumptions, amplify voices)

It's super satisfying when some puts a title on a thing you do, lulz. Now I wanna get an "Incident Commander" sticker or something. But in all seriousness, this made something click in my head that this is something to work on purposefully so that it's a documented, reproducible role and not just the thing Lincoln does when there's a problem (which is a bottleneck). For instance, while sitting in this talk I realized we should make a dedicated chat room per incident to centralize communications instead of hopping around. More on that later.

The New Manager Death Spiral was an entertaining talk by **Michael Lopp (Rands)* who went thru the worst case scenario of how a new manager can scuttle a team while having the best intentions the whole way down. While no one would ever (probably) perfectly do all 3 levels of bad he described, they were excellent food for thought and reflection. Some "failure modes" he descibed in the abstract were:

• I'm the boss, which means I'm in control. Leads to taking on too many tasks and responsibilities personally.
• The ineptitude of fake delegation. Hero coding, not giving guidance, creating paint-by-numbers for your team, and trying to code your team out of problem all contribute to this.
• Opinions become facts. A lack of information and guidance prompts the team to stop consulting you.

The three primary remedies he descibed were: let others change your mind; augment obvious and non-obvious weaknesses by building a diverse team; and build trust.

I've read several books by Rands and have followed his blog for a number of years, so it was super interesting to see him speak for the first time (that was a major draw that got me to the conference). I also discovered a private dev manager Slack he runs in the run-up to the conference and plan to join that soon.

Silvia Esparrachiari gave great 10-minute talk on preparing for having an intern. I hope in a few years Vanilla is in a place we can handle that and benefit from it, and this was a great primer on how to start thinking about the requirements of making that successful.

Continuous Culture by Kim van Wilgen: My notes for this one read like I was trying to take notes on a roller coaster. She covered a really indepth series of topics about continuous delivery and the impediments to it. Here's the high-level notes I wrote down:

• Cynefin Framework is a useful way of looking at the relationship "cause and effect" can have in various contexts (Complex, Complicated, Chaos, Simple).
• Mapping "Value" and "Effort" on an XY graph for feature request, the four quadrants are (clockwise from top left): Act / Decompose / "No" / "Maybe".
• Anti-patterns in deploying: Communication overhead (that's us).
• Continuius learning: sprint board for agile HR.
• "Fully realized release strategy".

Make The Right Thing The Easy Thing by Jason Lengstorf:

• Being a hero/rockstar feels really good. Being an auditor feels way less good.
• Rockstars don't get any days off - "bus factor of 1", bottlenecks, dependencies, initiative is lost.
• Team slowdowns are from lack of ability, knowledge, autonomy, or clarity.
• Good process makes stronger teams. Docs, Training, Onboarding, and Positive Code Review for the team.
• Appearing infallible diminishes teams.
• Why processes fail -Know vs Feel - "this is handcuffs"
• Make the right thing the EASY thing (yes here comes an acronym)
  • Emotional rewards - less effort, praise
  • Automation (code bot everything)
  • Simplification
  • Yak shaving (do foundational work to set up for success, don't hand off at 0%)

The conference ended with "The Best Hearts of My Generation: Intersectional & Inclusive Standards for Developers" by Patricia Realini, and it definitely kept the audience rapt for a late afternoon, final talk. I really recommend going to the slides for this one, but here's a few notes:

• "Minimizing" is most prevalent de-humanizing seen in workplace.
• "Gaslighting" is manipulating someone into self-doubt / doubting sanity.
• "Social loafing" is an offshoot of privilege / social capital (e.g. Erlich on Silicon Valley).
• Discuss communication styles in 1:1s to avoid misunderstandings.
• Require posting in chat before talking in person.
• Avoid broad generalizations.
• When "wrong" action taken, get context before correcting.
• Requesting vs Guessing attitudes: "Ask anything and see if they get it", vs. "must be assured of 'yes' before asking".
• Comfort in / Dump out - aggrieved party at the center. When you screw up, apologize -> let them define recourse.
• Resources: "The Path To Intentional Inclusiveness", open sourcing mental illness, Mouse + The Elephant newsletter, Project Include.

I'll leave you with the video she showed at the end of her talk, "Like Totally Whatever". It's a bit intense.

https://www.youtube.com/watch?v=me4_QwmaNoQ