Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Lead Developer Conference 2019 – Notes

Lead Dev Conference 2019 (code: leaddev)

Navigating team friction

Lara Hogan – @Lara_Hogan

Storming -> Norming

  • Brains
  • Feedback
  • Team Processes


  • Belonging – part of a group
  • Improvement/Progress
  • Choice – flexibility, autonomy and decision-making. Balance – can have too much Choice
  • Equality/Fairness – Access to resources and information
  • Predictability – Resources, time, direction and future challenges. Right level of predictability
  • Significance – status, visibility and recognition

Core needs vary depending on individual

Desk moves – emotional impact across cove needs

"Some groups had choice, we didn't"

Knowing and addressing core needs is a shortcut to making others feel understood and valued.


  1. Observation of a behaviour – factual, not assumptions
  2. Impact of behaviour – describe in a way they will care about
  3. Question or request – action to change it. Ask open questions to start a dialogue

Ask about their preferred feedback medium

Team Processes

Retrospectives – normalise talking about team health

Team charters and docs

Venn diagram of responsibilities

Product manager drives "what", Tech lead drives "how", Engineering manager drives "who"

Em n El n PM drive "why"

"Product manager + tech lead scope and estimate project work"

Take care of yourself

Distance yourself from unhealthy work environment

I can't do that for you Dave: undefined is not a function

Asim Hussain – @JawAche

AI + JS @aijavascript


TensorFlow, MobileNet & I'm fine


Engage teams to achieve high performance

José Caldeira – @Jose_E_Caldeira

High performance in 5 steps

1. Goal – OKRs/KPIs

Bold not reckless

Crisp not fuzzy

Impact not vanity

Simple not complex

2. Constraints

Embrace don't fight it

Impose don't wait

Mandatory not optional

3. Principles

Options not restrictions

Align don't Impose

Focus not an obstacle

Fast not slow

4. Pitch

"We need to sell everything"

Energize don't discourage

Promote don't wait

Consistent not occasional

5. Storytelling

Empathy not a report

Path not the result

Truth don't lie


  1. Memorable goals
  2. Creativity through Constraints
  3. Autonomy with Principles
  4. Motivation by pitching
  5. Engagement by telling stories

Bottoms up with OKRs

Whitney O'Banner – @WooBanner

Objectives & Key Results

  • Set goals
  • Align teams
  • Quantity Progress

We will (objective) as measured by (key result)

TIP: Skip individual OKRs - Try tasks instead

Ignore the metrics Focus on outcomes

SWAG = Sophisticated Wild Ass Guess

Avoid cascading goals Take a bottoms up approach

"Having goals improves performance. Spending hours cascading goals up and down the company, however, does not"


  1. Try tasks
  2. Focus on outcomes
  3. Take a bottoms up approach

What on earth does it mean to build AI software?

Ronald Ashri – @ronald_istos

AI = delegating decision making to machines

How do we describe and build systems where decision making is delegated to machines?

Thinking of the what before delving into the how

Agent-based engineering

Agent is an object that has goals

Software is a passive agent – allows us to achieve our goals rather than having its own goal

Active agent has its own assigned goals

Pro-active – has increased self-direction. Proactive rather than reactive

Autonomous agent – generates goals based on its own motivations

Data-driven and model-driven AI

When we delegate decision-making to machines we need a model of the world. something to base our decisions on. How do we derive that model?

Design the model

Newton physics equation - apple falling

Explicit model used to represent reason. Very efficient.

Discover the model

Use data to work out the model

Data used to learn patterns or behaviours or to make predictions

Machine learning

e.g. image recognition

Validate the model

Applications are hybrids

Google Maps: Model of road network for directions from A to B. Data to predict traffic conditions to find the efficient route

Guiding self-organising teams

Rebecca Hill – @Rebekaka


  • Set directions

  • Design the teams

  • Manage work

  • Execute tasks

  • Have a vision

  • Trust the team

  • You will fail – learn from it together

  • People are unique, so are teams

  • You can't do it all

  • Be kind to yourself and others

  • Perfection doesn't exist - and that's ok

