Skip to content

LeadDev Austin 2018

Brittany Moore edited this page Mar 3, 2018 · 1 revision

Leveling Up: The Way of the Lead Developer - Pat Kua (@patkua)

When transitioning from a developer to a developer lead, you will probably face some monsters and "level up".

Leading involves totally different skills: "What got us here won't get us there."

  • Mirror Monster: You get stuck in "maker" mode instead of "multiplier" mode. You take too much ownership / control over code and problems instead of empowering the team to handle them.
    • Solution: maker -> multipler
  • Switch Monster: You are overly devoted to "binary thinking", or the idea that there is a single right answer. This can lead to paralysis (if you feel like you don't have the perfect solution) or micromanaging (if you think you always have the perfect solution).
    • Solution: Blurry is the new binary. Most problems aren't cut and dry, especially since teams themselves can vary so widely.
  • Moan Monster: You focus too much on problems or obstacles.
    • Solution: Motivate over moan.


Building Tech for the Non-Technical - Laurie Barth

Advice for building a project that will be owned by a non-technical team.

  • Don't underestimate the non-technical resources: build to their skills / strengths.
  • Use visuals to your advantage to achieve shared understanding.
  • Break things down into smaller problems (just as you would if building for technical ownership).

The Life-changing Magic of 1:1s - Adrienne Lowe

1:1s should be:

  • Scheduled but informal
  • Coaching, mentoring, context, and venting
  • Informative: where is the conflict? where is the drama?

How to tell 1:1s are going well:

  • You meet regularly, at least 45 minutes
  • You can discuss topics that matter, including specifics
  • You get an answer of substance when you ask "what's not going well?"
  • You give the report your undivided attention; it's their time

How to tell 1:1s are not going well:

  • You can't remember the last conversation or you forgot action items.
  • You are frequently late / cancelling the meeting.
  • You are focusing on status reports or information you could get through another means.

Quotes: "I can't do this, but I'm doing it anyway." (Imposter syndrome w/ regards to managing)


Building Engineering Teams Under Pressure - Julia Grace (@jewelia)

Google research:

  • The most important thing for the team is "psychological safety": "A shared belief held by members of a team that the team is safe for interpersonal risk-taking."
  • Predicated on trust...
    • People tend to "trust" people like them more easily (which leads to non-diverse teams)
    • Diversity is important, so build trust in other ways than likeness.

Toxic conflict (often) arises when different people try to solve different problems that they think are the same problem. What you want is an environment where people can solve the same problem in different ways in a safe environment.

Clarity is queen. Decisions happen constantly (every commit is a decision) and team members need clarity to make those decisions.

Clarity & Psychological Safety w/ regards to Teams

  • Unsafe and Unclear = chaos
  • Safe and Unclear = party
  • Unsafe and Clear = dictatorship
  • Safe and Clear = high-performing team

How to kick off a high-performing team:

  1. Determine the state of the world
  • Kickoff survey: What is the team's purpose? What has worked well? What hasn't?
  1. Hold a kickoff event
  • 2 hour meeting (over lunch works)
  • Get to know each other; realign purpose; brainstorm for the future; get excited.
  1. Align on a mission
  • Prioritize; frame the roadmap in terms of the mission
  • Consider something catchy (like an acronym)
  • Helps w/ talking to external candidates, because the entire team shares the message
  1. Safe space for the team to communicate
  • This can be a separate Slack channel just fo the team. Emphasize banter and positivity.
  1. Regular team lunch
  2. Goals
  • When making personal goals, ask the team to pick one goal that requires someone else's help
  • Share goals with the team - some members may have the same goals and not realize
  1. Team emoji / mascot


Tackling the Big, Impossible Project - Michele Titolo

Big, Impossible Project = significant in scope / significant in change

Definition of done

  • End result may be fuzzy; DoD can be "MVP" app or list of features
  • What causes the list of features to grow: new features, breaking things up, surprises

Manage dependencies

  • Dependency = any work that's not done by your team
  • Business As Usual (BAU) trap - you fail to inform the other teams in time, so you can't get on their schedule
  • Plan to get blocked
  • Communicate blockers
  • Having a dependency usually turns into being a dependency, especially as other teams accept and take ownership of your project (this is a good thing).


  • Make it easy to see how you are doing
  • Design and POC
  • Changes are well known and estimated

Your Customers Don't Care About Five-Nines Reliability: They Care About Five-Nines Customer Service - Kishore Jalleda (@kishorejalleda)

Don't mindlessly shoot for five nines - understand how much uptime is "good enough" and establish budgets. Often, dev teams aren't equipped w/ soft sills to manage an outage.

3 mindsets:

  • customer-focused
  • boss-focused
  • everyone else

When an outage occurs:

  • Send an outage notification (right now!)
  • PR & Social media
  • one-stop outage shop - issues page

Mitigate the impact:

  • Show me the impact (quantify)
  • BCP / failover a data center
  • rollback the change
  • restrat cluster

Outage soft skills:

  • Calm down
  • Speak out - the best engineers ask the right questions
  • Get straight to the point
  • Don't be a jerk; have empathy
    • Form a cult around the customer, not leaders
  • Never give up
  • Think on your feet; take a stand
  • Can you do a proper handoff?
  • Can you run a marathon?
  • Can you leave / take feedback?

After the outage is resolved:

  • Clean up - clean, consistent, convergent state
  • Bookkeeping
  • Postmortem - avoid the "bad apple theory"; blameless culture
  • Outage is about customers, not you

Things that aren't helpful during an outage:

  • Passion / perfectionism, if it blocks a solution
  • Excessive jiggling
  • Blaming or bitching
  • Fatigue leading to a "needle in a haystack problem" (one customer experiencing an outage is too many)
  • Covering up

DevOps Observations:

  • Uptime is everyone's job
  • Velocity is overrated; customer feedback is underrated
  • Anything that distances developers from customers is an antipattern


5 Ways You Can Hire Better - VM (Vicky) Brasseur (@vmbrasseur)

  1. Know why you are hiring.
  • Consider the problems you need to solve in 9-12 months
  • If you're solving an immediate problem, you need a contractor or consultant
  1. Write a good job posting.
  • Be explicit about the role
  • Use general requirements instead of specific ones (learning is more valuable than skills)
  • Inclusive language (textio)
  • Don't copy/paste
  • Don't kitchen sink the requirements (if you have too many, you probably need to think about the role)
  • Don't use education as a shortcut for experience
  1. Seek out new perspectives
  • Diversity isn't just gender / race: age, skills, anything that provides perspective
  • Value different perspectives
  1. Train the team to interview
  • Give them context
  • Assign areas of focus
  • Be consistent - applicants should be interviewed by the same people and asked the same questions so they can be accurately compared.
  • Ask nothing that doesn't directly relate to the job.
  • Have a blind first screening.
  1. Start the relationship on the right foot (interviewing is like dating)
  • Set expectations (decorum, process, salary)


Leadership Through the Underground Railroad - Anjuan Simmons

A discussion of lessons we can learn from John P. Parker in the underground railroad, and how to apply those lessons to our development leadership.

  1. Prepare your incentives before you need them (slack time, conferences, books, different things for different people based on how they value it).
  2. Bold actions set the tone
  3. Don't let your experience bias you
  4. Embrace continuous solving ("problems don't die; people do")
  5. You are a lead of leaders - let the team step up

Do the Most Good - Mina Markham

Tech is not inherently "good" - we need to put impact before intentions.

How can we address these problems?

  • Understand your role in the impact.
  • Be an accomplice, not an ally - have some skin in the game.
  • Don't talk about it, be about it.
  • Do the unglamorous work.
  • Find joy wherever you can.
  • Do (the most) good.

How to get involved:


Reclaiming the Spirt of Agile - Vishal Bardoloi

  • The answer to every strategic question is "it depends". The important part is what it depends on.
  • "Cargo culting" Agile is the lead equivalent of copy/pasting from StackOverflow.
  • Agile is a culture, not a process; leaders impact culture.
  • Leader's role for a self-organizing team:
    • Context, mentoring, course correction
    • Be an information radiator
    • Inverse DRY - leaders do need to repeat themselves
    • Observe trust, communication, etc. for potential problems
    • Recognize and shorten feedback loops
  • Collaboration = partnership, not order-taking
    • Power imbalances result in scope problems, timeline problems, features given a higher priority than technical debt, no "why" conversations
  • Leaders need to recognize tension
  • Hold the vision: "Even the right change feels wrong at first"

How to improve leadership:

  1. Practice communication skills
  2. Make time for individuals and interactions
  3. Coach, teach - leaders make leaders


The Death of Data: Retention, Rot and Risk - Heidi Waterhouse

Machine learning w/ old or biased data => "hallucinations", similar to ergot poisoning. Machine learning is not neutral - we've programmed our own biases into it.

"To kill data is to acknowledge the loss of its potential."

BMI == consequence of poisoned data.

As an organization:

  1. Hire an archivist
  2. Constrain storage space (to encourage deletion)
  3. Train data retention; set policies
  4. Automate deletion


Vault and Security as a Service - Patrick Shields

This talk is about Vault and involved many diagrams, so my notes are pretty thin.

True Tales of Building Microservices - Karl Hughes

For the purposes of this talk, microservices are:

  1. Encapsulated functionality
  2. Independently deployable
  3. HTTP

PackBack - pivoting w/ microservices

  • 3rd party microservices: great for startup, need to scale
  • Rewrites are easier with a template (replace 3rd party)

Graide Network - Migrating to microservices incrementally

  • Turning a monolith legacy app into a giant proxy
  • e2e tests can be useful when unit tests are not possible
  • automation before refactoring
  • build a culture of improvement (boy scout rule)
  • refactor > rewrite

I'm Lazy So I Write Tests - Jaime Lopez Jr

Test-backed Development (TBD) involves writing tests with explicit value. It's useful for:

  • api calls
  • smoke tests
  • demonstrating that something works

I'm Lazy Busy So I Write Tests

Who Destroyed Three Mile Island - Nickolas Means (@nmeans)

This talk involved a lot of nuclear reactor jargon that I couldn't reproduce accurately, so I won't try. 😄

The "First Story" of an accident focuses on humans.

  • Hindsight bias
  • Outcome bias

The "Second Story" treats human error as a result of systemic issues.

  • Why did those people make those decisions?
  • Are there ways to improve the system to give humans better information?


Clone this wiki locally
You can’t perform that action at this time.