(melodious instrumental music) (audience applauding) - Thank you.
Who recognises this slide? This is probably the top front end slide of 2017. And this is from Cristiano Rastelli talk Let There Be Peace on CSS.
He's making a point about how we're thinking differently about separation of concerns in our code bases as engineers. But similar thing has happened to the structure of organisations in recent years. It is now most popular to organise your teams not by function but by business mission and you bring together people of different skill sets, different roles in these cross-functional teams. Traditionally, leadership has been about control. The leaders in an organisation were responsible for knowing everything, for making good decisions using that knowledge and then for telling everyone what to do and how to do it. And this form of leadership works okay in the traditional functional model of an organisation. You just put your best designer back end there and front end there in charge of each of those teams, they'll tell everyone what to do and it'll be fine. But how do you lead the front end engineers across an organisation when they are spread across all these different teams? It seems like a good time to remind you that I'm the director of Front End Engineering at a place called Culture Amp.
When I joined three years ago there were 10 people in the product team and we are 80 people today.
Which means we have doubled in size three years in a row, which is a heck of a thing to keep up with. We sell a product for improving your company culture, which means that we have to be super intentional about how we think of things like leadership. Probably the number one source that we've taken for inspiration at Culture Amp is this book, Team of Teams by General Stanley McChrystal. It tells the story of the US Joint Special Operations Task Force which under McChrystal's leadership from 2003 to 2006 defeated Al-Qaeda in Iraq by adopting some of the same methods that made that terrorist group so effective. If you're a little creeped out right now, join the club. The idea that the US military, let alone a terrorist organisation might form the blueprint for your successful tech startup, it's a bit weird.
And I don't know about you, I didn't get into web development to feel like I was in the army, right? This turned me off the book for quite a while but I recently had kind of an aha moment about this stuff that I'll share with you at the end.
For now, I think we can summarise this book in a single slide like this.
The book is basically saying that in today's fast paced highly interconnected world there is so much complexity that it is foolhardy to optimise an organisation for efficiency when what you should be optimising for is adaptability. They're saying that in this really complex environment the fate of your company could come down to how the people in your organisation respond to a single completely unpredictable event, maybe something as small as a tweet.
This is a story that I don't have to tell you because we all read about it when it happened last year. For our purposes today, we know now that United Airlines like many airlines have a routine practise of over booking flights to maximise their operational efficiency.
And they have strict procedures that go along with that policy.
When this crisis hit the headlines the first public statement made by the CEO was in support of his people because they followed those strict policies. Now what this book is saying is that in this day and age you do not want people who follow strict policies, you want people who can be adaptable.
The point if we put in engineering terms is that premature optimization is the root of all evil. And if you're optimising for efficiency it will always be premature because we can't predict the future anymore. So in a model like the one on the left, if suddenly something in the world changes and you have to do a whole lot more front end engineering and a lot less back end engineering you're in big trouble because you've organised your teams and given people roles that are strictly associated with a particular kind of job that maybe you don't need them to do anymore. Where in the model on the right, you generally have roles that are blended and people who learn skills from each other in these teams by Osmosis.
And so if you suddenly need people to do a bit more front end engineering you just ask them to.
So, adaptability over efficiency is kind of what this book is all about.
And in order to achieve it, it says that you need to focus on creating two things. Shared consciousness, you want to give everyone as much information about what's going on as possible.
And empowered execution, you trust them to use that information to make decisions. To illustrate what this looks like, I'll divert a moment into the world of bees. Nobody panic.
Here we have a typical open plan office.
Now when a bee finds a new source of nectar, it does this thing called a waggle dance.
And it communicates to the other bees the distance to the new source of nectar by the duration of its waggle.
And it communicates the direction to the nectar in relation to the sun by the angle of its waggle in relation to the honeycomb beneath their feet. I learned about this somehow as a kid on Sesame Street or something.
And I think when I first saw this I must have thought something like, "Wow, that bee is on the fast track to a corner office." Because this bee is acting like a leader, right? It's telling the other bees what to do.
Or is it? If you go to the Wikipedia page for this, there's one of those headings controversy.
Don't you hate it when you find one of those? Well the waggle dance controversy is because over the past 10 years or so, scientists who study bees have discovered that in some populations, as many as 93% of bees that watch a waggle dance then just go back to a source of nectar that they already knew about.
About and the prevailing theory is that bees will actually only follow a waggle dance when it is advantageous to do so.
Usually it means that they are in an environment where nectar is hard to come by, like a rainforest. And so that bee is acting as a leader but not because it's telling the other bees what to do. It's because it's acting as an information radiator and it's empowering all the other bees to make their own decisions about what to do with that information.
So this is shared consciousness and empowered execution. This is exactly what this book is talking about. And in this kind of organisational model, leadership is definitely not about control anymore. These traditional roles of leaders are now spread throughout your hive if you will. So what do leaders do in a team of teams structure? Well at Culture Amp we talk a lot about leadership in terms of accountability.
By definition maybe, being a leader means being accountable for more than your own individual contribution. And some of the things you can be accountable for at Culture Amp are team performance, development of individuals, technical outcomes and strategic vision and I'm going to tell you some stories about each of these. So, team performance.
If you are a leader responsible or accountable for team performance at Culture Amp, that probably makes you a team lead.
Good team leads are people who nerd out about how a group of people can come together to solve a problem.
This is Virginia Murdoch.
One of our team leaders at Culture Amp casually tweeting on a Friday afternoon about a new idea for running meetings for her team. This is Jack Dorsey on the left talking about how most of the meetings he participates in now are written meetings that start with 10 minutes of silent, writing and commenting in a Google Doc.
And Virginia is wondering if this model could work well for her team which has several members for whom English is not their first language. That this is casual Friday afternoon tweeting for Virginia tells me that she is probably a very good team lead. As a team lead you also need to get comfortable with leading more experienced people.
I once had coffee with a new team lead for a new team at Culture Amp and he wanted my advice because he was worried that there were people in this team who knew his job better than he did and he didn't feel comfortable making decisions for him. And I said, "Welcome to team leadership, "it sounds like you have a great team." As a team leader you don't make most of the decisions for your team.
Something we've gotten really good at asking out loud at Culture Amp is, "Who is the right person to make this decision?" Often, this is easier to decide on as a group than the decision that needs to be made.
And then you trust that person to make the decision and it is usually in a team not the team lead. But some decisions are right to be made by a team lead. This is a story that my colleague Jo Cranford who you met earlier, she tells about when she was the lead of a team and they had just finished like a full quarter of aggressively shipping features. And she was getting feedback in her team retrospectives from the engineers saying that they were having trouble keeping up that pace because they had accumulated some tech debt, things were slowing down, it was not a good time. And she talked with her engineers about it, she talked with the product manager in her team. And then as team lead she made a decision and she decided that that team would spend the next four weeks shipping no new features, working only on product health.
And she tells this story because it was the first time she remembers being trusted to make a decision with that level of impact for the company.
She didn't have to check with anyone or get anyone's approval.
And the response when she announced this decision from the higher ups was, sounds like a team lead decision to me.
So, that's team leadership.
Next up, development of individuals.
If you are accountable for the development of individuals at Culture Amp that usually makes you a mentor.
This is what we call your manager at Culture Amp. They are the person who looks after your career progression, evaluates your performance and determines your pay and when you're due for a promotion.
As a mentor you support your mentees career goals even if it means moving them to another team or supporting them in moving to their next job outside of Culture Amp.
Your number one job as a mentor is to be great at giving feedback.
You need to be your mentees most trusted source of feedback. And if they are facing a challenge, they need to hear about it from you.
Which means never failing to acknowledge when there's an issue.
And definitely never saying something slightly different in their performance review than what you said to them face to face.
This can be surprisingly hard at times.
And everything I've learned about being a good mentor lately has come from this book Radical Candour.
You thought this was a talk about one book, there's two books in this talk.
This book is almost becoming a cliche in our industry, but some things become cliches because they are just so good.
And this book calls walking the line between ruinous empathy and obnoxious aggression is what being a good mentor is all about in my books. At Culture Amp your mentor is usually not even in your team. And this has a nice side effect because some of the things that you can't say out loud to the people you collaborate with day to day, you can say out loud to a trusted mentor who is not in your team.
Here's some things that my mentees have told me over the years.
"I think I was promoted too early." This engineer was suffering from the pressure of now being at the same level as some colleagues that they had previously looked up to and they were feeling crushed by the imposter syndrome. We had some great talks about this.
And the only reason this engineer felt safe sharing this with me as their mentor, the person who evaluates their performance is I was already giving them lots of feedback from other sources.
So they didn't feel like anything they told me would immediately be used against them.
Another my mentees told me that they got a job offer and could I help them decide what to do.
This wasn't the shock you might expect because my mentee and I had been discussing their next career move for some time.
In this case, they had gotten an offer for more money but the team, the mission, the workplace at the new company were much less of a good fit for them.
We talked it over and this engineer is actually still with Culture Amp today. But I don't tell this story because I saved a flight risk or something like that. Because if this engineer had left us for a better job, that would have been a victory of a different kind for me as their mentor. Our CEO talks about three stages of mentorship that we want to embrace.
As a baseline your managers should be looking after their people.
But you want them to level up to taking pride in their people's accomplishments and even taking pride in their people going on to bigger things.
I would love to one day say that three engineers that I had mentored were now CTOs at other companies.
That would be really special.
Next up, technical outcomes.
You might be thinking, "I'm not that great with people, "this is code leaders after all. Can I lead with code?" And maybe that means you should be a tech lead. But, spoiler alert, tech leads need to kind of be good with people too, unfortunately.
Here's a story of when I was a tech lead of a team and we had to make a choice between two stacks on the front end.
Other teams at Culture Amp had recently gotten good results with adopting React. And our team was about to undertake a brand new Greenfield user interface project. And as the tech lead, it was my responsibility to decide what the stack should be. In fact, at that point it wasn't even a question. Everyone else was using react.
It's this emerging industry standard.
Why wouldn't we use react? But we had a new engineer joined the team, his name was Markos.
And in his first week he said to me, "Kevin, I know we're all using React here "but I've been experimenting "with this language called Elm in my spare time. "And from what I've learned "it has all the same benefits of React "but it has some other benefits on top of it. "Is there any chance we would consider using it here?" And as the tech lead, it would have been really easy to say no.
It was the safe choice.
It's the IBM, no one gets fired for choosing React, right? (audience laughing) But...
But I realised in that moment that I would have been making that choice from a place of ignorance and fear.
And so I said to Markos, I said, "I'll make you a deal, "you go and build a new screen in React for two weeks "and I will go and build and screen in Elm for two weeks "and at the end of it we'll compare notes." And at the end of those two weeks he said, "Okay, I know React now. I still like Elm better."
And I said, "I'm completely head over heels "in love with this Elm thing.
"Can we use it everything going forward?" And that's what that team has done ever since. All of that teams UI's are done in Elm, and increasingly our other teams are choosing it too. Today, about 50% of the new user interface code that we build at Culture Amp is written in Elm. And that's what being accountable for technical outcomes looks like. Oh, I should mention, Marko's today, tech lead of that team. Strategic vision is the last thing I'll touch on. And at Culture Amp being responsible for setting a strategic vision is being a practise lead. And this is what I am learning how to get good at right now as director of front end engineering.
Your job is to repeat this vision that you have devised over and over again, in as clear terms as possible to anyone who will listen until they are saying it back to you.
But it's not just about leading from above, you also spend a lot of time and effort on promoting good information sharing across your practise. So at Culture Amp in front end we do this with our front end practise meeting, which is a meeting that happens every two weeks. We bring together front end engineers from all our different teams and they do some show and tell to show what is going on in each of those teams. And when we first started these meetings, I noticed right away two pretty unhealthy patterns. The first was, that an engineer would get up, give a really polished presentation about a piece of work that they had just finished. And then all the other well meaning engineers in the room would pick it apart with questions of, why didn't you do it that way? Did you consider this? There's something similar already in the library over there, why didn't you use it? And the engineer who presented this work would inevitably leave the room feeling kind of deflated and defensive.
I heard some laughs in the room, so I know, you sympathise with these engineers. So I made two changes to this meeting to fix this. The first was, I made a rule of no slides.
I didn't want anyone doing up a slide deck for the front end practise meeting.
I wanted to really lower the bar for sharing information in this meeting.
And then the second was that I made a rule that we should share work as early as possible. Ideally, before you've even started building the thing. Because that is the right time to get feedback from your peers about how you're about to do a thing.
Not when you've just finished it and you've got your sense of pride all tied up in it and you're gonna feel defensive about any suggestions. So now that we do this, most of our presentations are just an engineer scrolling through their code editor, pointing at things that they might be about to do, and the conversation is completely different. This is now my favourite meeting to go to every two weeks and I think a lot of our front end engineers feel the same way.
So, those are our four accountabilities.
And I'd like to finish by asking what we've learned about leadership. And to answer that, let's return to my thoughts on this book.
This book is about 1/3 stories of people fighting and dying retold as examples of good or bad management practises. That may not bother you but it did bother me. The good news though is that there are hopeful stories in this book too.
There's an entire chapter about NASA in the 1960s and how they completely reorganise themselves to make possible the landing of Apollo 11 on the moon by the end of that decade.
That was incredible.
And then there's chapter 11 which is entitled leading like a gardener.
As a gardener, you fertilise the soil, you pull the weeds, you make sure every plant is getting the right amount of water and sunlight. Which despite what Ryan will tell you about cactuses is not always that easy.
You ideally have some kind of plan for how things are gonna go, but as a gardener you don't always get to choose what will grow where.
And so whether you're representing a cross-functional team as a team lead, guiding the development of individuals as a mentor, applying technology to benefit the business as a tech lead or creating alignment between teams as a practise lead. The role of the senior leader is no longer that of controlling puppet master but rather that of an empathetic crafter of culture. I'll remind you that I get to go to work every day at a place called Culture Amp.
So this quote obviously appeals to me.
But it is not just the mention of culture that I like, it's the mention of empathy.
In a book full of war stories, I really wasn't expecting that.
And it was this quote that made me realise the point. The point that McChrystal and his co-authors are making is not that the methods of war are the secret to business success, the point is that there is no context less soft and fluffy than the military one.
And if distributing the control of leadership across your organisation and replacing it with empathetic crafting of culture will work in the military, then it'll work almost anywhere.
Being a great leader is putting yourself in the shoes of the people around you and then building connections between them that will lead to success.
Culture Amp's model is not perfect, we're tinkering with it constantly.
But I hope by sharing some of it, I've inspired you, the gardeners of your own teams to do some empathetic crafting of your own cultures. Thank you.
(melodious instrumental music)
