At DevOpsDays Melbourne 2015 I facilitated an Open Space session on management and leadership.
The purpose of the session was for experienced leaders to share their stories and discuss what skills are required for effective leadership, so new managers and people who are thinking about making the switch could learn from people who have been before them.
You can find the original audio on SoundCloud.
This is a writeup of what was discussed in the session.
Reviews
At some stage you’re going to have to do a performance review.
Being honest in the review can be hard when you start, but the people in your team really appreciate feedback because it’s personal.
Reviews should contain no surprises. If you get to a review and your team member is surprised by something said, it’s too late. When you give feedback, be specific and call out specific good work – it shows that you as a leader are noticing and appreciating the work that’s being done. Generic platitudes of “good job” aren’t effective.
But don’t just wait for a review - force yourself to give feedback whenever you can. Showing that you notice what people in your team are doing is really powerful, and is a big influencer of behaviour. You might feel like you’re giving too much feedback to your team, but every person on your team is only seeing a slice of the feedback.
1:1s
Sometimes 1:1s are the last thing you want to do if you’re an introvert.
It shows up in your calendar, and you think “I wonder if I just don’t show up today?”. But when your boss doesn’t show up, you both stop talking about the 1:1, and mutually implicitly decide not to do more 1:1s. Force yourself to do them even when you don’t want to – you’ll often find within a minute that you’re enjoying it, because you’re feeding off the response you’re getting: that it’s important to them.
People might do 1:1s because they feel they have to.
Why should I do it? Why should I talk about family, weekend, work? We’re engineers! We know what each other do!
But people are more engaged if you know about their family, and they know about yours. It’s surprising to know these things work, but also relieving – it’s not black magic, it’s just how humans work. We attach to each other more when we’re socially connected.
You should be meeting people a minimum every fortnight, so there are no nasty surprises.
But separate 1:1s-as-a-status-update from 1:1s-as-a-personal-update. It’s important to do both, but separate the concerns.
Mentoring
Get team leads together in your organisation, and get them sharing experiences and lessons. Make sure new managers talk to one another, and bounce ideas around.
It’s also important to pair up new managers with an experienced manager to bounce ideas around.
These pairing doesn’t have to be in the same department, because it’s dealing with people problems, not technical ones.
Also think about finding someone to bounce ideas off outside of the company – talk to ex-bosses, find mentors, individuals. They give you a perspective because they’re not trapped in your day-to-day.
Best bit of advice ever given to David Spriggs, CEO of Infoxchange: “Treat all your staff as if they’re volunteers”:
Listen to people, look after them. Don’t try and do too much work as a manager – you’re there to be a multiplier.
Role models
Everyone was likely managed by a good manager at some point.
We’ve all seen and experienced good things when working for good management. We often forget what those good things are when we make the change to management. You’ve got to re-learn it all. You’re not receiving it, you’re giving it. This is super hard.
Conversely, a lot of people have never had good technical management, so they may imitate what they’ve seen, perpetuating bad practices because it’s all they’ve ever known. For example: “I haven’t seen my manager in 3 months”.
Promotion vs career change
There’s a preconception that you have to do a lot of tasks as a manager.
You’re going up to get more responsibility, be paid more, and have greater input into the company direction.
Often people will get to a point in their technical career where they are unable to advance any further, and there are few companies that help people go further on the technical career development track. Rackspace have the technical career track, where engineers can be paid more and have more input in the company than some execs.
As managers we need to create the opportunity for our people to grow in the direction they want.
Traditionally, people in tech have been promoted due to technical ability and intelligence – less on emotional intelligence, and their ability to communicate with people. The higher up in the org structure you go, the more your ability to socially interact with other people becomes important.
You have to critically assess how good you are at that. Make sure you’re getting feedback, as well as giving feedback.
Celebrating successes
Linda Rising’s “Do Food” pattern from Fearless Change talks about introducing food into celebration and retros, as a way of bringing the team together.
Just a coffee goes a long way. Removing people from the office environment allows them to open up more about problems and successes.
How do you make food or drink celebrations work with remote teams? Everyone buys their own food and drink, gets reimbursed, shares on the video conference.
If you’re going to cater celebrations, be aware of dietary requirements. If you’re doing regular 1:1s, you’ll know people’s dietary requirements ahead of time.
Distributed teams, remote workers, co-located offices
What works: dedicated chat rooms, per-product streams, that people can opt into as they please. Non-technical folk should hang out in those rooms too. Also have a general themed rooms too, like “devops”. Having management in those rooms is a great way to identify problems in the organisation before they spiral out of control.
There’s a certain etiquette when working remotely. People don’t realise that they need to digitally note things that are said face-to-face, so other people who aren’t in the same room are up to speed. To prime co-located teams for working remotely, spread the team across the office so they’re not physically located together.
Sometimes you need to pull people together into the same place regularly (e.g. every 3 months). The frequency and size of events will vary from team to team.
If you don’t have regular face to face communication, the co-located offices and people can fall into old patterns. Even if you send someone to the other office permanently, they adopt the culture of that office, become “one of them”. Exchanges need to be two-way.
There are cultural concerns around remote work in different countries. In some cultures there is a certain level of prestige around having your manager come and visit you. If your boss doesn’t come to visit, and other teams have their bosses visit, that’s a negative mark against you.
Teams that are partially distributed are harder to manage than fully distributed teams. As a manager you can send people that are together home to work, so they work like the people who are distributed. Consider walking around the office before/during/after standups to show the office environment beyond the normal meeting rooms. It makes people feel included.
When you’ve made the wrong move
What happens when you’ve made the career change, and you realise you don’t want it any more? How do you address the impression that you aren’t successful when you go back to your prior role?
It’s important for your organisation to recognise the challenges people are facing in their new roles and support them.
“The fact is, if you’re miserable in a leadership role, you’re probably not doing a good job. Save your team the pain, and change.” – Hannah Browne
Move towards a position you provide the most value in, and you are the most happy in.
It’s not a promotion, it’s a career change helped people realise that the move is not “I have all this responsibility and stuff I need to look after”, it’s “I have different things to think about, I have new stuff to learn about people, communication, relationships, how to be the multiplier”.
Leadership is a fundamentally different set of skills to engineering.
We don’t look at a hairdresser, or a carpenter, and say the hairdresser should be able to knock you up a house, and the carpenter can dye your hair.
In our knowledge industry we expect that people can change the work they do at the drop of a hat – with minimal mentoring, support, training, guidance, advice – and be successful. We all have a role to play to help people who take the step and decide they don’t love it to not feel like they’re losing face.
Go back to something you love and are passionate about. You have invested years of development in those skills.
Leadership vs Management
Aren’t leadership and management separate things?
The feeling in the room was that to be a good manager you have to be a good leader, but you can be a good leader without being a good manager.
Leadership isn’t a position, it’s a function that anyone can adopt. David Marquet’s Turn The Ship Around is a great case study of encouraging a culture of distributed responsibility, creating leaders at all levels of your organisation.
Management has a bad name, leadership is the trendy alternative, but they are distinct things. When leading you have to look after your people, because you’re working for them.
We’ve heard the term “management heavy”, but you don’t really hear the term “leadership heavy” - maybe that’s an insight into the differences between the two functions?
Leadership cuts across different jobs and industries. Management less so, because it can be focused on technical details. Leaders that are great working with, encouraging, motivating, collaborating with people are successful.
Story time from Chris Madden:
Startup during the dotcom, hired 25 engineers, had a great team. But there was nobody in the team that was suitable to lead.
Startup leadership went out, found someone who had run restaurants, and had herded cats in the film industry. Although he didn’t have any technical experience, he was parachuted into this great team of engineers.
The engineers respected him because he was successfully doing work that they weren’t good at.
One thing new managers can be bad at is knowing when to be direct. You don’t want to tell anyone what to do because “you should just decide”.
But eventually you’ll get feedback from the team that sometimes they just want you to make a decision, set a direction, so they can get on with the job.
Regardless of whether you’re in a management or leadership position, make sure you have good feedback loops from the team.
Understanding your team
Understand how your people are working.
If you’re in a leadership position but come from an operations background, spend time understanding how developers work and think.
“No-one gets out of bed in the morning with the express purpose of making your life miserable”
Sometimes people will drive you insane. But everyone has their own stuff going on. People behave how they do for a reason, so spend time understanding why.
Recognise that everyone is different. A technique that works for one person won’t be guaranteed to work with the next person in your team. By having social interaction with the people in your team, you can work out what’s required of you to work with that person effectively.
Devops and changing roles within a team is a useful mechanism for building empathy. There’s the difference between understanding what someone is going through and actually living it.
Dan Pink’s Drive discusses a new model for understanding people’s motivations. Once you remove money as a concern, people are driven by autonomy, mastery, purpose. When you have 1:1s, use Drive as a framework for working out which category they fit into.
Involve the team in the decision making process. Don’t be “my way or the highway”.
Talk about ideas, collectively own it, build consensus around decisions. The work we’re all doing is hard, and you have to be pretty clever to do it well. As the team grows and gets better, you can start thinking “I wouldn’t be able to be part of this team”.
If you leave the team, there should be someone in place to take over your responsibilities.
The value you provide as a leader
You know you’re doing your job as a leader right when you realise that there’s more value in the communication you facilitate than the tasks you’re performing.
You’re not the leader because you’re the best at every job. You’re not delegating tasks because you’ve run out of time to do the tasks.
You’re delegating because you genuinely believe the people you’re giving the work to can do it better than you. Your responsibility is to create a context in which people in your team can succeed. You do this by talking to them, understanding their motivations, giving them purpose.
Sometimes people think that management or leadership isn’t something they can do, because they’re engineers, and it’s not their responsibility, and they’ll need to change the org structure to achieve the outcome.
But leadership is the responsibility of everyone in a team, and it’s within all your abilities.
Resources
- Meetup: Melbourne Agile Dev Managers on Meetup, “MAD managers”
- Meetup: Once you’re in a leadership position, or are aspiring, there’s the Melbourne CTO and Sydney CTO schools.
- Podcast: Manager Tools. Two US-based management consultants talking about new topics every week.
- Newsletter: Software Lead Weekly is a free weekly newsletter of curated management and leadership articles. Oren Ellenbogen maintains a Trello board of all the articles included in the newsletter over the last few years.
- Book: Oren wrote a book called Leading Snowflakes off the back of the Software Lead Weekly newsletter. It’s specific to people making the transition from engineer to engineering manager.
- Book: Talking With Tech Leads by Patrick Kua on Leanpub, lots of interviews with managers
- Book: Behind Closed Doors by Esther Derby & Johanna Rothman is a good introduction to software development team management.
- Book: Turn The Ship Around by David Marquet. A great case study of encouraging a culture of distributed responsibility, creating leaders at all levels of your organisation.
- Tool: iDoneThis, SaaS, sends an email to each person in your team asking “what have you done?”, you itemise everything you’ve done, sends back to your team or your manager. At review time you can go over accomplishments in fine detail, and raise issues as they come up.
- Photos in this post are from the DevOps Australia Flickr set, under a CC BY-NC 2.0 license.
