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?
Leadership
“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.
Process:
- 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:
- Inclusive practices and culture will attract diverse candidates
- Hire diverse candidates into leadership first
- 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.
Interview:
- †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.
Interview:
- 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.
Debrief:
- 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.
Xamarin
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.
Flutter
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.
Kotlin
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.
Scaling
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
