[Lead Developer Conference] Day Two

From 11-12 June, over 20 Automatticians attended the Lead Developer conference in London and we took extensive notes. At Automattic, we promote a culture of learning and our attendance at this conference provided some of our team leads with a valuable opportunity to reflect on and develop their own leadership tools.

If you are interested in Automattic and the roles we have available, we’re hiring!

Flavours of technical leadership

Pat Kua: Chief Scientist – N26 www.thekua.com @patkua

Talk Intro:

Over the many years, Patrick has trained, coached and mentored many engineers into Technical Leadership roles. He is delighted by the way that everyone has their own style and “flavour” of being a Technical Leader. In this talk, he will explore what technical leadership is and the impact people can have through their individual flavours of technical leadership.

Having run leadership courses many times for different people, there are many different types of technical leadership. We each have unique flavors, defining our own personal style.

Where do people demonstrate technical leadership?
How do people demonstrate technical leadership in typical patterns?


“The ability to lead”. With Carol Dweck’s concept of the growth mindset, leadership is a trait that you can grow and develop.

“The act of leading a group of people ” It’s broad and inclusive. A single step or action of doing something and taking people with you. Anyone can be a leader. All you need to have is the courage to take action and this act of leadership.

There are four flavors of tech leadership:

The Knowledge cultivator

There is so much to learn: You simply can’t be an expert in everything.

Something that emerges from this ecosystem is that you have people who enjoy helping others to learn. They look for and create opportunities for learning. This act of leadership is really important. It has a big impact.

What does this person get as a result? It isn’t a zero sum game. It’s not like they are taking something from you. When you teach, you end up learning things more deeply: The Famen learning technique.

The Advocate

An interesting side effect of learning is making mistakes. A consequence of mistakes is that there are often pain points that teams feel. Some people notice this, listen to the pain points from different perspectives and decide to do something about it.

“What’s troubling you about X?”

“What do you think about Y?”

“How would you solve this if you had time?”

This act of leadership needs to get buy-in for the solution and influence people to get buy-in that this is something worth doing.

People who take on this leadership role often possess relentless patience.

The Connector

You may think of organizations as hierarchies, but they can be thought of as networks.

Sponsor someone. Invest social capital. Lend your privilege.

“Let me introduce you to X”

“Y can help you with this”

To be a good connector, you need to think about your reputation score

The Storyteller

These are people who can inspire and contextualize things for others.

People who can create the vision and bring people along the journey

There are many flavors of tech leadership – the only limitation is yourself. It’s about creating an environment for people to thrive. It’s about remembering that everyone has their own style and invest in helping people find their own flavor.

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

Jonathan Stott: Technical Architect – Royal Pharmaceutical Society www.rpharms.com @jonathan_stott

Talk Intro:

One of the challenges facing teams, particularly small ones, is having to balance the time spent on doing fun new things and having to support old (or antique!) systems and processes. These are the ‘business as usual’ (BAU) things which probably underpin the current revenue of your business. As such they are critically important but are almost certainly unloved and possibly even loathed by the teams responsible for them! BAU includes fixing bugs, handling support problems, running regular or ad hoc processes, and dealing with legacy systems amongst other things.

You will learn: how and when to say no; when to take time to fix and optimise; how to deal with a deluge of BAU; how to manage people working on BAU; and what we experienced when we were getting it wrong and finally when we got it right!

This is a story about the team maintaining Business As Usual (BAU) whilst working on projects

The one with the problem

What is Business As Usual?

  • Customer support
  • Infrastructure maintenance
  • DB Admin
  • Bug fixing
  • Legacy code
  • Manual processes

It is also:

  • not interesting
  • distraction
  • “beneath me”
  • keeps the lights on
  • urgent – someone might die!

Why is BAU a challenge?

  • Overwhelming – it feels like there’s no way to see beyond
  • Overlooked – not enough time allocated because of other stuff
  • Poor use of skills – people doing it need to be engaged enough
  • Cause of stress – have to do a lot of extra work to keep on top of the BAU workload
  • Increase turnover – more leave than you expect
  • Can feel insurmountable – can’t see a way beyond

BAU: 20% to 100% of the time: there are lots of systems and services to support.

Because of problem domain, quality and precision are very important.

There was once a situation when the team couldn’t start a project for 12 months because couldn’t get around the BAU.

The one with the Kiwi

This is a token that sat on someone’s desk to say you could come and ask them about problems; that the person who held the kiwi was dealing with BAU. Everyone in the team – without exception – got to experience the BAU work: learning and sharing the knowledge.

  • You have to support the person doing looking after the BAU, especially if documentation is not good.
  • Don’t plan for people scheduled to do BAU to do anything else but BAU.
  • Have to ensure you are fair: if someone has leave booked for the BAU time, they have to pick up their BAU responsibilities when they return.

The one with the project that will not start