People come first. They take time. They are worth it.

12/10, Excellent doggo: the power of positive transformation

Heidi Waterhouse – @WiredFerret

How do I get developers to write docs?

Never punished or rewarded – why would people bother?

Behaviour: A team effort to meet a shared goal

Training theory

Rewards positive behaviour until done automatically

"Do the thing I want – get a treat"

Positive Training Incentives

  • Rewards
  • Praise
  • Excitement
  • Treamwork
  • Mutual care and goals


What causes a behaviour?

Goals + Action + feedback

How do we change behaviours?

Clear Goals

Everyone has goals

Not all of us are clear about our goals

Respect others' goals

Achievable steps (atomic steps)

What is the minimum viable goal?

Reward – the learner chooses the reward

Successive approximation

Examples in corporate life:

Making Work Visible (Book by Dominica DeGrandis)

  • Think clearly about everyone's goals
  • Figure out rewards together
  • Commit for the long term

The reality of testing in an artificial world

Angie Jones – @TechGirl1908

How do you test machine learning?

Learn how it learns

  • As technology, so must our test approaches

  • The need for automation became much more apparent

  • There was still a need for thoughtful and critical thinking

  • Plain old common sense can still trump an algorithm

  • Security

  • Privacy

  • Ethics

  • Bias

Don't think of it as a magical black box

The future is here... test it.

A Team in Ten Minutes

Steve Williams – @StickyWilliams

RNLI – Life boat teams rapidly form when called – responding to a crisis

Cynefin Model (Dave Snowden)

  • Complex
  • Complicated
  • Chaotic
  • Obvious

RNLI from acquiring skills to the application of those skills to solve a real-life problem

Team building without knowing when we'll need it, what we'll need it for or who will be involved

Anatomy of an exercise

Get a list of potential crisis team candidates

Ask for their involvement

Make it part of their job

Divide them into 'crews'

How do you build the crews?


Defined roles

Cultural rituals

Regular meetings

Strong social elements

Preparedness for the real crisis

Level up: developing developers

Melinda Seckington – @MSeckington

Games increasingly complex which requires time and effort to master. Like mentoring teams.

Strategy: "Grow our own software engineers"

Internal Developer Experience

Variation of UX

Understanding motivations, emotions and behaviours

Game user experience provides a similar environment

10 Lessons of Game Design

Not gamification. Using examples from games.

A: Starting a new games

Phased introduction of controls to ease into learning

Don't overload new starters

Onboarding checklist

Trello template - copy for each new starter

Support and guide new starters

Provide a mentor

Make it clear what people should focus on – goal setting

Regular check in on goals – not yearly

Tie in with bigger picture career goals

Share goals with team members – someone else may be able to help and support

B: Learning a new skill

Give people direct and timely feedback

Encourage direct feedback


  • Difficult Conversations how to discuss what matters most (Douglas stone et al)
  • Thanks for the feedback (Douglas Stone and Sheila Heen)

Provide space to reflect and learn from the past

Self Reflection - retros for team but rarely for individuals

360 feedback

(15 5 tool for feedback)

Provide opportunities to apply new skills

Identify training

Learning events and groups:

  • Talks we love
  • Learning behaviours
  • Architecture club
  • Front end catchup
  • Conference club
  • Leadership study group
  • Book clubs & course clubs

Internal Learning

C: Levelling up

Acknowledge people's growth

Regular salary reviews

Expose basic competencies and how they're punished Competencies and skills

  • Curiosity
  • Communication
  • Technical skills
  • Team work skills
  • Initiative

Allow people to choose their own path

Generalise or specialise

Visualise what progression looks Like

Career progression framework

Linear framework (junior -> mid -> senior) – not always good

Modular framework better

What I learnt about hiring diverse teams from conducting a fully-anonymous recruitment process

Bethan Vincent – @BethanVincent

