This is a follow-up article to my recent article on Senior Software Engineers. The reason why I’m doing a follow-up so soon is because some interesting and useful points came up in a Twitter conversation about it, and I want to capture and build on those. The points concern different ways of looking at power and freedom. I’m no sociologist or psychologist, but as ever I’m not letting my lack of knowing what I’m talking about get in the way of waffling on the Internet.
In-groups and out-groups
Before I get into the main part of this article, I ought to fill in a gap I introduced in the previous article. Something that struck me in the Twitter conversation was that I had been ignoring out-groups. I had been defining relationships purely in terms of formal org chart type things, such as job title, years of experience etc. I think that unfortunately there’s a meta point here – I’m in so many in-groups that I had forgotten that being in an out-group can be a problem.
TL;DR explanation of in- / out-groups in case you need it: an in-group is my tribe, and the out-group is people not in my tribe, for however you define tribe. The division into in-group and out-group isn’t necessarily a problem (for instance, supporters of different sports teams), but power, status etc. can go with group membership. So, women can be an out-group, or people of a particular religion, or neuro-diverse people etc.
This adds complexity to this discussion, which I don’t think I’ll do justice to but I’ll have a brief go at here. I would expect a more experienced or more senior (in the org chart) developer to need to help someone junior or less experienced. I wouldn’t expect a male developer to think they’re better than a female developer who is actually their equal. I also wouldn’t expect a senior in-group developer to dominate a discussion, excluding both junior in-group developers and all out-group developers. I hope that you’re able to infer from the previous article and the rest of this article how this complexity plays out. Sometimes senior / junior and in- / out-group are similar differences, and sometimes they’re not.
It wasn’t obvious to me for a while, but there’s more than one form that power can take. One view of power is that it’s a zero sum game – if I have power it’s because you don’t (any gain in power I have must be matched by a loss in your power, so the differences sum to zero). This form of power can be described as power over, as in person X has power over person Y.
It’s interesting that there are other versions of power that come with different words after power. Power to is being able to do something, also known as agency. Power with is the idea that two people aren’t competing for power, but become more powerful together.
I’m not explaining this even half as well as people like Brené Brown who is an expert in this kind of thing. Her website has many excellent things, including including a summary of the differences that come the different views of power. A one-line summary, that came up in the Twitter conversation, is: Always being right (ego – power over) vs. always getting it right (collaboration – power with)
Just as there’s more than one way to view power, there’s more than one way to view freedom. A negative form of freedom is freedom from, such as freedom from abuse, from distractions etc. It’s an absence of some bad thing. A positive form of freedom is freedom to do or have something, such as free to do what I want any old time.
One freedom from that senior people can give more junior people is freedom from organisational politics and interruption, so that the junior people can get on with their day job. However, Nickolas Means (in one of his excellent videos) makes the point that it’s better to let some of this kind of thing through. I.e. be a heat shield rather than an umbrella where it comes to the rest of the organisation.
Other freedoms that senior people should give junior people concern delegation. In my experience, the best delegation happens when the person receiving the task:
- Knows all the requirements (problems that must be solved)
- Knows all the constraints (problems that must be worked around)
- Knows all the priorities (that help you rank one solution relative to others)
and then is free to do anything that fits with those three.
Things go less well when the more senior person misses out a requirement or constraint or some of the priorities. This means the more junior person does the work, thinking they’re producing the best valid solution, only to have this rejected at the end when the more senior person brings e.g. a constraint out of nowhere. Or they say “I would have done X rather than what you did, so please go away and change it to X”.
In a hand-waving way, it could be represented like this:
It’s important for the person who sets or delegates the task to not confuse correct with what I would have done. Also, adding in a requirement or constraint that you had missed earlier might mean that the left half of the blue rectangle is no longer valid, ruling out the purple solution. Or the priorities change so that, while the space of all valid solutions is still the full blue rectangle, now both bottom and right are best, and not just bottom.
The person doing the task isn’t a mind reader (just as the person setting the task isn’t) so everything that’s important should be communicated ahead of time, so that the person doing the task is free to do the work as they see fit, and is free from having to re-do work for reasons they weren’t aware of at the start.
How power and freedom relate
I think that, in this context at least, power and freedom are different but related concepts so it’s helpful to consider both. For instance, if an in-group developer exerts power over an out-group developer, then the out-group developer won’t feel free to contribute. Confusing correct with what I would have done is a power over kind of move – you want to make sure you have power over someone else’s choices, which means that they’re not free to do what they consider their best work (the solution they came up with).
It only takes a little bit of thought to see that giving up on only viewing power as power over is in your self interest as a senior or in-group software engineer. Yes, you won’t win every argument – you will need to give that up. However, there are at least two benefits to your team (and hence you) from a more collaborative approach:
- If people feel free to challenge and dissent, groupthink is less of a danger and so solutions are more likely to be effective and robust rather than partial and fragile.
- You want your organisation’s goods or services to make as much money in the marketplace as possible, so you keep your job, continue to get paid etc. One part of this is to be aware of and tackle the needs of as much of your customer base as possible. This is easier with a diversity in outlook, opinion, thought etc. If you use your in-group power to stomp on or ignore anything that smacks of out-group, you run the risk of cutting away an awful lot of the Venn diagram of your potential customers.
If you are a senior developer, you have been given power by your organisation. Use it wisely. You will still need to be prepared to pull rank occasionally, but this should be a last resort rather than a first one. Even if you’re not formally senior, you might have informal power due to being in one or more in-groups.
I invite you to look around your team and organisation, and think about how the various kinds of power and the two kinds of freedom play out around you. How can you improve things? Can you make sure that every voice is heard? When a man makes a point in a discussion such that it appears to be his but actually it’s a point that a woman has just given, can you point out that the woman had made that point? Are you confusing correct with what I would have done? Are you delegating as you would want someone to delegate to you?