There are times when you feel you are drowning in BAU. More than you can do with the number of people in your team. There were times when they had to say no.

  • They needed a really rigorous triage process.
  • They had to dig into what’s important vs what’s urgent.
  • They had to do it again and to make sure they were really sure.
  • They had to do a risk assessment of the work – what’s the impact of things not being done?
  • They ringfenced one person, then limited them to only doing that.
  • They contracted some stuff out – however it was hard to contract out BAU, mainly because of lack of documentation. But they knew they shouldn’t give all the fun work to contractors.
  • They looked for some common aims. They figured out value for doing things.

The one where everyone leaves

They prepared for the worst scenario. What would you do if everyone but you leaves. What happens if you leave, and the rest of your team have to do the stuff that only you know?

  • Three “ations” – documentation / simplification / automation.
  • Documentation – write everything down. People don’t like it but it’s important.
  • Simplification – question everything that you’re doing. Does everything you do have value? Just because it’s been done before doesn’t mean it has to be done again.
  • Automation – think about when you should be automating it. Processes stick around for longer than you expect, so think about that when you think about time saved. It is not just about time saved, also about quality: fewer human errors.

The one where the leopard changes its spots

BAU became a toxic term. So, they rebranded it to “supported maintenance”

  • They took the opportunity to consider the situation and changes priorities about how they managed this work.
  • This meant not just changing the logo.
  • How would you go through a corporate rebranding process? The whole business had to be involved in the mission, goals, values and tone.
  • The tone is interesting – how you communicate things, do you communicate in a way that other people can understand.

The one where we fixed some things

This was a period of consolidation. It was a process where the whole team looked at what can be improved.

  • It started with a list of ideas, then the team prioritized and decided upon each point.
  • The team is main product owner for consolidation work.
  • But they couldn’t neglect stakeholders within the rest of the business.
  • They worked on bug fixing, refactoring, work on “ations”
  • They identified things that would allow the team to learn.
  • It was important to repeat this process: it is not a one-time only thing.
  • They still have to focus on BAU whilst consolidating – it does not go away immediately.
  • What they decided upon had to be achievable: it had to be broken down into smaller tasks like planning a sprint.
  • They needed to be able to finish what they decided upon in the time they had.

The one with the new role

They hired a technical support engineer – main focus of this role is to do the BAU, and improve it over time.

  • They had an unwritten goal: the Technical Support Engineer was tasked to automate themselves out of the role altogether and become a developer: this created a progression opportunity
  • That became the transition path from technical support engineer to developer.
  • It was a fantastic job to do if they were new: they learned a lot, and got involved in everything.
  • Because of that, it can be fun. The person has some independent identification or problems, solutions and autonomy. It was a great way to motivate.
  • The greatest effect of this role was that it unblocks the team.
  • This role would still needed support so they introduced mentors

The one with the cliff-hanger

  • There were no silver bullets or magic wands but the process introduced lots of inspiration
  • It’s important not to stick with one approach forever
  • Processes must evolve and adapt over time
  • Don’t lose heart!
  • It might be frustrating but patience and motivation will pay dividends

Behind the scenes of an effective & inclusive hiring process

Ola Sitarska: VP of Engineering – Verve @olasitarska

Talk Intro:

In my role as a VP of Engineering at a fast-growing startup, I spent hundreds of hours interviewing and sourcing candidates in the last year alone. The bar we set ourselves was high: not just hire people with excellent skills and culture add, but also maintain and improve our current diversity (33% women, 9% people of color) across experience levels. The result of that is an inclusive and effective hiring process that lets us successfully grow the team while providing a great candidate experience. Even candidates who reject our offers end up recommend us to their friends! This talk will take you through a step-by-step hands-on guide on improving your skills as an interviewer and setting up a better hiring process at your company – no matter how large or tiny.

In the current role:

  • They grew team from 10-35 in 12 months
  • This included 30% gender minorities, 13% PoC
  • There is a 40/60 gender split in technical leadership

The objectives were:

  • The process had to be inclusive: measurable and objective evaluation to eliminate bias
  • Excellent candidate experience is a priority
  • It was vital to hire the right candidate for us: our environment and culture.

They were a very small startup, with no ‘big name’ or reputation to rely on. So candidate experience was a priority – particularly when they were being evaluated against bigger, more well known brands. They had to show their best selves.


  • Define the right candidate and build the pipeline
  • Design how you gather and evaluate information
  • Set your candidate up for success.

Defining candidate:

  • You can look for people who are like the good people who are currently in roles
  • Be aware of asking for too many requirements: this excludes people who took a different path in life
  • Be certain that requirements aren’t eliminating people with more diverse backgrounds
  • Be mindful that women hold themselves to higher standards (they tend to only apply if they meet 100% of the criteria), so don’t include requirements that aren’t necessary.
  • The best indicator of someone performing well is evidence they successfully did similar work in a similar environment.

Define what the job is:

  • Hire people who have done it before.
  • “Performance profile” – drop the list of requirements, instead list expectations of the role. Illustrate what success look like.
  • Help candidates self select out of the process – maybe can do it but don’t want to.
  • Be transparent about salary range.
  • Build representative pipeline:
  1. Inclusive practices and culture will attract diverse candidates
  2. Hire diverse candidates into leadership first
  3. Invest in outreach

In a homogeneous culture we have to work harder to prove broader spectrum of people can be successful. Building a diverse pipeline is hard work.

Gather and evaluate:

  • Define what information you need
  • Decide how you’ll gather that information
  • Ensure the efficiency of this process
  • Ensure it’s relevant to your job
  • Fight your biases

The process became:

Phone screen:

  • 30 minutes to assess the candidate is looking for what we can offer them, and has relevant experience.
  • Get them excited about the company and set expectations.

Coding test:

  • Assess that the candidate can solve a simple problem that they’d find at work, in a similar environment.
  • They asked for code review to understand values alignment and communication style. They assessed that the candidate could solve a simple problem that they’d find at work, in a similar environment.
  • Give them feedback.


  • †The candidate was invited in for an interview: this was time-boxed to 2.5 hours in order to respect the candidate’s time.
  • Here they outlined how things within the organization work and explained the sort of candidate they were looking for.
  • The candidate’s work history was explored, in order to try and gather relevant evidence of them being successful, and to ensure they have been doing it in a similar enough environment.
  • They asked questions requiring real stories and evidence: not just theory.

Eliminating bias:

The code test was blind code review:

  • Test is uploaded, and all identifying information is removed
  • The scorecard in held in a spreadsheet, ensuring that each engineer that reviews code test is consistent with the rest.


  • Having a representative panel is important as it ensured a representative decision.
  • An evidence based scorecard was used, with a standardized list of outcomes
  • In the interview they had one person leading, whilst the others focused on listening.


  • Always ask for evidence
  • Always consider facts, not opinions

It is important to use the same rubric for evaluating both candidates and employees. Performance on the job should have the same expectations as at the interview stage.

Set your candidate up for success:

  • Remember that it’s a two-way street. The candidate is also evaluating you.
  • Try to minimize the stress – interviews are stressful, but people generally perform better when they are not stressed.
  • Genuinely care about their experience.
  • Give the candidate their preferred time, and be efficient.
  • Don’t create artificial deadlines.
  • Get back quickly and 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 clear what success looks like
  • Make your code test more relevant
  • Blind review code test
  • List 10 examples of evidence of previous experience you need
  • Create a template to score all candidates against the same 5 criteria
  • Evaluate if you can make your process shorter

Mobile development in 2019: native versus cross-platform

Miriam Busch: CTO – Karlmax Berlin GmbH & Co. KG @miphoni

Talk Intro:

We’re 10 years into Android and iOS development and there are more ways to build an app than ever before.

Let’s look at the options, be it native app development or cross-platform systems like Xamarin, ReactNative or Flutter: What is core to these frameworks? What implications do they bring to your product and your development team?

We are now more than a decade into iOS and Android development.

Developers for mobile are becoming more and more specialized.

Is there a simpler way?

Let’s visit 4 alternatives

React Native

This was created by Facebook: UI and logic created in JavaScript. It is not web view based, and the rendering is done by native components. There’s a rendering bridge that components need to cross, meaning that there are some limitations and performance issues. But developers still use native for some UI. The core of RN is currently being rewritten, but it won’t be ready this year.


This brings C# and .net development to mobile. The logic is in C#, native UI components. When Xamarin forms are introduced, a shared UI is possible for both platforms.


This was introduced by Google in 2017. The UI and logic is written in Dart, and is shared between both platforms. The Flutter engine does all the rendering, but has a rewrite of UI components.


This is multi-platform, more lightweight. It shares logic written in Kotlin, and the UI written for both platforms. We can use Kotlin multi-platform libraries for networking etc.

When the team first switched to multi-platform, it was a relief. There was no longer a need to write things twice, and platform bugs became the exception.

But there is no such thing as a free lunch

Although they removed the need to do everything twice, they introduced a new complexity due to the inherent architecture of the system. For example, rendering the bridge in RN, bundling .net with your app, and the Flutter user experience. It feels like it’s still early for the platform, and the cross platform system will always lag behind.

Should we be supporting 3 platforms instead of 2? Airbnb gave this reason for sun-setting RN support. It’s important to remember that you still need specialists!

Cross platform thinking

This is not just about technology but taking ownership for those platforms. Even if you’re just sticking with two platforms you can still encourage cross platform thinking.

The answer?

It depends! Miriam’s team decided on Flutter, but it depends on the individual business needs.

Leading the team through a rapid growth

Joanna Chwastowska: Engineering Lead – Google DeepMind Health

Talk Intro:

Team leadership and technical leadership come with a variety of challenges and require various skills. One of them is an insightful future outlook and being ready for what’s yet to come. Working on a new project, or joining a startup – there’s an expectation for your team to grow. Growth is good. The more hands on board, the more you can achieve. But it’s not all roses. In this talk we’ll look at challenges and risks related to the fast growth of an engineering and cross-functional team. How to notice the first signs of the change? When to react? How to keep your team’s culture when growing? What will have to change, what can stay the same? Summarizing past experiences – from bootstrapping a remote team from zero to 20 people, as well as growing DeepMind Health engineering team from 20 to 80 in a bit over a year – there are patterns emerging that can help other teams avoid pitfalls that come naturally with a rapid growth. At the end of this talk you should be aware of what changes to expect as your team grows, how to notice critical inflection points, and react to them so your team comes out bigger and stronger.

The reality is that most hospital systems aren’t as advanced as they could be, nor are they operating well with each other

With a mix of paper records and many systems — how do you make a dashboard?

A Pager is a very primitive version of a mobile phone – it only displays the number that is trying to reach you. A Doctor would come out of surgery with 20 pages. They can’t know who needs them or why. Someone might be dying!

Even in leading hospitals technology is not what it should be. They will say they use “mobile technology” but what they have is called “computer on wheels”.

In 2016 a few people started to look into whether it’s possible to create a mobile app to deliver important info to clinicians, nurses and doctors, and improve the delivery of healthcare. The good news was yes it’s possible – and this is now in live deployment in two hospitals in London.

The spectrum of what can be addressed is so broad, but they needed to start with something small enough and traceable enough that it can be measured.

The team developed an app to quickly diagnose Acute Kidney Injury by measuring blood samples and alerting staff when symptoms existed – proving that it is definitely *possible* to focus and deliver impact.

The report says that technical interventions give them 2 extra hours a day face time with patients.

The team quickly went from a few people to a hundred and fifty.


From start up to an established team, what were the important aspects:

  • Be super clear about trade-offs in technical design.
  • Google operates at scale. But start ups need to move fast and evaluate.
  • Through that fast evaluation, learn and find your niche in the market.
  • This does not go well with technical scale.
  • You will start accumulating technical debt, it won’t go away on it’s own you will have to address it.
    • Approach technical debt: put it off, or constantly think about it.
    • Either approach is fine, but be intentional.
    • Know the domain.
    • Have the time now or in the future.
    • It is not just leadership that needs to understand, the team needs to be on the same page.
    • How risk tolerant and how error tolerant are you?
    • In regulated environments, you probably cannot afford risk of leaking user’s data.

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

  • It can’t be applied as another layer.
  • Security and privacy is something you build on from ground up.
  • It is crucial for financial or medical information.
  • Hire an expert, and include them in conversations.

Put the team at the heart of everything.

  • They are the most important asset of your company.
  • It is easy to forget this in times of fast growth. It started from everyone knowing and trusting everyone.
  • You add one person at a time, but soon you realize you don’t know some people on your team.
  • Hire responsibly. Whenever you hire a new person, make sure you need them – don’t just hire because you can.
  • Scrappiness forces focus on the most important thing.
  • Don’t lower your hiring bar.
  • Be intentional about diversity. It is tempting to hire what is on the market, but think about the team you are building.Who do you want on that team? What will the team need to deliver on?
  • Look out for signs of team burnout. It is easy to focus on just the next deadline. We have to learn to work in a sustainable way.
  • People should be able to deliver results and live their life at the same time.
  • Monitor for team psychological safety. It is easy to lose the sense of the culture of the team: are people feeling safe? Can they question decisions?
  • It is important that people feel appreciated.
  • Communication: it is not just about making it open and intentional. It is about how you scale your communication as the team grows. We need to build mechanisms for teams and roles to communicate across.
  • Ensure that you, as a leader, understand how your team feels, and how people perceive decisions. If this communication breaks down, you will not know what is happening on the ground.
  • Be clear on the goal – not just you and leadership, but the whole team needs to know what’s happening.
  • Care for people. Other things may change, but if you have a strong group of people who can build things together, that is the biggest power you have.

Facilitation techniques 202

Neha Batra: Engineering Manager – GitHub medium.com/@nerdneha @nerdneha

Talk Intro:

We’ve all had that experience where we’ve planned the perfect discussion only to have it hijacked by a passionate side-person, lose focus halfway through, or produce the exact same takeaways as you had before you began the discussion. With a few tricks in your back pocket, you can recover from some of these tricky situations or even prevent them in the first place! I’ll share some of my best techniques and provide some yellow flags I’ve learned to recognize that signified needing to make a change.

Set the stage

  • When facilitating an event, come in 30 minutes before the meeting to prepare. Think about what is on the desk and the messages that they are conveying to the delegates.
  • The use of chairs allows for the facilitator to transition between roles.
  • Agendas are great for aligning goals and packing in the information needed for inclusive audiences
  • Start and end times – identifies when people need to speak and what they need to speak about
  • Include breaks – human care, allows thinking time after important points are made
  • Check off the items of the agenda as you’ve completed them
  • Keep people to their time slot
  • Have a ‘Go’ bag containing materials (post its, markers, erasers etc)