Managers like to hire people like themselves

  1. People want to showcase "soft" skills alongside "technical" ones
  2. Jobseekers want a human connection (+ they want the lowdown on what it's really like to work with you) – felt inhuman
  3. Lengthy tests and at-home exercises are not inclusive
  4. Your job listing is just as important as the application process
  5. If we really care about diversity and inclusion, we need to listen

Volunteers, not conscripts: fixing out-of-hours on-call

Brian Scanlan – @Brian_Scanlan

Virtual team of volunteers

github flow for on-call alerts

Give 10%, get 110%

Kate Beard – @SBinLondon

It's ok to have a life outside your job

Faster development + still getting free time

Drive by Daniel H. Pink (book)

Autonomy, mastery and purpose.

Autonomy -> Mastery

Give people trust; give people permission; and then give people room to learn and grow by doing what they know they need.

Eiffel's Tower

Nickolas Means – @NMeans

Flavours of technical leadership

Pat Kua – @PatKua


"The are only two hard things on computer science: cache invalidation and naming things"

What is leadership?

"The ability to lead"

"The act of leading a group of people"

What is Technical Leadership?

Start as a maker From maker to multiplier

Make other makers more effective

A multiplier has more impact


Career paths – shared expectations. Some don't want to be boxed into one title or role. Art and trick to have a path which flexible, but not too complex.

The more impact the further into a role you go from junior to mid to senior to lead

Two track model of career development - Popular in US

Individual contributor on one side, growth path on the other

Trident model

  1. Technical Leader
  2. Individual Contributor
  3. Management

Shared path before you diverge - gives the contract to manage or lead appropriately

Need to understand nature of building software

Formal & Informal views

Formal brings Autonomy brings responsibility and accountability

Informal is safer introduction to leadership

Some problems need someone to dive in a specific way – depth of impact. too many introduce SPOF


4 Flavours

There is so much to learn

People interested in helping other people learn

Create learning opportunities for people

Learning isn't a zero-sum game

Seniors learn from juniors too

Feyman Technique – when you can't explain something you know in clear concise terms, maybe you don't understand as deeply as you thought you did

"The person who says he knows what he thinks but cannot express it usually does not know what he thinks"

@ruthmalan "The architect's clue bucket"

Knowledge cultivator

Constantly Learning

Powerful Questions

What do you think about y?

How would you solve this?

Open questions. How and what

Getting buy in for a solution

The Advocate

Needs patience

Relentless Focus

Continuous integration

The connector

Organisations not hierarchy, but a network

Introductions. sponsor a colleague

Lend your privilege

  • experience
  • connections
  • likeable

The Storyteller

Many flavours of technical Leadership

Every leader has their own style – discover your own flavour

Inclusion starts with an I

Dora Militaru – @DoraMilitaru

Business as usual: how to stop drowning and learn to swim

Jonathan Stott – @Jonathan_Stott

The one with the problem

  • What is BAU?
  • Bug fixing
  • Customer Support
  • Manual Processes
  • Infra maintenance
  • Legacy code
  • db admin
  • not interesting
  • keeps the lights on
  • "beneath me"
  • urgent?

Why is it a challenge?

  • overwhelm
  • overlooked
  • not enough time or brain power allocated to it
  • takes time
  • poor use of skills
  • cause of stress

2. The one with the kiwi

  • Kiwi toy for people responsible for BAU and answering Questions
  • rota systems
  • everyone gets to experience it – all get to learn and share knowledge
  • still requires support from other team members
  • never plan non-BAU for person with the kiwi

3. The one with the project which will not start

  • Deluged by BAU
  • Say no to stuff
  • Rigorous triage process
  • What is important, what is urgent? – keep doing it
  • Risk assessment
  • Ring-fence a person for BAU – creates an artificial ceiling as a rate limit. Forces people to make a choice over what is important

Contract out some work but keep the cool/interesting stuff for perm team

Find a common need from the business and from dev

Consider moral of those in the team ring-fenced into this work - Provide them some variety

4. The one where everyone leaves

The 3 "ations":

  1. Documentation
  2. Simplification
  3. automation

Write everything down


Question anything we do – does it all have value


Think about when to automate

The one where the leopard changes it's spots

Rebranded BAU to "Support and maintenance"

Allowed for a change in priorities in how the work was managed

The one where we fixed some things


The one with the new role

New role - technical support engineer

Aim is to automate themselves out of the role itself to move from TSE to full developer role

High level of autonomy to work out how they go about this task

Unblocks the rest of the team

Do still require support and mentoring from others

Helps up-skill other devs by introducing mentoring

The one with the cliffhanger

Multiple approaches – choose the appropriate one and change as needed

Adapt approach over time

Behind the scenes of an effective & inclusive hiring process

Ola Sitarska – @OlaSitarska

Making it a fair process for Everyone

Effective & Inclusive?


  • Inclusive: measurable and objective evaluation important to eliminate bias
  • Excellent candidate experience is a priority
  • Hires the right candidate for us: our environment & culture

Define who the right candidate is & building the pipeline

Requirements can be too eliminating based on a specific path Women known to only apply to roles where they meet 100% of requirements

Best indicator of someone performing well in the job is evidence that they successfully done similar work in a similar environment

1. Hire for the job you have

Define the job & responsibilities

In the next 12 months... we will be doing

2. Be transparent about what the job is

Publish it on your website - ideally with a salary range!

3. Build a representative pipeline

  • Inclusive practices and culture attracts diverse candidates
  • Hire diverse candidates in leadership first
  • Invest in outreach

Can be a hard challenge

Design how you gather & evaluate information

1. Define what information you need

2. Design how you'll gather that information

Keep it efficient

Ensure it is relevant to the job

Gathering information

  • In 30 minutes asses that the candidate is looking for what we can offer to them and has relevant experience. Get them excited about the company and set expectations.
  • Asses that the candidate can solve a simple problem that they'd find at work, in a similar environment. Ask for code review to and understand values alignment and communication style.
  • Ask for a code review to and understand values, alignment and communication style.
  • Provide useful feedback to candidate
  • By going through candidate's work history, gather evidence of them doing the job you defined in an environment & culture similar to yours

Instead of asking how they break down a big problem, actually ask for actual experience of when they have done this – more evidence based

3. Fight your biases!

All of us have implicit bias built in – find ways to fight them

Code test

Code review is done blind – no name/details of candidate included

Coding task scorecard – keeps things consistently and objectively scored

Evidence based review

Interview stage

  • Representative panel
  • Evidence based scorecard
  • Standardised list of outcomes
  • Neutralise your first impression
  • Introduce a lead to drive conversation and evaluators to listen and take notes
  • Score on a 1 to 5 scale


Ask for evidence

Don't take opinions as facts

Use the same rubric for evaluating both candidates and employees to ensure you're hiring the right candidates

Setup your candidate for success

1. Remember it's a two-way street

The candidate is also evaluating you – think about what's important for them

2. Minimise the stress

Interviews are stressful for most. People generally perform better when they're not stressed

3. Care about their experience

  • Let candidate interview at preferred time, and be efficient
  • Don't create artificial deadlines on accepting the offer
  • Get back to the candidate quickly with useful feedback

"You've nailed the candidate interview experience when they reject your offer but still recommend you to their friends"

Start improving tomorrow:

  • Get real clear on what success looks like for someone doing this job
  • Make coding test relevant
  • Blind review code test
  • List 10 examples of evidence of previous experiences you need
  • Spreadsheet for scoring candidates against criteria
  • Speed up interview process and feedback

Mobile development in 2019: native vs cross-platform

Miriam Busch – @miphoni

Is there a simpler way than specialist team for iOS and Android

React Native

  • Some limitations
  • Some performance issues
  • One platform for both iOS and Android
  • Core being re-written to improve performance and consistency across the two


  • C# based
  • Shared logic, differing UI


  • Rendering by Flutter engine
  • Material Widgets, Cupertino Widgets for Android/iOS respectively

Kotlin Multiplatform

  • Two apps
  • Shared library in Kotlin – shared business logic
  • Multi platform libraries
  • Still early stage but popular

1. Focus on features

  • Don't build the same features twice
  • Reduces friction.
  • Platform specific bugs still exist but as the exception rather than default

2. There is no such thing as a free lunch

  • Remove doing everything twice
  • But introduce new complexity with new tech
  • Additional cost in other areas (performance, app size, start up time, OS consistency)
  • Still feels like an early stage of a lot of these platforms
  • Cross platform will always lag behind pure native
  • Everything evolves very fast and needs to catch up

3. Supporting 3 platforms instead of 2?

  • airbnb dropped React Native because it almost become its own platform

4. Cross-platform thinking

  • Even on two Native tracks can still encourage cross-platform thinking
  • Pair iOS and Android developers together?
  • Can't share code, can share ideas

No silver bullet

Pick what is right for you and your team, with your team

Building security culture on infrastructure teams

Franklin Hu – @ThisIsFranklin

Critically important to consider security as a design constraint


  • Building and maintaining trust
  • Scaling with growth

What do we want in our security culture?

  1. learning and growth
  2. Empathy
  3. Responsibility


Learning and growth

Fail in a safe and supporting ways No shaming

"Shame erodes our courage and fuels disengagement" – Brené Brown

Learn from mistakes, don't shame


Diverse & Dynamic -> Disagreements

Approach with Empathy

Thou shall not use...

Sometimes security team do need to speak in absolutes, but aim to speak with empathy and consideration

Culture focused on solving problems

Recognise disagreements often from diverse in the context of teams or individuals


Security is everyone's job

Can't bolt on after the fact

Developers have most context for the problems they are solving

Built the right tools and abstractions to reduce surface area a developer needs to think about

Of the three, without any of them security becomes someone elses job. Makes security difficult to implement



Find security-interested people

Give people the opportunity to learn and grow

Rotations! – Move people around on a temporary basis

Builds context and relationships

See things from a different angle

Security advocates

Formalise the volunteers into security advocates or champions

Point person on their team


Foster a positive culture of learning

Discussion and presentation forums

Talks/white-boarding/lunch & learn

Tabletops & Game days

@badthingsdaily for tabletop scenarios for tackling security issues

Cross functional scenarios: legal, engineering and regulatory

Game days: What happens if we kill -9 redis?

shipped@/fixed@ – tell people when changes have been made and how/what we learned

security-shipped@/pre-shipped@ – more focused groups for smaller teams and targetted audience

Shipping emails are a great design tool – helps crystallise your goals and expected impact

Stripe – increment magazine


Security review?

Context, context, context

Stripe game days blog post

Why we should be scared of Shor's Algorithm right now?

James Birnie – @RunningChairJB

Navigating front-end architecture like a Neopian

Julia Nguyen – @FleurChild

Often start as a generalist before becoming more of a specialist

Front-end architecture is more than laying foundations. It's about upholding, improving, and evangelising standards.

Personal bias always impacts architectural decisions, so it's important to determine whether it benefits the codebase and the people who work on it.

Often times, we choose the option that is most convenient given time and resource constraints.

Migrating jQuery to React

Storybook to build in components

Moving to a new architecture is incremental, so it's important to document its progress.

  • Stack
  • Migrate one component at a times
  • Supporting internationalisation in both client and server
  • Making a more client-friendly API in Rails
  • Onboarding

Headspace spaceManaging microservices End-to-end testing across services, leveraging Cypress and improving through minor mocks

While working on a greenfield product is an excellent opportunity to make decisions that reduce technical debt, it's important to strike a balance between this and shipping features


Don't become gatekeepers – keep communication open

How long is a piece of string: the key to solving the consundrum of software estimation

Jonathan Rigby – @jonrigby1975

We always get it wrong:

  • Use "expert" estimators
  • Compare with historical projects
  • Gut feel
  • "Double it to be safe"
  • T-Shirt sizing
  • Storypointing
  • Cocomo II Estimaste Formula

It always take longer.

No Estimates?!

"I'll ask you for an estimate then treat it as a deadline"

Without estimates, no gantt chart 😂

Planning is needed to know where to put our efforts

Is there a third way?

Key ingredient is trust

Important between tech and product

Maximise trust:

  1. Make and keep the commitments you can – give quality demos
  2. Be transparent – don't hide behind tech speak. Fail and be honest creates safety
  3. Don't overdo things – we don't help ourselves if we over complicate things
  4. Show empathy – product have their own pressures from stakeholders, they have to convey our info to them
  5. Educate them – give them examples

Very important task for lead developers

Imports our developers significantly – adds the unhealthy pressure on the team if not tackled well

Impacts mental wellbeing and relationships

Silence isn't golden, it's deadly!

Paula Kennedy – @PaulaLKennedy

In teamwork silence isn't golden, it's deadly


On-site teams, distributed. Hard to feel like part of a bigger team

Trying to improve

  • Communication
  • Trust
  • Culture


  • Always do 1-2-1s
  • Weekly standup – help requests, interesting finds, upcoming events
  • Weekly "teach me something"
  • Monthly retro
  • Quarterly "virtual" off-site


  • Google's Project Aristotle
  • Psychological safety
  • Active listening
  • Mindful communication
  • Resilience


  • Off-site
  • Team swag
  • Team mascot
  • Virtual "coffee break/happy hour"
  • Shout outs
  • Celebrate achievements

Leading the team through a rapid growth

Joanna Chwastowska

Be clear about tradeoffs in technical design

Technical debt will start accumulating. IT will not go away on its own.

One approach is to let it get so bad you have to do a rewrite. Alternatively address as you go to avoid the build up.

Depends on status of product – early start up or established?

It's important for us to decide our choice of trade off and to communicate it with the rest of our development team

How risk-tolerant and error-tolerant are you? Can you afford errors?

From day one build with quality, security and privacy in mind

Hire experts – even if just one person on the team understands security and privacy have them available. Not just to sign off – use their expertise.

Hire external companies to black-box test the system. Show you are interested in finding those vulnerabilities.

Put thw team at the heart of everything

Most important asset of the company

Hiring new people changes the team significantly

More people aren't always right – sometimes it means a lose of focus

Never lower your hiring bar – especially due to a deadline. Almost good enough, isn't good enough.

Be very intentional about diversity. Think about the team you are building and what it should be like. Teams should be long lived.

Look out for signs of team burnout

Easy for people to think they must work hard just until the next deadline. Weeks becomes months become years. It isn't sustainable.

Work so that people can deliver whilst having their own lives at the same time

Monitor for the teams psychological safety

New members on the team whilst the core team are already extremely busy is very risky and means could lose the culture of the team – damages psychological safety and feeling of appreciation

No "heroes" attitude

Communication – ensure it is kept open and intentional

Build mechanisms for teams to communicate, and roles to communicate across teams

Ensure roles and responsibilities are clear

Communication top down and bottom up are both important

  • Be clear on the goal
  • Communicate openly
  • Hire responsibly
  • Care for people

Facilitation techniques 202

Neha Batra – @NerdNeha

  1. Set
  2. Engage
  3. Include
  4. Finish


  • Agenda – inclusive when used correctly
  • Timeline – when do things start and end
  • Check you are spending time in the right places
  • Helps introverts know when to speak up
  • Embedded breaks
  • Gives quiet time – recharge time
  • Helps those in other meetings or teams – gives a time for checking notifications/emails
  • Cross out agenda items once covered to keep the transition clear – stand next to the agenda item when time is overrunning
  • Go bag with all equipment you need


  • Sharing

  • Struggles

  • Solutions

  • Action Items

  • Pairs

  • Individuals

  • Share (Voluntary, Each)

  • Board

Mix of contribution/sharing styles throughout the meeting

Facilitating vs talking


Assign roles within the session


Include all personalities

Steamrollers vs quieter folks

Round robins with post its

Encourage everyone to speak

Dot vote helps give everyone a voice – no longer the voice of most vocal/senior person

Give people a warning of when people are going to share – helps quieter people

Rules: 3 people speak before you speak again - Used as a fallback/last resort if required

Take a break when things get heated


Finish with a bang

  • Appreciations
  • Retros
  • Swag/memorabilia

A button to pause time: how to live outside the clock

Sal Freudenberg & Clare Sudbery – @SalFreudenberg @ClareSudbery

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment