Work 2019

This post is a summary of work stuff over the past year which covers my first adventures into

  • Technical leadership and line-management
  • Hiring and building a brand new team

I think I've helped build a pretty rad team, so if you're interested in that kind of thing, read on.

Rough start

After working in one of the most productive, interesting and fun teams I've ever had the pleasure to be a part of, the team has to be disbanded due to complicated (and boring) politics.

We were given freedom to move in to almost any team within the organisation but I really didn't take our team being disbanded well at all so I think in my eyes every opportunity looked boring and unfulfilling. It was never going to work out.

New job

Happily a new opportunity came about with my previous employer. I'd worked there for just under 2 years; it was really enjoyable, I liked the environment and I'm proud of the work we did and how we did it. It felt like we stood behind the good DevOps principles and it worked out well for us.

This would be a different role though, I would be a technical lead. I have been a technical lead before but in a different environment and without the line management responsibility needed for this role.

I was a little tentative about this at first. I hadn't been a line manager before and everyone I've spoken to about it to implies it's horrible. My future boss spun it pretty well though:

I deliberated on this and thought about leads who had worked well with me and those who hadn't. A couple of people who've had the dubious pleasure of managing me have had a real positive effect on my career (and life, I suppose). They pushed me into things I never saw myself doing and gave me confidence to stand behind my convictions.

When I put all that together with someone giving me this rare opportunity to pay it forward and to help some people find the joy I get out of software-engineering; I had to give it a go. I may never get this kind of opportunity again!

My personal goal for this job

  • Learn how to create great teams who not only deliver good software with minimal stress, and actually enjoy it.
  • Grow some engineers

Hiring

The initial suggested makeup for my team was:

  • A senior
  • A mid-level
  • An associate (junior)

Now where I work isn't as glamorous as one of these fancy fin-tech startup whatevers, but it is a good place to work. The environment is great, we're empowered and work in a pretty cutting edge way. We go to DevOps conferences and hear about best practices and we can honestly say we do a lot of them. We deploy many many times per day, deployment is a non-event for us.

Getting that across to the highly competitive London job market I guess is hard because I had to do a lot of recruitment effort to eventually get the right people.

Diversity and all that

I was determined not to hire 3-4 clones of myself. I am infuriating to work with. Studies show diverse teams have better results. Also, hiring diverse teams is the right thing to do.

We approached Makers Academy to help us hire as their raison d'etre is bringing people from different backgrounds into software development. I've had a very positive experience working with Makers graduates over the past 5 years, they've always made the teams and people around them better so I wanted more of that.

It was a fun and intense experience of pitches, chatting to lots of people and interviewing a number of great candidates. If it were up to me we would've hired more but in the end we hired 3 excellent developers who are thankfully nothing like me.

The team

The stars aligned quite nicely in that after months of recruitment going nowhere my team of 3 associates and a senior more or less joined at the same time. It was super exciting to have a new team suddenly appear in the office.

Having a brand new team, and role suddenly land on my lap all at once was pretty intimidating at first but the people I hired made it a lot easier because they're all excellent people and I had good support from other people in the department.

How I tried to make it work

Before leaving Springer Nature I had a meeting with one of the managers which was more impactful than he probably realises. He said

You need to take learning management as seriously as you do learning software development. In the end you have a direct effect on people's lives

OK, it's a bit dramatic but it is true. I reflected on managers who hadn't worked for me and how frustrated and annoyed I was about the situation even outside of work.

It's definitely a problem that a lot of people seem to think that management comes naturally to certain people and is not a skill to learn and practice.

So I picked up some books and watched some talks in the hope I could actually achieve my goals and not let my team down.

The Phoenix Project & The Machine That Changed The World

These are two books that talk about the problems you have when trying to build big complicated things with lots of people. They're very different books,

The Phoenix Project is described as a "DevOps Novel" which sounds lame as hell but is actually really enjoyable.

The Machine That Changed The World talks about the approaches to manufacturing cars. From artisan bespoke cars, to mass production and then lean manufacturing. It sounds far away from software development but as you read it you find yourself nodding along, drawing parallels with our industry.

There's loads to take from them and here are the main bits I got:

  • Command and control definitely does not work. You need to empower the people who actually create things to make decisions as they're the people with the most up-to-date, relevant knowledge.
  • You must respect work in progress (WIP) limits. It's way better for a team to properly finish tasks and only work on a small number of things than hurriedly work through dozens of tasks. Disrespect of WIP will slow you down.
  • A better understanding of "lean". Once you read these two books you have a very clear idea of where agile gets a lot of its ideas from.

I summarise these ideas in more detail in The ghost of Henry Ford is ruining your development team

Resilient management

This is a very practical book on technical leadership, it's quite short and I have found it invaluable. It has given me concrete things to do to help build my team.

Growing people

It has some fascinating insights between the terms "coaching" and "mentoring" which I share with basically everyone because it really has changed the way I try to help people.

  • Mentoring Giving advice and perspective to help someone solve a problem. Quite a direct way of giving information. Good for overcoming roadblocks. Focused on the problem and solution.
  • Coaching Asking open questions to explore a topic more. I like to see it as trying to help someone "join the dots" of an idea. This style will have a longer term impact on people and will help both parties explore ideas more.

Having these ideas explained has made me more conscious about how I try to help people solve problems. I find myself looking for coaching opportunities more when working with people and have tried to take that into our workshops by encouraging coaches to draw on real-life analogies to help explain technical ideas (David Wickes is extremely good at this).

Self reflection

The book discusses how when people go from engineering to leadership need to understand their "default work mode" and how it might not be compatible with different goals as a lead. I think my default work mode is "just fucking do it" and "ask for forgiveness, not permission"; this has broadly worked out quite well for me as an engineer in teams. However as a lead I need to check myself.

Sometimes I just want to open my IDE and refactor some code I dont like and git commit -am "refactor". On a high level that is the right thing to do but how does that help my teammates in the long-run? I should see these things as a coaching opportunity and instead find time to bring it up with people and explore the space with them so that in future everyone else can see the problems in our code better.

The book asks you what you think your management style is so you can reflect on it. Just asking that question of myself was weird and difficult, this is what I came up with:

  • No micromanaging. Feel strongly about empowerment, ownership and trust. I have no interest in denying clever people the opportunity to use their skills to achieve our goals.
  • Reliant on honest feedback, sometimes I don’t observe myself not being great
  • Hope to focus more on growing people than “getting shit done” but I will need to check myself because that is my “default work mode”.
  • Want to act as a sponsor, finding opportunities for people to grow

I like to think that I've stuck to my guns with this style and it seems to be working out OK.

Setting direction

The book also instructed me to write a vision (or North Star) for the team

Be an amazing team that is continuously improving that ships well-engineered software with minimal hassle and stress by relying on craft and taking advantage of our autonomy to apply industry best practices.

We will take pride in our actual agility to confidently change and evolve our software as and when we need to.

If we get good at creating great systems, our stakeholders will always be happy with us and will continue to give us autonomy.

And a mission, which is a more grounded version of it

  • Openly and honestly communicate with each other to guide ourselves so we can grow
  • A culture of learning and sharing knowledge
  • Confidence to suggest changes to improve our ways of working and our code
  • Continuously tightening feedback loops to guide improvement

And a strategy to get there

  • Finds ways to break problems down into smaller chunks so we’re never working on something that feels too intimidating. Perfect is the enemy of good, better to ship 80% of the feature quickly than 90% in 3 months time.
  • Low WIP (work in progress) so we’re not spinning too many plates and that allows us to focus on small tasks that we can execute well.
  • Culture of feedback. Practice saying something nice every day! Remember that giving someone “negative” feedback is an act of kindness (so long as it’s done kindly).
  • Practice continuous integration. Both in respect to code and knowledge.
  • Pairing, mobbing. Even if you work on a task by yourself it should be considered very unusual not to seek feedback on your work as you do it.
  • Give ourselves time to research, in particular pre standup research times
  • Share interesting things you learn.
  • Ensure everyone has time to work on all aspects of our code and development practice, actively fight any silos of knowledge forming.
  • Everyone on the team contributes in forming how we work.
  • We should take pride in our work. If you’re not proud of something, we discuss how to make it better.
  • Identify any single points of failure we may have in our ways of working and work to spread the knowledge & responsibility