Engage your group

  • Sharing – sharing ideas, thoughts and feelings
  • Struggles – identifying challenges
  • Solutions – finding fixes to the challenges
  • Action items – identifying action-based tasks

Exercises may include (and should be shared ahead of time to allow for personal preparation):

  • Splitting into pairs
  • Share back
  • Writing
  • Contributing

Facilitating vs talking (assign roles to others who are keen)

As facilitator, you shouldn’t need to do all the talking throughout the meeting. Be careful how to phrase your questions to ensure others engage and do more of the talking!

Include all personalities

  • Steam rollers vs quieter folks
  • Post-its and round robins
  • Museum walks – present ideas through flipcharts and have everyone walk round and ask clarifying questions
  • Share 1 idea
  • Dot vote – good to see what people want to prioritise
  • Breakout groups
  • Time to think before sharing
  • Rule: let 3 people speak before you speak again
  • Take a break when things get heated
  • Retros using post-its and dot votes

Finish with a bang

  • Appreciations
  • Retros
  • Swag/memorabilia

Challenge Tweet: what is the one thing you want to try at your next meeting

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

Sal Freudenberg: Chief Being Sal Officer – Cucumber Ltd salfreudenberg.wordpress.com @SalFreudenberg

Clare Sudbery: Lead Consultant Developer – ThoughtWorks medium.com/a-woman-in-technology @claresudbery

Talk Intro:

How does time impact on your working day? Would you like to hack time and live outside the clock? The answer is likely to be yes.

In October 2018, Sal and Clare took an all-female team to Hack Manchester, built a time machine and won Best in Show. They are now taking their time machine on tour: You too can press the button and stop time. Have a nap, play tricks on your friends, or force the trains to be on time.

Seriously though, repeated research has suggested the straitjacket of standard working hours does us all no good at all. Nor does the “always on” culture perpetuated by the speed of innovation and delivery in the world of software development. Yet we are all still stuck in our rigid working cultures. This light-hearted talk has a serious message: Don’t assume your teams have to be imprisoned by time. Try a little experimentation and see what a difference you can make when you play with expectations and give your people some time-based freedom.

Time travel for the win!

At Hack Manchester, the team were dedicated to self-care, instead of pushing themselves too far, eating unhealthy and staying up too late. They all rested and slept. They undertook a lightweight form of Agile. They used story maps. They had 1 hour iterations, involving 45 mins working, 5 mins retro review, 5 mins break away from desk.

So why didn’t everyone do this?

Not enough sleep

We don’t always want to sleep because we want more time to do things. But then we pay for it the next day.

Humans sleep in cycles that typically last 90 mins long

The SleepCycle App can be installed on your phone. Here, your phone ‘listens’ to breathing and moving, and it deduces sleep cycles from this.

Why do we need to sleep?

Sleep deficiency affects mood, learning, focus, reactions and emotions. It creates lots of physical and mental health issues.

Humanity is bartering the most blessed thing there is: sleeping

Larks vs owls

Larks are early risers and owls prefer to work late into the night

Most people fall into one of these categories, but some can fall in the middle of these two

Larks are in the majority which is not surprising given the society we live in. We think owls are a bit lazy for not getting up in the morning. But from an evolutionary psychology perspective, it makes sense to have people who need to sleep at different times: it reduces the hours of vulnerability.

Spoon theory

If we start the day with 12 spoons and each tasks uses a certain amount of spoons, there will come a point in the day when we run out of spoons. This has been adopted by the neurodiverse community. It demonstrates the need to recharge. But don’t forget that we can’t calibrate spoons between different people: different activities take up different ‘spoons’ for different people.

Flexible working

Sleep matters, rest matters and being a parent can confuse this.

It is important to give parents the flexibility to do wrap around care

And it’s not just about parents: we should be allowing all people to work flexible hours. It allows for self-care, caring responsibilities, or for just getting the boiler fixed.

If you don’t pay attention to people, they will lie to you, and say they are fine when they’re not. This can cause absenteeism and disengagement.

Structured Days

However, not everyone works well with the concept of a flexible day and structure is key for them…..it important to not create an environment of exclusion when trying to encourage inclusion.

So what works and what’s needed?

Self awareness

Self care

Empowerment: be flexible about flexibility

Clocks and time does not have to be our master – everyone has different needs and these should be acknowledged and addressed

[Lead Developer Conference] Day One

From 11-12 June, over 20 Automatticians attended the Lead Developer conference in London and we took extensive notes. At Automattic, we promote a culture of learning and our attendance at this conference provided some of our team leads with a valuable opportunity to reflect on and develop their own leadership tools.

If you are interested in Automattic and the roles we have available, we’re hiring!

Navigating Team Friction

