(upbeat electronic music) (applause) - Thanks John.
I actually thought that name was really boring so I changed it.
So today I'm gonna talk about how continuous delivery killed my culture and if my story resonates with you, I'm also gonna talk about how we fix it, so stick with me.
So when I was a junior developer, the way we would deploy to production would be to take a floppy disc over to the dev machine, move across all those handcrafted JavaScript HTML files and DLLs, take it into the server room, that was on prem, put it into the server, upload those files, maybe restart IAS, (laughter) pray for the best.
It never worked, never worked the first time. So then it was all hands on deck, call in the seniors, call in anyone that could help, what is DLL hell? How do you fix that? Oh, look, the server hasn't been patched in a while. We better do that 'cause it's not like my dev machine anymore and it would take a while.
We'd make some phone calls home, probably not gonna make it for dinner tonight, we'd order some pizza, we'd eat together, we'd have some beers once the boss left and, hopefully, hopefully, we got it running by the next morning at about 9 am and then, there'd be celebrations.
There'd be team lunches, there'd be thank you very much, thanks for the heroics, thanks for going above and beyond, that was awesome.
So then we go forward a few more years and we're in data centres and we've got these monoliths and the way you deployed infra in a data centre, was to talk to your lovely third party vendor liaison, raise a requisition form, which specifies a configuration for your infrastructure and cross your fingers again, and hope that at the night when you came to deploy, that everything would work as you intended and, of course, it never did.
So, once again, it would be all hands on deck, everyone is gonna come together, put in a heroic effort to get this thing working. The complexities that would add by talking to a third party vendor were always greatly exacerbated, more late nights, more pizza, more beer, more celebration lunches, big call-out at the all hands, "Thanks this dev team, "thanks for going above and beyond, you're awesome." So we thought there must be a better way and then, the cloud came along and we all really, really, really wanted to get to the cloud but we all had these massive monoliths and it just didn't seem possible.
So the next few years, specifically for me, my team spent trying to do the lift and shift and along the way we went, "Ah, might not work, "let's break this thing down to monoliths..ah, sorry, "to microservices and "single page applications and we'll try it that way," and we did, and we spent a lot of time learning like, first, what's a microservice? What's that all about? Then, what's a docker and, oh, what's this EC2 thing? And we did a lot of learning together and went on a lot of training courses and we spent a lot of time helping each other out. One team would have a breakthrough, they'd share it with everybody so that we could all get on the same page and get into the cloud and we did.
We got into the cloud and there was much celebrating, once again.
What a relief.
More beers, it was probably Champagne at that stage, pizzas, or maybe splashing out for some sushi as well, a lot of accolades, a lot more celebratory dinners and lunches and we all had a sense of camaraderie.
We'd been in the trenches together and we really got there, and we got there as a team and it was amazing.
So now we fast forward a few years and there's a very different vibe.
So with the microservices and decoupling of all the architectures, we chose different tech stacks.
So there's no more shared learning.
There's no more sharing ideas, we can't share libraries with each other that we've created and there's no more celebrations for heroics and no more challenges that can't really be solved by one person and stack overflow in about an hour. So no need to band together, really.
So this has led to siloed teams and, unfortunately, siloed individuals within those teams. So we're in the age of the individual contributor. We've lost the strong connections to those around us and, unfortunately, I work with a lot of teams and I see them, they're just kind of coasting. They're not low-performing, but they're not high-performing either.
Nothing hurts enough to go and fix it anymore. There's no small, incremental changes that you make every day to make your life and the life of the others around you a little bit easier and there's not a lot of challenge.
But then what happens when the team faces a change, or there is some adversity, or there is a crisis? They've forgotten how to come together and solve problems as a team so that cultural glue that bound them together is gone. In the book, "Lost Connections", Johann Hari talks about how we've evolved to belong in tribes and how we need them to feel safe and happy, and he's demonstrated how the high rates of depression that we see in our society are really from a disconnection, a disconnection to those around us, a disconnection to a shared purpose, and a disconnection from feeling like you're part of something bigger than yourself.
So, who's really gonna wanna come to work if they're feeling disconnected? If they don't really have a shared purpose with those around them? In 2015, Google did a study that set out to determine what key individuals you needed in a team for that team to be high performing.
So, for example, what number of rock stars versus coding ninjas did you need for your team to be high performing? And what they found was something really interesting. Who is on the team matters far less than how the team members interact, how they structure their work, and how they view their contributions or see their sense of purpose.
So, if continuous delivery has broken your culture, how are you gonna get your team back to high performing? How are you gonna get to a point where you're going to work surrounded by friends all day and you're happy to be there? So we don't have these times of adversity and hardship and heroics to bind us together anymore.
We need to be much more deliberate about strengthening our culture and we're gonna start that by focusing on trust. So Lencioni's five dysfunction survey which, I'm sure, the managers in the room will be well aware of and, if not, if you're not a manager, your manager will be well aware of this.
Lincioni tells us that the absence of trust, which is the bottom of the pyramid, ignites all the other team dysfunctions.
So without trust, we don't wanna be vulnerable with each other, we won't put up our hand and ask questions when we're not following the conversation.
That will lead to a fear of conflict and you end up with artificial harmony, where people won't challenge each other and you don't have rich debates.
If you're not having those debates, and you're not getting your voice heard, you're not gonna be committed to the results and that will lead to ambiguity for the team. When there's a lack of commitment, you'll avoid accountability and that leads to an inattention to results.
That will mean that the individuals in the team are working in it for themselves.
They resort to behaviours of status and ego and the team won't be as high performing as you would want it to be.
This is further backed up by the extensive research that you'll find in the Accelerate book and your State of DevOps report, which demonstrates that psychological safety is the highest determining factor of high performing teams in the technical industries. So, how do you know if your team is as high performing as it could be and that there is enough trust in your team? Let's have a look at how you answer these questions. Do you avoid asking stupid questions? Do you avoid giving feedback to your peers? Are your team discussions dominated by just a few loud voices? Do your team members become defensive when they're challenged? Or are new ideas ignored or even dismissed? If you're answering yes to a few of these, then it really is time for you to look at that trust and work on how to bring it back.
Luckily, it's very easy and it all starts with building personal connections and personal relationships.
So you don't have to be best friends with everybody in your team, but you have to know them enough to understand their motivations.
So, if there's someone in your team that really grates on you and you butt heads and you just never see eye to eye, be the bigger person and extend the olive branch, take them out for coffee, call it out, say, "Hey, we don't get along, we don't like each other, "let's talk about that." You might actually end up with the best friend you've ever had in that team. So find ways to connect and find some common ground. It's really important to role model vulnerability as well. Try to get comfortable putting your hand up and saying, "Uh, I don't know what you mean. Can you repeat that?" You should let others know that it's okay not to have all the answers all the time.
So when this happens and people are willing to ask questions, it means that everyone has all the information they need to be able to contribute to the discussion and that means you're getting much richer debate and coming up with more innovative solutions. I recently heard of a team that has a screw up of the week which, I think, is really cool.
So, they stand up in their retros and brag about who had the biggest screw up.
It's really hard to get that started and it takes a lot of courage and you might just find that it's you, for the first few times, just talking about all the stuff you've messed up that week, but eventually people will get the gist and they'll start joining in and then you can start learning from those mistakes you've made.
Win, win, win.
So, on top of building connections and being vulnerable, it's very important to cultivate a feedback culture. So giving feedback can be really, really uncomfortable the first few times you do it, but, you know, they say feedback is a gift and it really really is, 'cause you're showing the person that you respect them enough to tell them how they can succeed in their job more.
So even though it's awkward, you've got a responsibility to give it to those that you respect.
It's also one thing to take the feedback someone gives you, but inviting it is even richer and helps you grow more as a person.
So, what I mean by inviting feedback is not to stand up in your..
stand up and say, "If anyone's got some feedback, please give it to me and I'll listen to you." It's more about finding moments when you can get specific feedback, so, for example, if you run a retro, you could grab someone afterwards and say, "How did I go? What could I do to improve that? "Which bit resonated with you and which bit didn't?" So get specific in the moment feedback and people will see what you're doing and they'll start to give you feedback more often, unprompted, and they'll start inviting feedback and everybody grows.
Another thing that we don't do anymore much is celebrate.
So our friendships are really created in times of celebrations.
For centuries, people have come together to resolve differences by sharing a meal, where enemies become acquaintances and acquaintances really do become friends. So, do you need to celebrate more in your team? Do you celebrate results every few weeks or more? Do you get together outside of the office? Do you have shared stories that are not about work with your colleagues? Do you know about your teammates' partners, children, pets, hobbies, what they do on the weekend? So without our wartime cultures of heroics, we need to be deliberate in finding times to celebrate. Team lunches are great.
You don't really need a reason but just find one. "Ah, we had a great sprint, let's go out for lunch." "Ah, we moved our metric down a couple of points, "let's go out for lunch." Get together outside the office and find those personal connections again with your teammates.
Or birthdays, bake a cake for your colleague's birthday and take it in and share it with the team.
Just pick up some cupcakes on your way to a retro and feed people and if you don't have the budget for cupcakes, packet of Tim Tam's will do it.
The five bucks that you spend is gonna come back to you tenfold, believe me. So the key here is finding small and frequent reasons to celebrate as a team. You reduce your mean time to recover, let's celebrate. If you fix an annoying bit of tech debt that's been frustrating people for like forever, celebrate that as well.
So the next aspect we're gonna focus on is appreciation. So the School of Positive Psychology tells us that practising gratitude actually changes our brain. We have a more positive outlook on life generally and we start to feel that we're all in this together, instead of being suspicious of our peers and ruminating on all those bad things that happen in our companies.
Just being able to realise the contributions that our peers can bring can help build trust and unless you go out and deliberately look for it, you won't notice the small things that they do every day to support you.
So, is this something you feel you need to work on in your team? Do you even notice your teammates' small daily contributions that make your life a little bit better? Has someone told you that they appreciate something you did this week? And have you let someone know you appreciate something they did this week? Luckily, it's really easy to get started with this. Verbal recognition is good but it doesn't stick. Having something tangible, like a kudos card, that someone can take to their desk and hang up, it creates a permanence to your gratitude.
So say they're struggling in a week or two, they can look at that card that's in front of them and they still feel that gratitude but they might forget the words.
This can be quite uncomfortable and people say things like, "You can't force us to write gratitude cards." It's true, but I'm sure that your employers don't pay you to sit inside your comfort zone.
If you're gonna grow as a person and a team, you need to push yourself beyond what's comfortable and look at ways to improve.
Pretty soon this is gonna start to feel natural and after that, you'll want to be giving people kudos cards because you realise the impact that it's making. Put them up on a wall so that everybody can see them and maybe hand them out at the end of the week. Make them really visible.
Okay.
So the next thing we're gonna talk about is craft. I'm gonna assume that you've got your practises all down pat so continuous delivery, loosely coupled architectures, everything is automated, it's all observable, you're humming along into production, no sweat, it's not hard.
So somewhere along our automate everything journey, we stopped focusing on software as a craft. Getting it done and functioning was really really hard for a while.
We didn't have time to consider maintainability. In fact, I can remember when microservices came out, I was an XP developer at the time, and I was told, "You don't need to write unit tests anymore "because we're not gonna maintain "any of these microservices, "we're just gonna throw them away and start again." (laughter) But that never happened.
So do you think there's any room for you team to lift their game? Do you sit on a problem for more than ten minutes? Do you have pull requests that stay open for more than a day? Or any that go back and forth a lot, needing a lot of rework and having a lot of comments? Oh, a few people are nodding, that's good.
(laughs) Do new starters take more than two days to ship code? Do you have to delay a feature release if someone gets sick or do you avoid taking holidays because it's going to impact the team? Yeah? Good, it means there's a lot of good work that you can do in your team to help fix this. The best place to get started is to really focus on clean code and a few people have spoken about this today which is excellent.
So this is a framework that produces code that's easy to read, write and maintain but, more importantly, it creates a shared set of values that builds that connectedness in the team. The next one to focus on is test-driven development and it is not the same as writing your unit tests after you've written the code.
It does produce less code that's easy to maintain but it's not about the output so much as the behaviours that it drives.
So with TDD, there is much less context switching. It forces us to create small, discrete designs that are easy to communicate and collaborate on and we can also celebrate every test that runs green. Yay! More celebration.
It also makes pair programming so much easier. So pair programming, just like a team, the pair is more than just the sum of it's parts. The magic is the connections between them and what they can achieve together is always far above what they could do as two individual contributors.
So this here, this is my happy place.
These practises together seem to be force multipliers of good behaviours that leave no room for those dysfunctions that we discussed earlier.
A lot of these can be quite confronting when you introduce them to teams.
People feel quite uncomfortable.
Getting out of your comfort zone is hard but we need to do it to learn and grow.
So if you want to introduce practises like these, frame it as an experiment.
I might feel really uncomfortable with someone coming in and saying, "You need to pair programme 100% of your day, "five days a week for the rest of your life." That's quite confronting, but I might want to agree to, say, four hours a day, five days a week for three weeks and then stop and review it at the end, see if I like it, see if I've seen any impact to the team and then we'll discuss whether we continue it. Most teams that are quite hesitant with like the full-blown all-in all at once approach, are more than willing to run an experiment and quite often, see the benefits, see the behaviours that I'm talking about, and want to carry it forward.
What's really important is to focus on how you're gonna do it, what success looks like and how you're gonna measure it, and then come back together at the predetermined time and figure out if it's working for your team or not. So when you do have your practises sorted, you need to be able to share your ways of working with the wider organisation and with new people that come on board and that's when you'll create a team charter. So this is a workshop set of core values.
It means that everyone is aligned on what they value and how they wanna work together as a team. So some of the things that might be in this is, "We have team lunch together every Monday," "We don't interrupt each other in meetings." "We turn up on time to meetings." The important thing is that you hold each other accountable. So it needs to be visible, up on a wall somewhere so that you can see it all the time.
Okay.
So now we're gonna move on to learning and collaboration. We've drifted into this individual contributor world where people sit around coding with their headphones on all day, and stack overflow has become the teacher of the next generation of our developers.
Stack overflow is really good to figure out what and how but it misses the context. We're not teaching why we do what we do.
Working in siloes means we only look to our teams to learn from and this leads to homogeneous ideas and a little bit of groupthink and the best teachers for you might possibly, and probably will be, somebody that's not in your team in the organisation, someone from another team, someone whose got a diverse way of thinking about things. So how do you know if you could get more out of relationships with other teams? Do people attribute failures to other teams? Do you avoid seeking help from people in other teams? Do other teams fail to build things your team depends on and then that's their fault? So speed to market, so important nowadays.
This is our competitive advantage, right, is our speed. We need to ship more features and just keep shipping and shipping.
Now that deploying to production is not hurting us, there's nothing standing in our way.
There's nothing slowing us down and we don't take the time to fix our technical debts or learn new skills.
We're all too busy chopping wood to stop and sharpen the axe or even go out and get a chainsaw.
So you need to be very deliberate, plan learning sessions, or no one is gonna take the time.
Lunch and Learn's are fantastic and anybody can start these.
You might want to set up a Lunch and Learn and discuss three things that you heard at this conference next week.
People will be really happy to hear this.
So if you wanna focus on developing mastering, I love code retreats.
If no one's been part of..if you haven't been part of a code retreat, check it out and give it a go, it's amazing.
You work on the same coding carter for an entire day with different people and the outcome doesn't matter. You throw the code away.
It's about the way you write code, the way you pair and the way you write tests first. It's amazing.
It'll just take your craft to the next level. If you have communities of practise or guilds in your company, then join them and be active, contribute to them.
If you don't have them, start one, it's not that hard.
Send out something on Slack, find like-minded people that work in your discipline and just get together and talk about stuff that's happening in your industry.
Talk about things you've seen that you wanna make better or you wanna change. Pretty soon these things get a momentum of their own and then you'll be part of this great, connected community. So we've spoken about a lot of things.
Building trust, celebrating everything you can, appreciating your colleagues visibly and often and for small things, really focus on mastering your craft, provide learning and collaboration opportunities. So I hope that you'll find one thing that really resonates with you today and take it to your standup on Monday and maybe chat to your team about it.
Maybe you wanna run an experiment, maybe you wanna give a Lunch and Learn session. Invite someone that you don't see eye to eye with out for a coffee and just see what happens. So if you put yourself outside your comfort zone and get deliberate about rebuilding a great culture, you will find that high performing team that we might be missing, a team that you're happy to come to each day and a workplace that you really love and that's it.
Thank you.
(applause) (upbeat electronic music)
