Lead Dev Conference 2019
https://www.sli.do (code: leaddev)
Navigating team friction
Lara Hogan – @Lara_Hogan
Storming -> Norming
- Team Processes
- Belonging – part of a group
- 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.
- Observation of a behaviour – factual, not assumptions
- Impact of behaviour – describe in a way they will care about
or request– action to change it. Ask open questions to start a dialogue
Ask about their preferred feedback medium
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
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
Embrace don't fight it
Impose don't wait
Mandatory not optional
Options not restrictions
Align don't Impose
Focus not an obstacle
Fast not slow
"We need to sell everything"
Energize don't discourage
Promote don't wait
Consistent not occasional
Empathy not a report
Path not the result
Truth don't lie
- Memorable goals
- Creativity through Constraints
- Autonomy with Principles
- Motivation by pitching
- 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"
- Try tasks
- Focus on outcomes
- 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 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
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
Design the teams
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
Rewards positive behaviour until done automatically
"Do the thing I want – get a treat"
Positive Training Incentives
- Mutual care and goals
What causes a behaviour?
Goals + Action + feedback
How do we change behaviours?
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
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
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)
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?
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
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
(15 5 tool for feedback)
Provide opportunities to apply new skills
Learning events and groups:
- Talks we love
- Learning behaviours
- Architecture club
- Front end catchup
- Conference club
- Leadership study group
- Book clubs & course clubs
C: Levelling up
Acknowledge people's growth
Regular salary reviews
Expose basic competencies and how they're punished Competencies and skills
- Technical skills
- Team work skills
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
- People want to showcase "soft" skills alongside "technical" ones
- Jobseekers want a human connection (+ they want the lowdown on what it's really like to work with you) – felt inhuman
- Lengthy tests and at-home exercises are not inclusive
- Your job listing is just as important as the application process
- 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.
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
- Technical Leader
- Individual Contributor
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
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"
What do you think about y?
How would you solve this?
Open questions. How and what
Getting buy in for a solution
Organisations not hierarchy, but a network
Introductions. sponsor a colleague
Lend your privilege
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"
Why is it a challenge?
- 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":
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
- 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 review is done blind – no name/details of candidate included
Coding task scorecard – keeps things consistently and objectively scored
Evidence based review
- 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
- 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
- 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?
- learning and growth
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
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?
fixed@ – tell people when changes have been made and how/what we learned
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
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.
- Migrate one component at a times
- Supporting internationalisation in both client and server
- Making a more client-friendly API in Rails
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
- Cocomo II Estimaste Formula
It always take longer.
"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
- Make and keep the commitments you can – give quality demos
- Be transparent – don't hide behind tech speak. Fail and be honest creates safety
- Don't overdo things – we don't help ourselves if we over complicate things
- Show empathy – product have their own pressures from stakeholders, they have to convey our info to them
- 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
- 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
- Team swag
- Team mascot
- Virtual "coffee break/happy hour"
- Shout outs
- Celebrate achievements
Leading the team through a rapid growth
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
- 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
Share (Voluntary, Each)
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