Conference Report: The Lead Developer NYC 2019

This was my second year attending The Lead Developer. I love everything about this conference.

I love the content: it has solid, actionable advice for managers and senior ICs. It’s one of the few conferences that really acknowledge that the senior IC path exists and is a thing people might want to do.

I love the inclusivity: excellent closed-captioning, a reminder to use camel-case to help screenreaders, pronoun badges, a quiet room where the conference is streamed (with the aforementioned closed-captioning), lanyards that make it clear whether you're ok being photographed, a clear and emphasised code of conduct, and lots of other stuff. Every other conference should follow this model.

And now I love the speaker experience too. The (excellent and lovely) A/V folks present from their own laptop so you don’t have to mess with slides on stage. There are confidence monitors for both slides and speaker notes so you can talk directly to the audience and not to your laptop. You get a nifty headset microphone (delightfully known as the “Britney Spears microphone”) which is very hard to mess up. Also, they pay their speakers $350 and expenses, and offer two nights in a hotel near the venue, even if you're a local. Thank you, White October Events. It was a fantastic experience.

Just like last year, Lead Dev New York was a one-day conference with a single track including a mix of ten, twenty and thirty minute talks. If I misrepresented anything, or if you know extra livetweets or slides I could link, please mail or leave a comment here and I'll fix it.

Here’s what I saw:

Creating a Career Ladder for Engineers, Marco Rogers.

Marco says there's no such thing as a "flat" org: if you don't have visible structure, it just means the career path isn't visible. You still have a hidden structure full of assumptions and biases.

Hiring and retaining engineers is quickly becoming the top issue in orgs. A career ladder can help with engagement, hiring and growth:

  • engagement: Recognition and rewards keep people engaged and feeling valued. Visible paths to promotion help retention. A level increase is also a feedback loop that lets people see that they're getting better at what they do. Announcing a promotion is one of the most engaging cultural events that can happen at your company: "You fulfill your entire quota of slack emojis." (Hahaha I love this.)

  • hiring: A career ladder improves your job descriptions, and allows you to make more consistent and equitable offers. Personal growth is a major driver for candidates in choosing companies. If you have a flat org, you're not showing candidates that they can grow at your org.

  • growth: Career ladders can help managers be more consistent around performance management. If you're working on improving diversity, equity and inclusion, ladders give you a framework for capturing data around who gets promoted and why, as well as maintaining pay equity and mitigating biases during negotiations. The data and the visible progress help you build trust.

Your career ladder can have anywhere from three to nine levels, but it should always have a level called "Senior".  People aspire to that level; they're proud of reaching it. The Senior level is your anchor: the levels below are for people to grow their autonomy; the levels above increase impact and responsibility. (ed: I hadn’t thought of this and I think it’s insightful.)

Three examples of career ladders:

  1. the starter kit: this three level system (junior, mid-level, senior) is where a lot of places start when they go from being flat. But it doesn't scale. The mid-level is vast and nebulous. People top out at senior. Junior people just want to not be junior. And it isn't granular enough to help with compensation.

  2. the snowflake model, popularised by Medium, is a sophisticated system which scores individuals across lots of dimensions. It's great that you can reach the same level in different ways, and people do love numbers. But you need to be careful not to move the goalposts and make the meaning of the numbers change. Also it takes a lot of time and effort to use this model.

  3. the spreadsheet matrix is a matrix of level across various skill, and it strikes a nice balance between flexibility and not being such a huge deal to maintain. The often-copied Rent the Runway ladder is the classic of this type. Make sure to fill in every box; don't leave ambiguity.

When introducing a career ladder, messaging and rollout is critical. You need execs, HR and recruiting involved as you place every engineer into their new level, and you should brace for difficult conversations. Candidate offers should come with levels now; a good career ladder will help you close the offers.


Follow: @polotek

Deconstructing the Monolith, Kirsten Westeinde.

