What makes a good technical leader? How does one stay competent technically while being an effective leader? How do we build more effective teams in the age where people are constantly pulled in multiple directions but still expected to focus and deliver?

I had the privilege of attending The Lead Developer Conference held for the first time in Austin this year. There were a lot of good talks but here is a snippet of the ones that stuck with me.

  • Pat Kua: Levelling Up: The Way of the Lead Developer

    • As engineers, our default mode is the ‘maker’ mode. But, as a leader, we don’t necessarily need to always be the one solving the problem, instead, enable the team to do so themselves.
    • There rarely is only one right answer to a problem, especially when it involves human beings. Consider the context of the situation and the tradeoffs when making decisions.
    • What you say matters as much as how you say it. Each of us come with different interpretations of reality and our own personal biases, so what you say could mean different things to different people.

  • Julia Grace: Building Engineering Teams Under Pressure

    • When Google set out on its quest to build the perfect team, the most important thing they found after studying many many teams was that the good ones generally shared 2 behaviors: Members spoke in roughly the same proportion (equality in distribution of conversational turn-taking) and they were skilled at intuiting how others felt based on nonverbal cues (high “average social sensitivity”). Within psychology, researchers sometimes colloquially refer to traits like ‘‘conversational turn-taking’’ and ‘‘average social sensitivity’’ as aspects of what’s known as psychological safety
    • Toxic conflict arises when different people are solving different problems that they think are the same problem.
    • Get as much clarity and information as possible about the problems that you’re solving and NOT solving.

    • Grace further illustrates the combination psychological safety and clarity:

              Psychological
            safety
              ^
              |
    Party     |  High performing
              |   team
              |
----------------------------> Clarity
              |
    Chaos     |   Dictatorship
              |
              |

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

    • Be mindful of the data that you store. Store it in such a way that enables you to separate the wheat from the chaff.
    • It might be cheap to store data, but is it cheap to maintain, protect and convert to new formats in the future?
    • Old data is not neutral, it affects current data.
    • “Collect carefully. Ingest mindfully. Delete boldly.”

  • Nickolas Means: Who Destroyed Three Mile Island?

    • When something bad happens (e.g. we experience an outage of our services, we miss the deadline on a very important project, someone miscalculates a formula that causes us to collect the wrong amount of money from our customers, etc), it’s always too easy to find someone to blame and make them pay for their mistakes. In reality, if we believe that we have hired the right people with the right values to get the job done, the root cause is never that simple.
    • Nickolas talks about Hindsight Bias, also known as the knew-it-all-along effect, is the inclination, after an event has occurred, given the knowledge of everything that took place during that event, to see it as having been predictable all along. He also talks about Outcome Bias, which is when we evaluate the quality of a decision, when the outcome of that decision is already known.
    • It’s very important when something bad happens that we focus less on the human(s) that made the mistake, but rather the systemic flaws that allowed the human to make the mistake. Seek forward accountability, and always find the second story that’s hidden under what’s obvious.