I have spent the last 6 years or so learning how to enable a team. It's been a slow journey and if I were kind to myself I'd say it was slow because my most natural inclination lies with the code rather than the relationships of those around me. In truth it is more a journey in being vulnerable and getting the ego out the way, which is taking time, but it's making space for learnings that are quite life changing. I am still very much a novice of management (of any sort) but perhaps there is something for you to take away from my stories.
I think being a good manager requires keeping a lot of external pressures in balance that are often contradictory, subjective and unclear. Being a good manager often requires making the correct quick decision based on your knowledge of the situation and how the people involved will respond best to an intervention. Sometimes being a good manager means empowering others and taking a step back but on the flip side doing nothing because it’s all so unclear is paramount to not doing your job.
To add more on top of that as a manager you have to fight against your learned childhood habits and fears to react disproportionately in some situations and this is probably one of the hardest parts of the job. You also have to realise that other people will naturally overreact in some scenarios and you need to magically weave your way through this minefield in order to achieve optimum happiness and output from your team.
These rather subjective areas of management make me quite tempted to ignore them. In fact, distancing myself from things that make me uneasy is one of my learned childhood habits. Alas, my scapegoat reaction doesn’t make the problems and excitements of enabling a team less real.
In this post I run through some scenarios from my very real world and discuss what a lead developer, manager, CEO, agile coach, scrum master, facilitator might do to deal with them. For each scenario, I’ll set up a situation and outline some possible approaches to handling the situation.
I have made an assumption that management is a concept that each one of us takes up, be it to manage our internal worlds or move a project forward or to help a team improve. For this reason I have been quite lax on associating roles with the scenarios that we run through. It by no means follows to say there shouldn't be roles in team.
This post may have benefit for someone trying to get a team past the headwinds of initial agile adoption and it will be a useful reminder of some of the challenges that face us each day, in life and at work.
In a roundabout way the topics, scenarios and stories that follow document some of the journey of ego reduction and making space for vulnerability that Tranzact and I have taken. The journey ultimately resulted in us adopting an agile process which then substantially fast tracked our progress.
Expressing vulnerability puts it on the backlog
Vulnerability and Ego are hard to get right in practise and was probably the step that took Tranzact the longest in its journey to improvement. The scenarios that follow are probably obvious but perhaps we can just take a moment to acknowledge how hard it can be to do the right thing.
I’m frustrated and worried with a relationship I have with a client that is possibly going to increase the chances of a failed product. We’re struggling to follow up with each other. We're both bad finishers. We’re bad at pinning down a requirement together. I react by distancing when they don't listen to what I say.
What do I do?
- Use the team as a platform to express my disdain with how our client is failing to help us build the right product.
- I don’t tell anyone and make excuses later.
- Talk about my client relationship issues openly and constructively with the team, being vulnerable about my shortcomings.
- Make the tough choice that the client is probably not a good fit for the company and motivate for the product to be cancelled.
I don’t think I have ever managed to talk openly and constructively with the team before doing a little of the others first. Our natural silence or misdirection leaves the product in a tenuous position and it robs us of the ability to learn and improve. The benefits of letting your guard down, being vulnerable and allowing the people on your team to help you can be enormous. Perhaps the product should be cancelled, perhaps you need some tips to help get you on the right track, perhaps someone is better suited to handling the relationship.
Harry mentions a potential stumbling block I hadn’t considered. Our operating system upgrade isn’t compatible with the version of the database software we’re using.
- Tell Harry that database software upgrade will happen at the same time, even though it wasn’t in the plan yet.
- Acknowledge you hadn’t noticed the incompatibility and praise Harry in the next stand-up meeting for saving your ass.
Without the acknowledgement Harry’s contribution has effectively been stolen and it’s gone unrecognised. Contributions that continuously go unrecognised will probably stop arriving. Harry will feel devalued as he feels the rest of the team already have the answers he’s brining. If we don’t manage to be vulnerable for a moment to acknowledge Harry's contributions, the opportunity for building trust and encouraging natural teamwork is lost.
Our client calls in and asks me if things are good with the thing I promised to work on over the weekend (but forgot about).
- Pretend we’ve done the work. And frantically sort it out.
- Pretend there was an impediment or make some other mostly invalid excuse.
- Acknowledge we committed to something we haven't done and apologise and make the best plan together to mitigate the situation.
Holding on to your ego in 1 and 2 doesn’t allow the team to adjust to its strengths. The team becomes reactive (or you become reactive). Perhaps there wasn’t actually a need for you to have committed to those changes in the first place. If you said you’d do the work over the weekend just to show off, you’ve probably subtly set a standard in the team that commitments don’t need to be met.
The benefits of keeping the ego in check, letting your guard down and being vulnerable are tremendous but often incredibly hard.
How do we make vulnerability easier for our teams?
Creating a safe place for team members to take a journey towards expressing vulnerability can be tricky.
Without a doubt expressing your own vulnerability will help people around you feel safer to express their own. We've also found expressing the things we're really good at and celebrating our wins has helped us be OK when we have to acknowledge something we suck at. Phrasing helps (even when its to yourself). For example: "We really kick ass at dev ops, but we're pretty bad at making sure our users actually use the stuff we release". Our weakness "making sure people actually use our stuff" seems just a bit easier to own now. Having an agile framework that we understand and value to work within has also helped the team put aside time to have harder conversations.
|My list needs to be longer but this is what I've got so far! I'd love to have conversations about making it more complete.|
Know and acknowledge your limits - bring in a specialist when needed
I've previously documented Tranzact's journey towards adopting an agile process and coming to terms with some of our bad developer habits. This journey was really one of reducing my typical developer ego and learning to be vulnerable.
In the early days, with no formal process, new projects coming online, dropped balls and failing communication Tranzact were starting to feel some pain. What did we do?
- Change nothing
- Adopt a standard
- Bring in an expert.
In the beginning our fear of the world changing around us kept us from making any change. We just kept doing things the way we had been doing it. Later our developer egos got in the way and we developed our own issue tracking system and release process. Eventually we adopted an agile process, but only after nudging from clients and feeling enough pain that we were almost forced to make a change.
We switched away from our own issue tracking tool to one that helped us follow the 'Scrum' steps I’d found in a short online course. The team was mildly optimistic but also sceptical that all this would make things better because in the moment there was just extra pain. The tool we’d adopted needed configuration. Switching to it complicated our automated releases. And it didn’t have some of the features our home grown software had. The team was seeking answers to their whys and no one, including myself had the answers.
Tranzact could have avoided a long, risky journey of discovery of how to operate as a team if we’d been able to acknowledge that we’re not the best at everything and asked for help. Bringing in an expert saved us from probably never discovering the true value that can be achieved by working effectively together.
Have you been part of a similar journey?
Make sure individuals and the team understand why work is being done
A couple of years back I asked the team if they had moments when they didn’t know what they were supposed to do to do their job or didn’t know what was expected of them. Without hesitation every person put up their hand.
What do you feel when you get this news?
- It’s a fast paced world. Who has time for clarity on whats and whys. We’re just trying to keep our head above water.
- Believe the team is self organising and hence its not my responsibility to help them understand what is expected.
- Worried! The team should always have some clarity of what is expected of them.
- It's fine. Low clarity breeds creativity
In our more recent years Tranzact has gotten good following the agile process. We stand up, retro, plan, pair, review, measure. The team typically know how to keep busy this way. Tasks get moved up the backlog, get actioned and get out the door. This way the process allows everyone to feel held, feel safe and empowered with something to do. It’s a good runway.
We found that the the process itself didn’t necessarily help us hit our targets and this was mostly because those targets weren't particularly clear. We were moving things off the backlog and this worked great for operational issues because people were jumping up and down asking us to make their very real and current pains go away but that even short term product build goals often suffered.
I have made the mistake of not planning even one 'why' up for awhile and we’ve really only started radiating our goals in the last few months. The cost of not thinking 'why' is actually higher than I initially imagined. We may have been building slightly the wrong things but it also meant the team wasn't empowered with purpose. Churning yet another bug or small operational enhancement off the backlog feels empty compared to working towards something bigger. A team empowered with higher level purpose will hopefully be in a position to feel motivated and take more ownership.
|Some project goals at Tranzact|
Side effects of not understanding why
- Lack of purpose
- Lost opportunities for learning and motivation
- Lack of ownership
- Invalid feedback
- Building the wrong thing
The feedback from the team a few years back has come to mean option number 3 for me. In fact in hindsight the fact that the team so readily put their hands up meant in those moments we probably had a failure at a number of levels.
In order to create goal clarity at Tranzact we are playing with a couple of techniques and frameworks. I hope to get a post up soon with our learnings there and I'll update with a link here.
Once our goals are clearer we hope to be in a position to celebrate our victories (because we finally know what victory looks like) and have critical conversations about missed goals or other noticeable inefficiencies because of the same reason. We'd like to know where we are going!
Don't micro manage by taking over delegated goals
Our journey of ego reduction, vulnerability and an effort to connect to the reasons we do stuff has left Tranzact in a much better place than we were, but it is amazing how easy it is to damage a good thing.
I have a horrible tendency of stealing ownership and in the process creating large amounts of work for myself and disabling perfectly capable ‘owners’ from doing their job.
Here’s a scenario
Alex is running with a new feature but I notice something hasn’t been followed up on as soon as I would have liked. What do I do?
- Personally follow up with the client and pass feedback on to Alex
- Remind the Alex to follow up with the client.
- Let the Alex fail to follow up if it is safe and have a conversation if goals are missed as a result.
- Open communication channels to allow Alex to talk about his approach.
- Relinquish the Alex from his duties as he’s clearly going to
There are countless examples of my bad behaviour scattered through any given week in Tranzact’s history. I will frequently choose 1 or 2. I believe that every time I do this I'm:
Stealing ownership. Alex, armed with responsibility and a clear goal can figure out how to achieve his goals in his own, potentially better, way and if he fails he has an opportunity to learn. My micro management moment also creates work for myself. In the case of 1) The people I follow up will naturally start talking to me rather than Alex and there is a risk Alex will be cut out of the solution. In the case of 2) I am now an inefficient middle man as Alex will rely on me to be his task management system. Thus,
Some consequences of of micro management
Don’t let team tensions go unresolved
Over the years Tranzact has grown to become a diverse collection of individuals from different backgrounds. Naturally we’ve had tensions and personality clashes. I am conflict averse and this has meant it's been incredibly difficult for me to actively get involved to help people resolve their differences so they can get back to working symbiotically.
Here are some voiced Tensions from Tranzact’s world. Anonymised.
- Bob mentions he likes working on Project X over Project Y because Harry is better at making it clear what he needs to do.
- Larry mentions he’s not too sure about Bob because he’s unfocused and takes risks.
- Bob mentions Chris can be daft sometimes, suggesting he’s not good at his job even though there is evidence this isn’t true.
- Mike says Larry’s work ethic seems to be slipping and he doesn’t trust his check ins.
What about non verbal observations and feedback?
- Jo often arrives late for meetings.
- Larry never seems to pair program with Bob, no one says anything but the stats don’t lie.
- Mike and Bob almost always review each other's code.
- Chris often interjects with lively but off topic banter and seems to break the focus of the rest of team.
In a team that is open to vulnerability that has a lot of trust there is a high opportunity to resolve these tensions easily. The level of team trust and vulnerability required increases with each intervention that follows.
- Don’t worry, Larry was having a tough day, the comments were probably harmless.
- Protect the team culture by moving someone incompatible out of the team.
- In a safe 1 on 1 space, ask if a deeper discussion would be useful.
- Organise team discussions covering topics like respect, disruptions, focus, quality (or whatever tensions are brewing) and let the team build awareness.
- Create safe spaces where the team learn about each other's strengths and weaknesses without feeling judged. Trust is built by honest conversations about habits and conflicts.
Even though unresolved tension is bad, In my experience one of the other damaging things I’ve done in the past is to interject in a controlling way without understanding exactly why there is a problem. A non critical, inquisitive opening in a high trust team will probably result in the right discussion rather than one filled with my preconceptions.
Summing it up
Tranzact and I are still working hard. The improvements are definitely coming faster than they did in the early days, but we've still got lots to do. We've learned that you need to continuously identify areas of improvement and then commit to working on them in clear and measurable ways.