Shopify has one of the largest ruby on rails codebases in the world. It used to be a massive monolith, and has lots of shared code.

Kirsten’s slide comparing the pros and cons of monoliths.

Pros: code all in one place, one test/deploy pipelines, all data available everywhere, one infrastructure.

Cons: slow tests, new code having unexpected repercussions, need to understand the entire codebase.

Monoliths have fallen out of favour in the tech scene, but they have advantages. Kirsten recommends that new companies start with monoliths: you don't have time to make principled design decisions early on, you just need functionality for customers. You'll know when it's time to introduce more deliberate architecture when the cons starts outweighing the pros. Simple changes get hard to make. Code changes have unexpected repercussions. Onboarding new people becomes hard because they need to understand the entire codebase.

They explored alternatives to their monolith. They ruled out microservices, discouraged by the need to maintain multiple build/test pipelines, manage data access, deal with the extra latency from calls across the network, secure a wider surface area, and manage refactors across multiple services at once.

Instead they chose to build a modular monolith with isolated dependencies and strictly enforced boundaries. They’re two years in and it hasn't been easy, but they've made a lot of progress. They're following these steps:

  1. They reorganised code by real world concepts like orders and shipping, making it easier for developers to understand the codebase. To reduce disruption, they did this in one big-bang PR. It was a single day of rebase hell.

  2. They isolated dependencies and decoupled components. They built an internal team to determine which cross-component links were ok and which were violations. (ed: I thought it was cool that it was a team’s core job to make this happen; it wasn’t everyone’s side project.) An internal tool reports a score per component; it's source of pride for teams to have the least coupled components. They're going to open source the tool (though it's ruby-specific).

  3. Now they're going to start enforcing the boundaries. Each component will only be able to load components that they explicitly depend on. A dependency graph shows visualizations and makes it easier to see circular dependencies.

Even if you're planning on doing microservices later, transitioning to a modular monolith structure will make the microservice migration less painful.


Follow: @kmkwesteinde
Blog post:  

Detangling complex systems with compassion and production excellence, Liz Fong-Jones.

There's no thing as 100% uptime.

You can't just buy a DevOps culture. You can enable CI/CD, and put your engineers on call, but without training and operational discipline, you're waking people up at night who don't know what to do. They’re trying to respond to incidents using unpredictable deploys and walls of meaningless dashboards illustrating your last ten incidents. It's a path to burnout and operational overload.

We need production excellence. That means more reliable, more friendly systems, and people who feel safe asking questions and changing things. You have to ask:

  • Do you know when when things are broken?

  • Can you debug them in collaboration with other people?

  • Can we eliminate unnecessary complexity?

Systems are always failing and that's ok. We don't need every blade of grass on a lawn to be green. (ed: I love this metaphor!) We use SLIs -- measurements of our critical business-facing events -- to measure whether the system is behaving. Product managers will have opinions on what's ok latency; use those numbers and measure what percentage of the eligible events were ok. An SLO is a target for the availability number, e.g., 99.9% of events should be good over a 30 day window. Error budgets are your allowed unavailability. For example, if we're ok with one event in every thousand failing, we don't need to wake anyone up until we’re failing more than that. Measure what you can, and iterate. You don't need perfect monitoring on day one.

Liz’s slide tells us that “Debugging is not a solo activity.” Cute image of people debugging together by the extraordinarily talented @emilywithcurls.

Services have to be observable so we can form hypotheses during debugging. We need to be able to identify and explain a set of users or a single machine that is behaving differently to the others. Mitigate the impact and then debug later. Often, addressing the frequency of the outage is less important than addressing the impact of it. Make the business case to fix the problem and prioritize completing it.

Everyone ends up contributing to production excellence. Debugging can't be solo, and it crosses teams. Service ownership doesn't mean service selfishness: don't silo into your org chart. On call needs to be sustainable.

Lack of observability is a risk. So is lack of collaboration. If you yell at your customer service folks for reporting something wrong, you're making it less likely that they'll report a problem next time. Collaborate with other people.


Follow: @lizthegrey

Communicating and documenting architectural decisions. David Ayers.

We increasingly give teams autonomy and let them make their own architectural decisions. But now we have to keep our systems running while 15 teams build things 15 different ways. David told the story of an Oracle shop that introduced MongoDB without talking to the people they expected to run the systems. (It didn’t go well.) He proposes three techniques for making systems maintainable in an organization with delegated responsibility:

One of Dan’s slides: someone is thinking “Oh well, I guess they knew better”. But maybe they didn’t! Or maybe something has changed in the meantime! An ADR would have let them know whether the past decision is still valid.

  1. Lightweight architectural decision records. A year after any decision, we often find ourselves asking "Why did we decide to do it this way?". We need to make it as easy as possible to socialise decisions and record why we made them. Michael Nygard introduced the idea of Architectural Decision Records, a structure for recording the context around decisions. David recommends we write them in markdown, have them reviewed just like code, and keep them together in a folder in the codebase, where they'll be easy to find. Have a separate repo for big decisions that span multiple projects.

    ADRs should be small, clear and easy to read. The text should be factual and non-threatening and include both the decision and any necessary context for reviewing the decision later. Future people should be able to evaluate whether the reasons are still in play or whether it makes sense to change course.

  2. Enterprise architecture guilds who make decisions. The guild meets regularly to discuss and vote on proposed ADRs. They might spawn off short term groups to go research a topic, come up with recommendations and propose an ADR. They can also help with socialising decisions, for example by publishing a newsletter with all of the new ADRs.

  3. Reference implementations. If you use a lot of different technologies, it can become a difficult environment for new developers to get started in. Build reference implementations for the use of each technology. You can bake in best practices around linting, deployment, etc, and give people a roadmap to get started. Reference implementations, like other documentation, will get stale unless you put effort into it, so make a commitment to keep them up to date.

    As a bonus, build a "steel thread" implementation - the simplest possible thing that uses all the components and executes all of the paths. It gives people something to build on. (ed: I've written about my previous team's "ping pong" reference code at; it's a really simple and powerful tool for getting people started.)


Follow: @iamagiantnerd

The future of cross-platform is native, Justin Mancinelli.

Ok, first off I should say that I understood maaaaybe 5% of this, but afterwards I asked Jackie to explain it like I'm five and she did. (But if there are errors here they're mine, not hers. Thank you Jackie!)

Justin compared native and hybrid apps on mobile. Native means writing the app in a language that the OS natively supports, like Java on an Android. Hybrid means you can write in a different language, e.g., Javascript, but use a UI WebView (which is kind of like an iframe!) to make the code still run as an app.

Justin shows how native or non-native languages can be cross-compiled, transpiled, or containerized and made to run on different architectures.

Justin shows how native or non-native languages can be cross-compiled, transpiled, or containerized and made to run on different architectures.

Hybrid apps are good because they're super easy to create: there's a low learning curve and you get to use the same code for your website, your iOS app and your Android app. But they can have less good performance, and often worse UIs (or at least UIs that aren’t standard for the platform), and they don't let you use some of the nifty phone features.

Justin did a deep dive of all the options available for building a native vs hybrid app and there were very, very many of them and I had never heard of any of them, so I'm really not a reliable reporter here. He likes Kotlin Multiplatform the most. He said that Kotlin is basically the preferred native language now for Android (ed: and apparently that’s official now. h/t Robert Konigsberg for the article!) and Kotlin Multiplatform is a way to reuse the code logic but leave the platform-specific part to be implemented natively. So you get the best of both worlds, I guess?  Kotlin Multiplatform is pretty new, and if you start now you're an early adopter, but Justin reckons it works well.


Follow: @piannaf

Managing the Burnout Burndown, Anjuan Simmons and Dr Aneika Simmons.

Building software can be exhausting. It's partly the pressure to continuously figure things out ("always be shipping!"), but we also know that our skills may be out of date tomorrow. We have to work to stay up to date. Any system you keep pushing will eventually fall over. Research tells us that people in our industry are burning out.

Burned out people make worse design decisions and write more bugs. Their short tempers are bad for the team culture. They begin to withdraw from slack and email. They make fewer commits.

World Psychiatry says that burnout is a psychological syndrome emerging as a prolonged response to chronic interpersonal stressors on the job. It's being overwhelmed by the feeling that today's resources aren't going to be enough to meet tomorrow's demands. It includes:

Aneika explains the three dimensions of burnout: emotional exhaustion, depersonalization and reduced personal accomplishment.

  • emotional exhaustion. You have nothing left to give after a full day of work.

  • depersonalization. Unfeeling or cynical responses towards the recipient of your service.

  • reduced personal accomplishment and less engagement with work.

Burnout is widespread. In a study of 7500 workers, 44% said they sometimes felt burned out, 23% reported that they always felt burned out.

A University of Cambridge study said that even highly engaged employees are subject to burnout. The highest turnover was in highly engaged people.

Work has become the center of many people's lives; we identify so closely with our work that trouble at work can make us feel like we are having trouble in life. The people most susceptible to burnout are those who really want to derive meaning and significance from their jobs, but don't feel like they're achieving it. Burnout results in physical and mental illness, fatigue, high blood pressure and rage.

Workplace stress is the cause of up to 8% of the US national spend on healthcare. Around 120,000 people die every year from stress. Not "eustress", the kind of pressure that compels us to do well, but "distress", the kind of stress that takes away from you, that causes burnout. (ed: I hadn’t heard of this distinction before. I find it very useful.)

Tech gives us fancy espresso machines, games, happy hours… but that stuff doesn't help when people are trying to put their lives back together. The company's need to deliver value to shareholders can conflict with what humans need to be healthy. As for individuals, we might turn to "solutions" that hurt more than they help: escapism, excess eating, illegal drugs or alcohol. The need to be impressive on social media means that a lot of us turn our vacation into a different type of work. And escapism requires wealth.

So, corporate efforts are undermined by business concerns. Individual efforts are undermined by lack of resources. Is there a framework we can use?

Anjuan illustrated workplace stress with an adorable sad pug dog and we all had feelings. Dawwwww.

In agile projects, burndown charts are used for measuring progress. They show where you are compared to the ideal line for where you should be. As a manager, you don't just need to burn down work, but also burn down:

  • barriers: Human relationships protect us against burnout. Include your teams in solving problems. Have open discussions, share ideas, and let people know the outcomes of their solutions and ideas. Incentivize socialising, e.g., gift cards that only can be used if more than one person is engaging in the activity.

  • distractions: Attention is finite. Harness attention on the things that matter and learn the power of no. Remote work can help us stay focused.

  • illness: Software developers often trade their health for productivity (and then later we spend our wealth on improving our health). Maintain a healthy sleep cycle, stay hydrated and practice mindfulness. Consider designated no-work times to make sure you're taking a break.

It's ok to have a spike of work/pressure if you know you'll take time for self-care later. (ed: I also thought this was super insightful and helpful. It’s ok to have times where you’re overcommitted! You just have to build in time to recover afterwards.) It's all about balance. Practice is more important than perfection.

The call to action is to model ways of managing stress. Help your teams protect their hearts, minds and bodies. Teach them to reach out, reduce distractions and take time to renew themselves. (ed: this talk got a lot of love on Twitter, and rightfully so.)


Follow: @anjuan @aneika

Being right is only half the battle, Rod Begbie.

We spend a lot of time dealing with computers, but being able to deal with people is probably more important. The secret to your career growth is being able to have increasing influence over larger groups of people over time, and that needs more than job titles. Rod laid out three superpowers for how to scale yourself up:

  1. How to read minds. Ask questions! Listen to the answers and understand other people's viewpoints. Our instinct when we disagree is to try to convince people. Instead, ask questions. Maybe the other person has information you don't have. Ask playback questions: repeat what you think the other person said and ask "did I get that right?". Watch out for blur words, things where different people can take away different meanings, for example "end of day". Ask "What does end of day mean to you?".

    Rod presented a great example of a vague request: "we need to improve performance of most of the pages as soon as possible". It's better if you make it concrete: "By June 30th we need the P95 server latency reduced by 30ms". Ask questions that will get you incremental change. "On a scale of 1 to 10, how happy are you with the service". "4" "How do I get from a 4 to a 5?" Don't shoot for the 10 immediately. (ed: adding this one to my toolbox.)

    People love to talk about their opinions. Asking good questions builds rapport, builds allies.

  2. How to control reality. You can implant truth in someone else's brain, control reality, and bend people to your will and all you need to do is set a strategy. Strategy drives change. A useful phrasing to include is "even over", where you prioritize something you want in relation to something else you also want. "We will value X even over Y". Giving an example lets people feel empowered to make these decisions and know how to think about them.

    "We are going to value fixing bugs even over shipping new features" "We're going to value fast iteration even over polished UI". It means you don't need to micromanage, or go to a lot of meetings. But remember that the thing that makes it a strategy is writing it down.

  3. How to predict the future. The best way to be sure what's going to happen in a meeting is to have a lot of conversations in advance. You need to socialise ideas, start people thinking the way you're thinking. Even before the idea is ready, you can do the conversational equivalent of sketching on a whiteboard. "Here's a half baked thought…" Ask questions like "How would you react if I said…"

    Start with 1:1s with trusted friends, but don't limit yourself to friends. Gather perspectives and objectives: the team who will be implementing it, the person who is always grumpy about new ideas, the VP who will be most involved. Shake out the objections in advance. After a lot of these conversations, the thing that was "your idea" may become the thing people believe is true. You may hear people talking about your idea as if it was an agreed-upon strategy.

    Write things down. (ed: this! so much!) Email or slack is better than nothing. "This is what I think we agreed to. Did I capture it correctly?". People aren't being malicious or incompetent; they just forget things.

Sometimes people consider this stuff to be "politics", which often means "that team made a decision I didn't agree with and I don't know why". Find out the why. Maybe they have excellent reasons, maybe they're wrong. The reason we are paid is to be smart people who make difficult decisions in creative ways.

Last tip: get your own team in a huddle before a decision-making meeting and make sure they all agree on what you're going to say. You don't want to fall into disarray in front of the stakeholder. Always make sure you know what's going to happen in the room before you go in.


Follow: @RodBegbie

Being Glue, Tanya Reilly.

Can I recap my own talk? I’ll just say that I was pretty nervous but I was happy with how it went :-)