Lara Hogan: Co-founder – Wherewithall

Talk Intro:

Friction is a common, and necessary, part of team growth—but when left unchecked, team friction is unhealthy for you, your coworkers, your company, and ultimately your end users.

In this presentation, I draw on my experiences at organizations large and small to illuminate the sources of team tension, how you can better understand and manage unexpected teammate reactions, and the best ways to give actionable feedback without escalating drama. Your coworkers, your organization, your users, and you will reap the benefits.

A study found that even when surgeons rotated shifts to different hospitals, only get better in their own hospital. This suggests that teams are crucial.

Teams of humans are amazing. Groups of people coming together to ship things is amazing.

Bruce Tuckman talks about the theory of group dynamics and the stages of group development:

  • Forming: team has a name, some understanding of why they are there.
  • Storming: start to see some friction. Clashing and confusion.
  • Norming: things start to iron out, resolve difference, start to find groove.
  • Performing: things are really smooth.

This process occurs every time the team changes, but storming is so painful. But it is critical – we can’t get to norming except through that stage. We have to feel equipped to handle it.


Pre-frontal cortex – deep, complex problem solving

Amygdala – gather data from the environment and figure out threat.

If enough threat, the amygdala shuts down pre-frontal cortex and takes over.

When the amygdala hijacks at work it is not useful. It responds to perceived threats even outside physical safety.

Human beings have six core needs to feel secure at work:

  • Community, connection.
  • Improvement / progress.
  • Choice – flexibility, autonomy, decision making.
  • Equality / Fairness.
  • Predictability – resources, time, direction, future challenges.
  • Significance – status, visibility, recognition.

Not all core needs are equally important to everyone.


Humans are mostly terrible at giving feedback. We are also mostly terrible at preparing to receive feedback.

We are afraid of having our core needs challenged.

Feedback of equation:

  • Observation of behavior – not about what you feel or assume. Factual.
  • Impact – describe something they care about.
  • Question or request – ask genuinely curious open question, help them to determine the way forward.

We should ask about their preferred feedback medium.

Team Processes

Each teammate has a different way of working. The important thing here is whatever your processes are, that you’re iterating on them, and that they are working for everyone.

Retrospectives help, as it creates a habit of talking about team health. They can help us meet core needs.

People who are willing to acknowledge their own failures are more trusted.

Team charters and docs give clarity about what’s expected of us. Having a mission makes it easier to give feedback on things that don’t align.

Throughout this process take care of yourself, and do what you need to do to distance yourself from an unsafe environment. If you aren’t sure if it’s time to walk away, speak to someone you trust.

Team health is a cycle. Team health is a thing you can continually improve.

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

Heidi Waterhouse

Developer Advocate – LaunchDarkly

Talk Intro:

How many talks, articles, and podcasts have you seen about organizational change, and how to implement it? How many of them talked about what we can learn from non-human psychology? This is that talk.

I’ll give you concrete and actionable advice for how to make change happen in your organization, one person at a time, by being nice. Make it rewarding to do the right thing, and people will do the right thing more often. Understand that people are motivated by different things and you’ll be able to talk to them more effectively. Inspirational leadership can only get us so far, and we can do the rest with hard work, consistency, and compassion.

It hurts to get fired and it’s hard to talk about. But dignity is for people who aren’t conference speakers.

What would your work life be like if you, and the person who reports to you, and the person who you report to you, had shared goals that you could agree on?

How do you get developers to write docs?

  • Very few devs like writing docs
  • Very few managers are good at getting people to do something they hate to do

Have you ever fired a dev for writing insufficient docs? This never happens.

Have you ever promoted someone for writing excellent docs? Maybe once in a while.

If you say you want it but you don’t reward it, and you don’t punish it, you don’t really want it.

Behavior: team effort to meet a shared goal.

Positive or training shaping isn’t new: from how you teach whales to jump through hoops, to getting cats to act in movies. At the simplest level: the trainer offers a reward until trainee starts offering the behavior spontaneously. They train to exhibit the behavior after a cue.

Dogs used to be trained using shock collars and by yelling at them.

We trained children and employees in the same way (but fewer shocks). You can get the good behavior, but not the good relationship.

Have you had that manager who criticizes you all the time? We then give them rent free space in our head.

Instead we should be incentivizing the good behaviors through using reward. This rewards the good behavior.

A lot of what we call goals are a set of interdependent behaviors and decisions. We have to be clear about what the atomic unit of a goal is. What is the minimum viable behavior that we are going to reward? the goals for other people are just as relevant, but often conflicted.

So how do we change behaviors? How do we make developers write documentation?

  • Can’t achieve anything without knowing what we’re aiming for.
  • Everyone has goals.
  • Not all of us are clear about our goals
  • We must respect others’ goals.

When you look at your goals, are you sure you know what you’re doing? What they’re used for? If you don’t have that alignment, then you might do the wrong thing.

