A lot of things in management become clearer when you realize it’s much easier to measure a team’s progress than its state.
A team produces 30 units of “x” in a week. Is this good? Well, we could start by asking what the value of each unit is, or by looking at the contributions of each individual on the team…
Or, we could look at how many units are being produced over time, and whether delivery is getting more (or less) predictable. This will tell us more about the trajectory the group is on. Is the team gelling, working together better, delivering more? Or are members of the team struggling, maybe with a lack of clarity about their mandate, or because they are onboarding new people without the right process in place to support that?
There’s a concept of “self-managing teams,” which I prefer to reframe as “self-improving teams.” Self-improving teams have feedback loops that make getting better over time a team effort; they respond well to failure and learn as much from it as possible, they use estimation as a way to better surface the known—and unknown—unknowns. They invest in collaboration that levels up individuals and the collective.
The question that might emerge from this is, well, if your team does all this on its own, what is the role of the manager? Doesn’t it render you redundant?
I know some managers say “don’t bring me problems, bring me solutions,” but personally I don’t subscribe to it.
I love when people complain to me. Of course, complaining is a national past time for the British, and we don’t just limit ourselves to complaining about the weather, or the poor availability of good tea when traveling. Brexit has provided some strong fodder for complaining (where do we begin?) but really your average British can complain about anything.
But, here’s why complaining is so useful to me as a manager.
Leadership roles evolve, especially through periods of transition. As a leader, I have found my own role changing as challenges on the team change—around every four months I realize everything is fundamentally different, and the way I need to spend my time changes, too.
Recently the number of my direct reports more than doubled, and I added two different roles reporting to me. This was a very obvious instance of change, and I opened up a discussion on our team blog about what that meant. I confessed to certain things I had noticed about myself when I felt overwhelmed, and asked them four questions:
– What do you see as the most important thing(s) I do (generally)? – What are the most impactful things I do for you specifically? – What is one thing you think I should stop doing? – What is the biggest area of your work where you want/need me to support you?
But even when it’s not as obvious, your job as a manager can still evolve. Maybe you used to have mostly new managers reporting to you, and now they’ve found their feet, meaning you can be less involved and spend your time on something else instead. Maybe your team had some kind of pressing problem—a big project with a looming deadline or bad releases that needed to be fixed—but now it’s on track, so what do you focus on next?
Something I struggled with as a new manager was finding a sense of accomplishment, and as I’ve moved on to manage managers, I’ve seen this become a challenge for them, too. It’s hard to find the right success metrics upon which to judge our work because our output is to make the team better, and so hopefully we give credit generously to them.
Without success metrics beyond the team’s improvement, though, it can be be easy to feel like you’re just riding a wave of good people doing good work without contributing anything yourself.
Some managers deal with this feeling by seeing their success metric as being available to their teams 24/7 (unsustainable), or by counting lines of code (which would be like editors focusing on the number of words they wrote themselves—absurd). Some embrace the performance of management without understanding the underlying motivations. They “perform good manager” in one-on-one meetings, team stand-up meetings, and feedback cycles, but it doesn’t really make them feel accomplished, and it’s hard to put a finger on why.
To that end, I’ve compiled a list of signs that I look for in managers on my teams that suggest they’re doing a good job.
I’ve never stepped into a leadership role without it quickly becoming clear why a new leader was needed. I think it’s normal for companies to hire new leaders when there are problems that need to be addressed. So I suspect that as the congratulations die down, it’s also normal to look at the set of problems that surround you and ask, “Where do I begin?” (also normal: “What have I done?!”). I suggest instead starting with these two questions:
Earlier this year, when I was learning how to facilitate a specific type of workshop, a colleague revealed the secret to making it great: understanding the outcome and keeping it in mind throughout the entire process.
If the team isn’t focused on the outcome, than they’re just performing a process.
Now, I see this phenomenon not just in workshops that I attend or facilitate, but everywhere.
Management is full of mechanics that could easily become process performances. One-on-one meetings. Feedback cycles. Team meetings. Retrospectives. These are not inherently useful activities (and I’m sure we’ve all been in some of these that felt extremely pointless). They are useful only in service of some kind of outcome.
The key is to consider the outcome as you design the process, and to pay close attention to the behaviors that emerge as you introduce the process. Behaviors are the link between processes and outcomes—processes encourage behaviors that create outcomes.
Beau recently tweeted an observation I made to him, which people reacted to… Something to do with “plague animals” all “ending up dead”. And well… maybe it isn’t my best management metaphor.
It’s a metaphor for how we expand people’s comfort zones – the way we want to give people more responsibility gradually, as it feels possible.
I suspect most high achievers have a point where we go from energised to so overwhelmed by everything we grind to a halt. Keeping people (especially new managers) in the space where they are energised, and catching as they head towards overwhelm is part of the job. It’s great if people will realise it themselves and surface it, but if we haven’t built a relationship such that they feel they can bring it to us… what are they going to do?
This is the failure mode – people drown in the sea of things they have to do, with nowhere to turn.
Some people like to be thrown in the deep end to figure it out, but thinking about this metaphor I realise that people who thrive when thrown in like rats are people who have built up their own resiliency and support. They’re not really being thrown in, because they have a parachute to deploy and a support team on standby, ready to help.
Which also clarifies that part of the frog boiling is to help people develop resilience – and a support network. I tell everyone around me that when their job gets harder, they should make a friend. Coaching is also amazing for helping develop resilience (and self awareness) and I encourage everyone to take advantage of it (if they can). But as a manager, how you react to the inevitable failures of people on your team – do you react with kindness, understanding, and coaching?
Or do you do you take your broken trust out on the person, destroying the relationship between you in the process?
How do you react to your own failures? Do you display the same accountability and commitment to learn that you ask of them? Or do you embrace a double standard?
As I think more about this metaphor, I see that the art of change management is the art of frog boiling. As much as we might be tempted to throw grenades in there “for speed”, consistent temperature and stirring will yield the highest number of live, temperature resilient frogs.
Part of getting to good code reviews is some up front discussion about trade-offs and implications for bigger architectural changes. I think of code review as when “my” code becomes “our” code – for architecture, those conversations need to start earlier. We all live with it, decisions have consequences beyond the project we are currently working on, and it has a huge impact on our ability to execute over time.
Some things to think about when giving feedback:
Ask questions. If it’s not clear to you 1) it’s probably not just you 2) it’s still worth clarifying.
Think further out. How does the proposal affect things in 6 months? 12? We might choose a shorter term option, but we should make a mindful choice.
Consider the effort vs the impact. I think this is a really important skill as an engineer or designer that I expect everyone on the team to have some sense of. We hire experienced people who we can trust to be autonomous, and I think this skill is pretty critical to that level of trust and autonomy.
Don’t nitpick. Small details are distracting. Big picture feedback is more important. If something is a nitpick, clearly mark it as such – and then consider whether it’s worth nitpicking at all. When that nitpicking can be automated, let’s do that. It’s fine to be reminded by a script. It’s not a good use of anyone’s time to be reminded by another human.
Style guides. It’s easy to have opinion on style, but consistency is more impactful than the details of it. The purpose of a style guide is to never discuss it again. Every other discussion should focus on the substance of what is being proposed, not style.
We need to be less afraid to give people feedback in general. Technical feedback is a great place to start since 1) that is our focus 2) it is not personal. You can question and critique someone’s idea or proposal without attacking them as a person, and being able to have our ideas and proposals critiqued without taking it personally is important for any professional. We don’t have to agree with each other on everything in order to treat each other with consideration and respect.
Some things to think about when asking for feedback:
Put it in the right place. Small changes are best discussed in PRs. Bigger changes are for the internal blog (but as an OSS project should be in the README architecture document once decided).
Be clear about the problem you’re addressing. This is really helpful context for people to understand where you’re coming from.
Explain why it’s important. Make a case for the impact, and why now.
Talk about what you’ve considered. What are the alternatives and their tradeoffs? Why do you think this is the best option?
Think about the kind of feedback you want. What would be most helpful? What might other people have more knowledge of?
Be clear on next steps. When do you need to make a decision? What do you expect to happen next? Who do you need to agree / help?
Making Decisions
The goal of these discussions is to define a path forward, and they should end with a specific decision which we then act on. Non-decision decisions* are a common dysfunction that I strongly prefer we avoid. Have some back and forth, switch to a call if necessary, but at the end of the thread there should be a decision and some next actions. Review the feedback, answer the questions, and then based on that, circle back, summarize, and state the decision.
If the thread has been productive, and people feel heard, this might still feel scary but at this point we have all explained our point of view, and should be willing to accept the outcome.
* Non-decision decisions: where a decision is made by not making a decision.
This is the final part of a 6-part series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2, part 3, part 4, part 5.
We want to be careful how we create process. The fastest way to a mediocre team is to define your process around mediocrity. A slow but sure way to a mediocre team is to define your processes to gradually push them towards putting their own self interest front and centre – like the conclusions the guy drew from the promotion process we talked about earlier.
Incentivizing complexity is terrible. When you incentivize complexity, you get a lot of it. Most of it unnecessary.
Impact is contextual and subjective. Time in app is a good example – is it good if people are spending more time on your app if it’s also making them more miserable? Are there longer consequences from that?
And people leave when they feel unappreciated. When the work they are doing doesn’t seemed valued in whatever definition of value they have – financial, or recognition (or both).
If you don’t feel like you can be successful somewhere, why would you stay? Which is why we need to understand what people think of as success, so that we can give them a path – or encourage them to find that path elsewhere.
There’s a Japanese concept called ikigai – the intersection of what you love, what you care about, what the world needs, what you can get paid for. The question this inspires, for me at least, is how do you bring out in people what they love, and how they are most excited to contribute to what’s around them.
One thing that we talk about in my current team, is the idea that a senior engineer makes the whole team better. Which whilst it has the problem of subjectivity that many things do, it’s clear when it’s happening, and clear when it’s not. The person who does a lot of great work hiring or onboarding, or the person who spends a lot of time on architecture or code review – their impact goes beyond lines of code of features shipped. But the person who doesn’t work with others, or who leaves things unfinished for teammates – it’s clear they are not contributing in that way.
As we approach the end, what can we take from all this?
The dysfunctions of your organization become the dysfunctions of your product. Dysfunctional teams of mean, insecure people, build shitty products.
I have this idea I think of as the hierarchy of kindness. Essentially, we’re kind to ourselves. And on top of that we are kind to our teammates. Kindness to the user sits above both of those. If you can’t show empathy to the people you work with every day, how can you show empathy to someone you will never meet?
Or: Resilient individuals -> strong teams -> towards a purpose (the user).
But strong teams are necessary but not sufficient. All organisations have their quirks. It’s fun and entertaining to talk about extremes, but things don’t need to be extreme to cause problems.
When you don’t make decisions: product features don’t get clearly prioritized, leading to stagnation or bloat.
When teams can’t work together: your UX becomes disjointed. This is Conway’s law – Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
When you incentivize complexity: you get a lot of unnecessary complexity.
When you are too into shipping fast: what you ship is mostly unfinished.
When you are too into long, complex architecture projects: what you ship is few and far between.
When you have to do a rewrite: you have failed. How do you not fail again?
When you get disconnected from how people really operate: you create a very rigid product.
Here’s the thing about organizational dysfunction. Sometimes it’s created by political machinations. But often it’s created through good intentions and deliberate process.
Arbitrary characteristics of early team members become enshrined in the hiring process and don’t evolve as needs change. The things that make small teams successful are still lore and aren’t revisited as teams grow. An elaborate promotion process gets defined in the name of fairness as a preventative measure against fiefdoms. We experience poor managers and then we become poor managers ourselves – or just devalue the whole concept. We pattern match, but we don’t really know what the patterns are.
I love what this snippet of David Bowie captures. The idea that in art, a piece is not finished until it is experienced. This is so true for products. This is where we live – in the grey space in between.
Thanks for coming on this journey with me. It’s left me with more questions than answers in many ways, but also with a strong conviction that this is the work – understanding those motivations, and creating that alignment. I leave you with three thoughts.
A sense of accomplishment is personal. Ask someone what gives them that for a potentially fascinating conversation.
Zoom out for clarity. The disconnects appear when we step back – from the individual to the team, from the team to the users the product is meant to serve, from the feature to what the person is trying to do.
Say thank you. If you liked something that someone did or built or wrote, tell them. Impact matters to people, but people don’t know they have had an impact on us unless we let them know.
Thanks to my colleague @folletto who helped me turn a collection of disjointed thoughts into a coherent structure and introduced me to Campbell’s law, and @mattmiklic who made my slides beautiful after I destroyed everything.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