Follow: @whereistanya

Resilience Engineering Mythbusting, Will Gallego.

Will presented a lightning talk version of his SRECon closing keynote (which I blogged about here!) He introduced the idea of resilience engineering (which he got interested in by doing blame-aware retrospectives), and distinguished between resilience and robustness: robustness is whether a system can perform within predetermined expected boundaries. Resilience is whether it can adapt when its boundaries are exceeded.

Will debunked five myths people believe about reliable systems.

  • Myth #1: We can build resilience into the servers.
    Don't ask if resilience is built in. Ask "Can it adapt". Can it change course and take hints to build a better path forward?

  • Myth #2: Complexity is the enemy of a well-maintained system.
    Some complexity is necessary. Complexity is inevitable. You have to plan for it and learn to cope with it.

  • Myth #3: Best practices guarantee safety.
    Best practices change and often depend on the situation. It's more important for people to use good judgement.

  • Myth #4: Good retrospectives require action items.
    Retrospectives are for learning and building expertise. Action items are great, but not a requirement.

  • Myth #5: The frequency and severity of incidents tell how safe the system is.
    Failures are happening all the time and that's ok. Share expertise instead of numbers.

Three useful resources:

  • The ETTO Principle - Erik Hollnagel (ed: ETTO is the "efficiency-thoroughness trade-off", the idea that if you increase efficiency (e.g., productivity, cost-effectiveness), you reduce thoroughness (e.g., safety, reliability) and vice versa.)

  • How Complex Systems Fail - Richard Cook

  • Field Guide for Understanding Human Error - Sidney Dekker