Trying to do a lot of things at once is overwhelming. You don’t (usually) learn to swim by being thrown in a lake. Complex movements, need to be taught and learned incrementally.

We should break tasks down into things that can be rewarded. Then, the person doing the thing needs to choose their own reward. It needs to be meaningful for them. When trying to motivate someone, it’s important to ask them what they want, what would make them happy.

Successive Approximation:

Dr Skinner trained pigeons to drop bombs accurately. You can teach almost anything to almost anyone if you can figure out how to ask for it in small enough increments with enough reward.

We invest a lot in thinking about ourselves as positive and rational beings. We’re not rational, we’re just playing rational on TV. People mostly do what they get rewarded for and avoid doing things they get punished for.

Writing documentation is too big

A blank page is the abyss.

Try creating a template: then they are not writing documents, but answering questions.

Some things to remember:

  • Think clearly about everyone’s goals: if you can’t write it down, it’s amorphous and squishy and no good. If you write it down and it looks like it came from a management book, it’s still no good.
  • Figure out rewards together.
  • Commit for the long term. Do it consistently until it becomes intrinsically rewarding, not just extrinsically rewarding.

Engage teams to achieve high performance

José Caldeira: Head of Development – OutSystems 

Talk Intro:

When bootstrapping new teams, they need to go through the standard process of forming, storming, norming and performing. And in the context of fast-growing companies, with their own level of uncertainty, how can we achieve high performance when teams and goals are constantly changing? How do teams deal with different degrees of uncertainty? And how can leaders support them in feeling safe and motivated?

Throughout the years, I’ve found some ways to help teams achieve this. Some of those were a direct result of my experience, others were inspired by my peers and other companies, and others I was able to derive from coaching sports or teaching people. In this session, we’ll talk about some of the ideas leaders can implement to help teams move faster into high performance.

Teams can achieve high performance in 5 steps:

1. Identify Goal

Sports psychologists agree that high performance is connected to highly intense goals. So how do we engage the team? The goals we decide upon must have impact and meaning.

We must define the goals that will be memorable:

Bold… not reckless

Crisp… not fuzzy

Impact… not vanity

Simple… not complex


Definition of the goal then creates a sense of control. By encouraging teammates onto a project, we create a personal development opportunity: 

Embrace… don’t fight it

Impose… don’t wait

Mandatory… not optional

3. Principles

Principles must be agreed upon and aligned within the team

Options… not restrictions

Align… don’t impose

Focus… not an obstacle

Fast… not slow

4. Pitch

We need to sell everything – we need to remember that the goal should create a sense of urgency.

We create a positive message in order to sell and motivate

Energize… don’t discourage

Promote… don’t wait

Consistent… not occasional

5. Storytelling

Humans use storytelling to pass to the next generation. We can use the same strategy but we must remember that creating engagement shouldn’t involve creating a lie

Empathy… not a report

Path… not the result

Truth… don’t lie

In summary:

  • Create memorable goals
  • Creativity through constraints
  • Autonomy through principles
  • Motivation by pitching
  • Engagement by telling stories

Bottoms up with OKRs

Whitney O’Banner: Engineering Manager – Braintree @woobanner

Talk Intro:

In 2013, Google famously published a leading reference for establishing Objectives and Key Results as a way to align teams and set short-term goals. While some of the information is still relevant, it is time to take a fresh look at setting OKRs within your teams. This talk will help leaders abandon the dated, flawed approach to setting OKRs and enable organizational alignment in an exciting new way, suitable for 2019.

OKRs are commonly used, but they produce variable results in both experience effectiveness.

e.g. ‘We want to improve accessibility as measured by 75% WCAG compliance’

Objectives and Key Results

We set goals

We align teams in a shared vision

We quantify progress

We will <objective> as measured by <key result>

It is often introduced from the mindset that we know how to do this well, but most of us don’t.

Here are three brief but key strategies to adopt:

TIP: Skip Individual OKRs

Try tasks instead

Remember that company level objectives are not individual tasks

Individual OKRs are like corporate meetings, they slow us down and don’t give value. Skip the big picture and instead focus on the individual. If not, they will turn into tasks or micromanagement, and become less about alignment.

Try to move from team level OKRs to tasks, initiatives, projects. Your team will love you, because they want to focus on the work. This empowers employers with priorities.

TIP: Ignore metrics, focus on the outcomes

It was discovered that a lot of what they thought mattered was not being measured. Most key results were “swags” – sophisticated wild ass guess. Is it reasonable? Feasible? Achievable? Good? No one knew. They spent a quarter hitting baselines, instead of hitting goals.

Instead, forget the numbers, and concentrate on the measurable outcome

Re-evaluate this once you understand what your team is capable of

e.g. improve accessibility as measured by WCAG compliance: start with general outcomes, and after a couple of quarters then you can set some stretch goals.

TIP: Avoid cascading goals: take a bottoms up approach

