[Applause].
>> Thanks, Meri. Hi, everyone. So, yes, today I would like to talk to you
about some familiar things that I think you might already be doing in your practice as
a software engineer, that, if you put a different lens on things, I think they will sharpen
up your leadership skills and make you a better manager. Why is that even important? Because
of this. A full 70 per cent of the performance of a team is affected by their manager. This
is from a book called It's The Manager, by Gallup who write about identifying high-performing
teams, and this is one of the things they've spotted. The next quote from this article
says, "Lousy managers create miserable employees who create negative business outcomes." So
it's no wonder, then, if you're thinking of taking on management, or are new to it, or
just want to get better at it, that's kind of scary, right? That can make you feel intimidated
and overwhelmed. You might be excited and happy, of course, to think about how you're
going to be able to help your team better than before, but you might also be nervous
about how to do a good job. Imagine yourself as a happy developer, shipping features. Your
manager taps you on the back and says, "I'm too busy to take this meeting today. Can you
stand in for me?" Or, "There's a leadership role coming up. I think you should apply."
Does that feel scary? Why? Because of the 70 per cent. It's so important to do a good
job. It's important at work to feel your manager has got your back and they are setting you
up for success. The first time I had to do a salary review for my team, I agonised over
it, because it was a huge responsibility to make a decision about their salary, fundamentals
things in their career that wouldn't have effects for them but compound over the years.
I considered all the angles and the pros and cons and I put a lot of work into it. That
process got me thinking about what I already knew as a developer and the ways I was used
to working, and how I could apply that to the new problem I was solving. So today, I
want to show you some of those things that you might already be doing and how they can
help you transition into this new role. These are the things we are going to be talking
about today, maybe some familiar terms in there, and these are the things that I thought
about when moving into a leadership role to make life easier. You don't have to throw
everything away. You're not starting from scratch. Don't repeat yourself. When I was
doing the salary review for the first time, I was worried I had done the agonising work,
and I thought hard about how to make it right, and because of the longer cadence and the
rhythm of the work, I might not have to think about it for a few months or a year, and I
forget everything that brought me to that decision, and that made me think how in code
you have reusable modules, and I think in management, the unit of reuse is the decision,
or the decision-making process. It sounds obvious but that decision for decision-making
is the core part of a leadership role. And it's really important that those decisions
are fair and consistent. If you're doing a salary review, you need to trust your team
need to trust you that that decision isn't going to come out differently, maybe better
because you're happy because you had a good lunch that day, or worse because it's winter
and you don't like the weather. Like in code, you have reusable modules. If you're in a
leadership role and you come up to a similar problem to one you've solved before, you want
to be able to see easily your previous thinking and deploy the same solution, because making
those decisions is hard, it's exhausting. You want to get it right. You put a lot of
work into it, make sure it is those good things, fair and consistent. Replaying your decision
is a good time saver for you as well. You don't want to have solve the same problem
twice. How do you go about this? Just write it down? That's it. It's really simple. Make
a template to make it easier to fill in next time. Make sure you save those things in a
place you can find them. We keep these kinds of decision logs in our project plans and
I think of these as a like a history of Git commits, a place to write down the why, not
just the what. When you do come back to it, you can get up to speed quickly and remind
yourself immediately of your thought process. What this gives you, once you've written all
those individual things down, and got all these lovely decision documentation saved
somewhere you can find it, is a the beginning of a bit of a process. You might roll your
eyes and think, "Process!" You're scared everyone will make you jump through unnecessary hoops.
I don't think process should be scary. All it is is a way to make those easily repeatable
decisions that are fair, and consistent, and take into account the varied needs of everybody
on the team. That's the goal, right? But don't reinvent the wheel. What you want to end up
with something is like a run book, or a play book, so you don't have to remember all the
steps each time you need to do something, you can just work your way through the checklist.
And this is great when you managers join your team because you can get them up to speed
easily, or because you've got that shared understanding of how you make those decisions,
you can start delegating work to help to make your team grow, and this frees you up to work
on the harder problem you haven't solved yet. Maybe you need to figure out how to hire a
new engineer or add levels to your development framework. If you're anything like me when
I was an engineer, you have to resist the urge to over-engineer these things. As developers
we try not to do too much work up front - just the right amount. As a manager, you get the
same principles, the same benefits by applying these principles. So don't try and force things.
Make sure you have had a few cycles and shaken out the edge cases before you try to make
anything too formal. When you do start to formalise things, don't let there be too many
steps. If there is a spreadsheet, or a screen shot in a Word document, they're not going
to do it. As with code, you want a clear path people can easily follow. I work in a team
of managers, so I wondered if we could apply any of this to the way we work together. In
the same way that you can apply product team thinking in your personal projects, I think
that you can apply these principles if you're working on your own as marring or a leader
too. We've been doing this for a little while now, and what we found is all the things that
make a software engineering team work really smoothly also help a management team work
really smoothly. Working in sprints lets you prioritise your long-term goals against the
day-to-day business as usual, keeping-the-lights-on, having a sprint board, asking what with we
do today that makes us move towards our sprint goals? We set our intention for the day. It
keeps you connected. It means you can easily see if someone is becoming overloaded or blocked.
There are reasons paring is useful in software development. We learn from each other, share
knowledge, get out our own heads a bit and bounce ideas around. You need to loose that
because your end product is different. All the different things of pairing on code are
true of just pairing. You can pair on a blog post, a talk, roll play some feedback you
need to give. I think there's this misguided expectation of people. Now, you're a leader,
you have to have the answers. That's not true at all. If you collaborate and work better
on your projects, you will have a better outcome than if irrelevant stuck in your own head.
This applies to getting feedback on your work, for example, building your career development
framework, that end product will be so much better if you get the input and advice from
the people who are actually going to be using it. Retrospectives are probably the single
most important thing I think we do as engineers be, and as leaders. You need to have a lot
of different experiences to learn, but unless you reflect on them, you will never truly
learn from them and be able to improve. You can do this on your own, even if you're the
only manager and you're not in a team or you think it's weird to have a retro for yourself,
go for it. Keep a journal. This time for reflection is really important. So these are just some
of the things that I think you maybe are already doing as an engineer that you can bring with
you on this new journey. I'm sure you can think of lots more. I hope I've encouraged
you today to think back on your own experiences as a developer and see if you can look at
your work in that slightly different way and add things to this list. You don't have to
throw everything away. You're not starting from scratch. You've got this. Happy leading!
Thank you very much!