(ed: I’ve been reading more about the topic of resilience engineering since Will presented at SRECon, and I’m finding it interesting.)


Follow: @wcgallego

Remote First teams, Nassim Kammah.

Who regularly works with people outside their time zone. (Something like 90% of the audience!). Who has had frustrating communications with them. (Basically everyone.) What are our options for doing better? We could ask everyone to move back into offices, but that would mean losing a lot of employees. We could stop having offices at all, but that would be unpopular too. The real solution is to go remote-first, to prioritise the experience of remote people.

Nassim proposed solutions for three topics that can cause friction when some people are remote:

  1. Meetings are the biggest source of friction. If one person is on the VC, they can see and hear everyone, but they can't participate in fast conversations; the team is missing out on that person's expertise. The traditional "caucus" meeting style is that whoever speaks first gets the floor. It rewards the kind of people who jump in. But remote people can't jump in: even apart from the lag, they're missing body language cues and maybe can't even see everyone in the room.

    Use the "One remote all remote" rule: every attendee should have the same experience.  If one person is remote, get everyone to dial in. (ed: this is a really interesting idea; I’m going to try it for a planning meeting I’ve got coming up.) Rather than try to find a lot of separate meeting rooms, get everyone to dial in from a laptop in the meeting room, but mute and use the conference room audio. Add a moderator. Make everyone gets a chance to listen by safeguarding the opportunities to speak.

  2. Timezones and deep work. Slack changes how we work. Jason Fried, CEO of BaseCamp, compares slack rooms to conveyor belts. The conversation still continues when some people are asleep, so the morning routine sometimes starts with hours of scroll back. And the conversation goes on throughout the day without pause, causing scattered attention. Everyone has to continuously decide whether to read and respond. It's hard to focus.

    In "Debugging the Development Process", Steve Maguire says the role of leaders is to shield the team from any thing that interferes with progress. You can set expectations around slack availability. For example, pick quiet times where there's no conversation in slack rooms. Encourage people to use those times for things that need undivided attention.

  3. In-person conversations and maintaining common ground. People who work together get to use abbreviated form of communication. Mutual knowledge, mutual beliefs and mutual assumptions let them use shorthand, drop context. In-office people sometimes feel the loss of common ground when they return from vacation; remote people lose it faster because they don't have access to in-person conversations.

    Mailchimp use a "slack changelog" to combat this: they use a slack plugin called Reactji channeler to copy every message with a particular emoji to the changelog channel. Now when someone posts a message they ask themselves who needs to see the message, they summarize the context around the message (for example a long thread it's at the end of), and they add the reactji. About 2% of the messages in their slack channel get pinned in this way. They've found this to be a game-changer for catching up from PTO.

Remote-first practices benefit everyone and they're everyone's responsibility. Don't leave it to remote people to make this stuff happen.


Follow: @kepioo

Leading engineering teams through massive change, Yvette Pasqua.

Whether it's technical, cultural or organizational, a big change can be disruptive -- and sometimes a thankless time to be a leader. Yvette was CTO of Meetup during their acquisition by WeWork and needed to find strategies to manage it. She discovered the value in asking for help and peer advice, initially from people she knew, then by growing her network by inviting people in similar positions to get coffee and have leadership conversations. (ed: I love doing this too!)

Changes pass through different phases. It helps to have a framework for communication, motivation and focus during each phase:

  • First there's an acute phase where announcements are being made. During the acute phase you need in-person two-way communication, like Q&A sessions. You need to understand and empathise with how people feel. It’s easy to get distracted here, so focus on investing only in the most important company priorities, and reinforce the company values and vision to keep people motivated.

  • Then there's a hockey stick of rapid change, during which you need to be highly focused on keeping the business healthy. You’ll need to convey lots of context, initially in-person but then shifting into written communication as the change becomes normal. During rapid change, people should feel anchored by a clear strategy and roadmap. Give people a direction and empower them to make the right decisions.

  • And then the change is done and this is just the new normal. You're back to execution and delivery, business as usual but maybe in a different direction than before.

If you ever go through change, it's good to fill out this model afterwards and do a retrospective on how you communicated.


Follow: @lolarobot

Crucial career conversations: a framework in practice, Adrienne Lowe.

How do you have good career conversations with your reports? Adrienne read Radical Candor and tried out its three-stage framework:

  • ask direct reports to tell you their life story. "Starting with kindergarten, tell me about your life".

  • ask them to describe their dream: "What would life at its very best feel like?"

  • use those two conversations to make an 18 month plan

It seemed great in theory, but practice is harder than theory.

As someone with disproportionate power over hiring, firing and promotions, you have to be careful to make 1:1s with reports be safe. If they’re afraid of losing your favour, they might avoid telling you things. You have to be open to the idea that this is not your report's dream job. You need to be their shield and advocate. You need to be ok with them bringing some skepticism to the activity.

Adrienne’s template for a 1:1 profile:

* I enjoy working on…
* I get excited by…
* Work that I’m proud of includes…
* I struggle when…
* I feel appreciated when…
* I prefer feedback…
* Ask me for help with…

Adrienne had a good relationship with her team and she found the life story part went great. People had high psychological safety and told her lots of powerful stuff about their lives. But the dreams part was a challenge. It can be uncomfortable to talk about what in your life isn’t how you want it to be. "Now you get to feel melancholy in front of your boss." People struggled to articulate what life at its best would be. They could name things that would make them happy but then they segued to talking about the tradeoffs they weren't willing to make to have that.

So she reframed the question to what it was really trying to uncover: what would people like to stop doing and what would they like to do more of. She asked people to pretend they're starting a great new job tomorrow: what would they want to keep doing that they're doing? They didn't hesitate. Everyone had lots of ideas. Then she asked them to imagine being in a coffee shop with friends, and the friend asks "what's frustrating for you. What do you want to stop doing?". Reframing it like that brought forth tons of detail.

The third step, the 18 month plan, didn't work at all. Adrienne couldn’t find a useful reframing of it and ended up throwing it out. Instead she worked on making 1:1s more useful and the feedback cycle more incremental. She created a 1:1 profile with questions like "I enjoy working on…", "I get excited by…", and so on. As an exercise to understand her reports, she filled one out with what she thought each person’s answers would be and asked them how close she got. She got pretty close! They liked it. The team shared their docs with each other, and she encouraged them to read each person's document closely before working with them.

Psychological safety doesn't come without putting in the work. You need to let your team see you as a person, and make it safe to speak truth to power. Schedule a couple of hours to answer the life story and dreams questions for yourself and mail them to your direct reports. It's scary, but it's good to be vulnerable.  Ask yourself the profile questions too, but be mindful of your cognitive biases and the weight and impact of your words on other people on the team. Don't be afraid to put a lot in "what will cause me to stumble"

Career conversations are a useful growth tool, but dangerous if you focus too much on the future at the expense of the present. Focus on the now. Have thoughtful conversations about who we are and where we're going. Time with people is precious and limited. Make career conversations less of a rollercoaster and more of a carousel: we're going around and around together, but noticing different details and experiencing something new each time around. We may appear fixed, but we're growing and changing. (ed: this was super lovely; I'm not doing it justice here.)

