So something that my friends and colleagues learn about me pretty quickly is that I love
karaoke, especially if you attend conferences like the lead developer with me, so this is
a photo from last year.
I think one of the people in this photo is in the audience right now.
I ended up at the karaoke box with 15 people from three different Amsterdam-based companies.
Yes, I love singing, but more than that, I love supporting people to do things that they
think are scary in order to truly express themselves.
That sense of freedom and camaraderie that you get, it makes me super happy, and so this
is the kind of supportive environment that I want to talk about today.
By supporting and trusting people to take their own steps towards difficult things,
we not only create more effective teams, but we also enable them to be stronger, happier,
and more fulfilled.
And what is better than that?
So I've been working as a product developer now in about ten different teams over the
last five years.
And I've lived four of them.
In that time, I have seen a lot of different ways of working.
And it's this kind of one that I think is the most important.
It's typically described by the term "self-organising" so it's really an umbrella for a spectrum
of team management styles.
We have self-governing, where teams figure everything out on their own, so they figure
out their own direction, their own team make-up, structure, processes, and everything.
This is possible but it's pretty difficult.
I think you've got to have pretty experienced people, and a very clear company vision.
And next we have self-forming teams which is where the direction is set, but the team
is created completely by themselves.
So I've actually done this twice now where, if you can imagine, a room full of developers,
a department of developers, maybe not quite this big, but where everybody is styled together
which teams and projects that they're going to work on themselves, which is a really cool
experience.
It's very motivating for people to be able to choose their own work.
Next we have the classic self-organising which is where their direction and team make-up
is set but the process is decided within the team.
And then outside this umbrella is the more traditional manager-led.
So I'm going to focus on the classics self-organising team by telling you a little bit about my
team, Team Cosmos.
This is where I potentially get too honest but I hope you can learn something from this,
and, when I go back to work on Monday, it doesn't bite me in the arse.
In October last year after the first two months at my company, I was asked to lead and manage
a team of almost entirely brand new people to the company.
This was an amazing opportunity.
I hadn't seen anything like this before where I could take everything that I had learned
and start completely from scratch.
I had a vision - #BestTeamEver.
This meant a group of people who cared about each other and the work wanted continuously
to get better at it as had fun doing it.
At the time, I wanted perfection.
I mean, I'm such a perfectionist that I had a secret hashtag!
What do you think, if you were asked to build a team like this completely from scratch,
how would you do it?
And how long do you think it would take you?
I had figured maybe a couple of months, maybe two or three months - something like that.
Well, let me tell you what happened.
We started off with a bunch of sessions to figure out how we should work together, where
everything was down to the team to decide.
Honestly, this was how scary saying, "Hey, team, do we want to do Agile?
" When I knew I certainly did, and they said they did I would have run out the room screaming,
but when everybody decides this stuff together, it's incredibly powerful.
Everyone was really invested in the decisions we were making as a team.
And, remember, you can always adapt and iterate if things aren't working.
It doesn't mean anarchy, though.
So we definitely had guidance from myself and from others external to the team.
In general, in a brand new team, I would advocate for starting with a proven structure first
and then pulling back on that and iterating and changing what is not working.
And as the team iterated, we also had a team agreements documents that iterates us.
Honestly, document as much as you can.
It's so useful, even for onboarding new team members which we had to do a few months ago.
Really, really helpful.
We also discussed our values as a team at this time and picked our top two were motivation
and honesty, because we figured we're not going to be really improving our way of working
if we're not able to be honest with each other.
And we're not going to really want to improve the way that we are working if we're not motivated
to do the work.
Most important of all: we decided on a team name together.
So we picked Cosmos because one of our team members is Greek, and it kind of means everything
that exists everywhere.
We like to think big!
And at this point, I really started to feel like our team was coming together.
We were all invested and motivated on building this thing.
All together as a team.
Then we shipped a bunch of bugs!
I shouldn't have been surprised.
We tried to deliver too quickly with very little experience with the codebase and with
each other.
Honestly, I thought we were ready, and I was wrong.
But, as we all know, it's okay to make mistakes, accept that it will happen.
We will ship bugs.
However, we were able to mitigate the impact and risk of these bugs with things like this
feature-flagging which was super, super useful.
If you're not doing this, please look into it.
It's a complete game-changer when it comes to shipping software.
By January, yes.
We were getting to know each other better.
Warts and all.
You might say this was our storming phase.
Honestly, this was a mission of a month.
We had team members struggling to work with each other, struggling to work with other
teams, it was kind of a mess.
But fortunately, about this time, I was doing these really amazing workshops on active listening,
which means in a conversation with someone, you're fully concentrating on what they're
saying in order to help them work through their own thoughts and feelings in a non-judgmental
way, which sounds simple, right?
But when is the last time you felt truly listened to?
Like even in a personal context?
It's so rare these days.
Get good at asking open-ended questions, and really listening to the answers.
Relating to someone doesn't mean steamrolling over them with your own story, right?
Figure out why someone is doing something.
And give a effective and specific feed back.
Examples are crucial here.
Also, don't forget to challenge your high performers.
You should be spending just the same amount of time on them as on everyone else in your
team.
They deserve it.
And, yes, this takes time, but it is so worth it.
It does need to be balanced, though.
By February, it was clear: I was doing too much.
I figured that, for the first two months, it would kind of crazy but it would calm down,
right?
It was not calming down, and I could not keep going like this.
To not underestimate the amount of time good leadership and management takes.
For me, the part of my job that I needed to drop was Scrum master work but usually, there
will be something.
Often, as lead developers, it's writing as much code as we would lying.
When you have a responsibility towards people, they have to come first.
If you're not - if you don't like the balance, look after fewer people.
Don't just look after the ones you do have less.
If you're struggling, talk to your manager or your team.
Balance the work if possible.
So, in our team, we had people starting to only things like retrospectives and stand-ups
which I am so grateful for.
So can you tell by now that I have pretty high expectations of myself and others?
This has sometimes led me to focus too much on continuous improvement.
I'm working on it!
We've heard it a million times, but I still manage to deprioritise it over and over.
Remember to authentically celebrate success.
We had a really great offsite celebration in April, and I got us team socks.
I'm wearing the socks.
They're amazing.
They have stars on them because our team name was Cosmos.
Be positive.
Don't fake it, but do the time to give praise and positive feedback.
Did we reach the original vision?
No, because the original vision was whack.
It's not based in reality.
I'm proud of my team.
We consistently ship great work and we are damned good at it.
We care about each other enough and we're honest with each other, and we have a great
time doing it.
I see here proof of this just about every day.
That vision of perfection, no.
The hashtag best team ever?
Hell, yes.
I hope with this talk, I've helped you remember to take the time to help themselves.
You can't do it.
Spread the load, reach out.
People are the most important thing as a lead developer.
Whatever you do with this job, you have the power to make such an impact on people's lives.
Never forget that.
Will I see you all at karaoke tonight?
Thanks!