If nothing else it felt cathartic to write this down and I've encouraged the team to contribute to the document.

I sometimes feel my role, if anything is to keep pushing the team in the direction this describes so that we do become that team that I hope we will be.

A talk from Makers

A few of us went to a Leading a Diverse Team workshop at Makers. It was interesting and one talk resonated with me a lot. It discussed how often as a leader we project our own ideas as to how to accomplish a goal based on our own experiences. This is fine and well intentioned but it's from a position of bias and you may be unintentionally shutting out different ideas.

A better, more empowering way of trying to achieve what I'm trying to achieve is setting a vision but then encouraging the individuals in my team to think about the unique ways they can contribute toward that vision that I may not be thinking of.

My way of achieving goals is one means to that end but it doesn't have to be the only one; and there's probably better ones that my team can think of based on their own background, skills and experience. It's my job to encourage people and build a great environment so they can explore their own ideas.

Lessons learned, things to improve

Introvert Chris

I am one of those introvert-ish people who can seem relatively outgoing most of the time but I definitely suffer from running out of social energy quite quickly and just wanting to get a break from people (no offence, team).

This role definitely has taken its toll on introvert Chris at times and I need to find ways of managing that better but I dont have many good ideas yet. I think perhaps now my team is settled more I shall try and delegate a few more meetings to people as it will save me some social energy and is an opportunity for others to contribute in those areas.

You cant just mob

I hear a lot of great things about mobbing and I am totally on-board but for whatever reason when we tried it did not go well. I suspect it was a function of the team being very unfamiliar with each other and the nature of the work (it was very new-project, infrastructure work).

Still, like leadership it's probably something you have to study and not just an innate skill. I hope to read more about this and try it again next year.

General time management

I'm not happy with the amount of time I've got to pair with everyone. I'd say I do it quite often but not enough. The times where I paired I've been able to give much more useful feedback in our one-to-ones.

When the role was first offered to me it was proposed I would manage 3 people. That quickly turned to 5 and at the start of 2020 7. To serve all these people well I am definitely going to have to think carefully about what I am doing every day and try to find opportunities to delegate useful tasks that will help people grow and free my time up at the same time.

Study more

The few books I got through gave me some excellent ideas and set me up well. I want to continue reading this subject to get better. I'm currently reading An Elegant Puzzle which is very interesting but seems maybe better suited to a head of engineering role rather than the one I'm in right now.

The next books will be:

Final reflections

I'm glad I didn't try and "wing-it" with management. I'm still learning though and there's lots of room for improvement but I think the upfront study I did helped grease the wheels for my team and get it off to a good start.

During hiring I was very upfront about what my expectations and aspirations for the team were which resulted in a group of people joining who seem to be bought into the idea and are contributing toward it.

I'm really pleased and proud of how things are going. I shouldn't take for granted that we managed to turn a group of strangers with various backgrounds and experiences into a great team. The culture is fun, open, curious and we take pride in our work; which is honestly exactly what I wanted.

I feel everyone has become better engineers since joining and I am confident we'll do great next year so long as we keep pushing ourselves to get better and better. (that felt like a bit of a lame manager-esque rallying call, sorry)

I think the most gratifying moment for me was a small one. A few weeks after the team formed I went on holiday. When I came back one of my team mates told me they had changed the process. I replied:

Good

It's the team's process, not mine. I want them to be comfortable making decisions about how we work and voicing strong opinions about the way we do things, and this demonstrated we are heading in the right direction.