This takes way too much time and stifles innovation. HBR found that most managers overvalue their ideas by 42%. Front line employees undervalue theirs by 11%.

Instead, take a bottoms up approach. It helps spark innovation and fosters the best ideas if employees can understand how they can build impact.


Try tasks

Focus on outcomes

Take a bottoms up approach

Guiding self-organizing teams

Rebecca Hill: Frontend Engineer and Team Lead – WeTransfer rebeccahill.co.nz @rebekaka

Talk Intro:

It’s all well and good for the agile manifesto to recommend self-organizing teams, but what does that actually mean in practice? What’s the best way to do it, how far should you take it? Total anarchy is probably not the answer here… right?

After bouncing around leading a whole bunch of teams of different shapes and sizes over my career, I have some insights into how to guide effective self-organization and create amazing teams. I’ll also share plenty of battle stories, including major re-organizations of entire engineering departments, structured completely by the developers in them.

Whether your entire department needs shuffling, you’re starting a new team, or just adding a new team member, you should walk away with plenty of ideas of how to guide your team to make the best possible decisions – for themselves.

Self organizing teams is an umbrella term for a spectrum of team organizing styles:

  • self governing – set direction, design the team, manage work, execute tasks
  • self forming – design the team, manage work, execute tasks
  • self organizing – manage work, execute tasks

Then, more traditional manager led teams – just executing tasks.


Rebecca lead a team of mainly brand new people to the company. This was a rare opportunity to start from scratch:

  • here was a group of people who cared about each other
  • who wanted continuously to get stuff done
  • wanted to have fun doing it

How long do you think it would take? A couple of months?

They started off with sessions to figure out how to work together, and everything up was up for the team to decide. Having everyone decide this stuff together was very powerful, and it meant that everyone was really invested.

The team would advocate for standard structure and keep iterating on it. They kept a team agreement document – this helped with onboarding.

They talked about values. The top two were motivation and honesty.

They chose team name together: picked Cosmos.

They felt really optimistic… but then shipped a bunch of bugs. They were too new to the code base and each other.

They ended up with people struggling to work with each other, and with people from other teams.

They began taking part in workshops on active listening. It is a simple concept, but how rare is it to feel fully listened to! They got good at asking questions and listening to the answers. They began to give specific feedback. It’s important not to forget to challenge your high performers – you should be spending as much time on them as everyone else on the team.

Do not underestimate the amount of time good leadership and management. When you have a responsibility towards people, they have to come first. If you’re struggling, look after fewer people, don’t just look after the people you have less.

Remember to authentically celebrate success.

Be positive.

Don’t fake it, but do make the time to give praise and positive feedback.

Did they reach the vision?


But that’s because the vision was whack.

That vision of perfection? NO.

The vision of #BestTeamEver? Hell yes!

In summary

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

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

Bethan Vincent: Head of Marketing – Netsells www.netsells.co.uk @bethanvincent

If we want to truly encourage diversity in our industry, we are going to have to listen and respond to feedback from under-represented groups that challenges our assumptions.

We spend so much time and attention on user research, user feedback and service design but when it comes to recruitment we seem to lose the same motivation. By taking the time to step back and see what our processes are saying to candidates, we can ensure that we are taking steps to increase diversity awareness. It might not be easy, but it’ll be worth it!

There was a common problem: they wanted to hire a diverse team.

They decided one way to get people in was to improve the way they hired.

They noticed that managers tended to hire people who are like them. If you have mostly white dude managers, you tend to hire mostly white dudes.

So they built a totally anonymous application system.

  • Anonymous application (with a mobile number), five skills the applicant felt they had, five skills they wanted to learn.
  • Slack interview
  • Technical test
  • Then come into the office – at this point they had to de-anonymise people.

They got some good press. They thought had solved it. But they realized they weren’t the same people as their applicants!

So they went to conferences and spoke to a lot of people. They also approached successful and unsuccessful candidates.

They learned a lot from this exercise.

People want to showcase “soft” skills alongside “technical” ones.

  • They found women felt uncomfortable listing their skills. You have to explicitly tell people you want to hear about them.
  • Women were put off by the anonymous platform.

Job seekers want human connection (+ they want the lowdown on what it’s really like to work with you)

  • Minorities tend to speak to people before joining, “what’s it really like”.
  • You can let them go around your process, but why not make it part of the process?

Lengthy tests and at home exercises are not inclusive.

  • This is particularly gendered. People with caring responsibilities do not have time.
  • It’s a facility that it rules out people who are “not committed” – they have lives and other things to do.

Your job listing is just as important as the application process.

  • Vague job postings: if something is not explicit, people will fill in the blanks with doubt.
  • Then, if you’re ashamed to fill in the blanks, you’re doing something wrong.

If we really care about diversity and inclusion, we need to listen.

  • †Had good intentions, but built something for them.
  • Status quo holds certain people’s values, the world is tailored to them.
  • Don’t just say “thanks for the feedback”, if you really care you do something.