We know ourselves so we can ask to do more or less of kinds of work. We can become the people we want to be by honouring who we already are.

Follow: @adriennefriend

Principles for managing product quality, Kwame Thomison.

Kwame identified four types of thinking that are useful in analysing failures. Each is one level of abstraction away from the one before:

  • event oriented: what happened? How should we respond?

  • trend oriented: what is the pattern of events. What's likely to happen? How can we prevent bad things?

  • system oriented: how is the structure guaranteeing the observed behavior? How will changes to the system affect it.

  • mental mode oriented: what assumptions, beliefs and values are giving rise to the system?

Different models are useful for different situations.

Understanding systems fully allows finding leverage points. For example, when optimizing the performance of a complex site under heavy development, he found that applying systems thinking helped him find unexpected leverage points. Having a team summit made a difference, as did making t-shirts. Hacking on company culture is a high leverage activity.

Systems thinking helps you manage quality long term. Instead of asking "how do I solve this problem", ask "what thoughts, beliefs, and values do I need to adopt to ensure different behaviour?" What parts of your culture are contributing to the failure? What mental models do you need to adopt or discard to cause the necessary structures to emerge?



Scaling yourself during hypergrowth, Julia Grace.

When Julia was ready to change jobs, she looked at the home screen of her phone to see which apps she wanted to contribute to. (ed: this is genius). She chose Slack, and ended up leading the developer platform team. The user base for the platform grew rapidly, both horizontally (raw number of users) and vertically (size of teams), putting pressure on the infrastructure and on the humans running the system. Julia talked about how she built a scalable organization and maintained organizational agility in the face of constant change and exponential learning curves. She gave us ten takeaways.

  1. Writing well and quickly is an incredible asset. Writing helps you clarify thought. You lose credibility as a leader if you can't convey the critical points of a message, so before she communicates to her team she writes down her talking points.

  2. Stories are powerful. Leadership involves a lot of evangelism. A story motivates people: you can tell the story of why the company is there, of ambitious goals. You need a good sales pitch to show candidates why they should join your teams. It might not come naturally but it’s a learnable skill. (ed: Jessica Hilt’s talk, Strategic Storytelling is a great resource. I love that talk.)

  3. Have a communication plan for everything. Don't wing it. (ed: This is so true. I have learned this the hard way.)

  4. Know your audience when you're communicating. She gave an example of being a bit starstruck when they hired a new VP, and agonizing over what information to give him. Her coach asked: did you ask him what he wants to know? Now, always asks people what's top of mind for them and what format they want.

  5. "Too many meetings" is often a symptom of misalignment. Meetings can be a reaction to not enough information. Process is often a response to a big event. The underlying problem is often organizational drift. If you have tons of meetings, think about whether you're aligned on goals.

  6. Create structure and process around the things you do often. But not the other stuff! It's ok for the rest to be messy.

  7. Always ask who the decision maker is. Decisions go to decision purgatory when it's not clear who's allowed make them; you end up with lots of meetings with no outcomes. (ed: this whole talk was relatable for me and this bit was the most relatable.) Decisions can sometimes get escalated up until they get to execs who are too far from the frontlines to make the call. Their execs can escalate back down by picking people close to the problem and telling them to go in a room and decide.

  8. Credit always flows to the most senior/tenured/visible person. If that's you, bolster and support other people. Make sure credit gets distributed to the people who did the work.

  9. Leaders build orgs that mirror their strengths and weaknesses. Julia shared advice that Diane, a Fellow at IBM, gave her: look at the leaders. People like them will be promoted fastest. Since then, she started asking leaders "What is your biggest weakness. How are you ensuring you're not over-indexing for people like you?"

  10. Treat people fairly and with respect. It's a tremendous privilege to be their leader.

This was a powerful and inspirational note to end on.


Follow: @jewelia