Accidentally in Code

Tag: incentives

  • How to build—and manage—a self-improving team

    How to build—and manage—a self-improving team

    My latest in Quartz…

    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?

    Continue reading…

  • Process Design

    Process Design

    (or: be careful what you incentivise)

    danbo-danboard-japangirl-toy-84368.jpeg

    When we design processes, we are heavily biased to design processes that we would be successful in. We see this with hiring processes, and we see this with promotion processes. You might think having multiple people would help with this but this seems just as likely to create the very narrow process that set of people would all be successful at.

    Feedback on processes will also come from this bias. This doesn’t mean that it should be ignored, but does mean that it needs to be analysed critically and different questions asked.

    Processes need to be compatible. If you have a hiring process and a promotion process and you will hire people into roles you wouldn’t promote them into, and promote people into roles you wouldn’t hire them into… something is wrong with one or the other, but most likely both.

    Your process encodes your values in the things that it incentivises. Any process that involves stack ranking incentivises diminishing others. When you incentivise technical complexity you tend to get a lot of it… not all of it necessary. If you have a process that makes it hard-to-impossible to hire people managers… you will end up with poor management.

    How do we minimises the process? In hiring I ask: what are the minimum things that we need to see someone being capable of. And then ask: how is this person great? People need to be able to function on the team, but we also want people who will add to the team in new ways – ways that can (and should) vary per person.

    In asking people to take on more responsibility I ask, who makes the whole team better? Technical capability doesn’t go very far unless people engage and pass it on. But interpersonal skills are not always sufficient to get things moving.

    It’s easier as we grow to create ever more process – sometimes with the ideal of fairness – but actually what that gives us is a longer list of things to selectively apply, and more and more reasons to say no.