One of the superpowers software engineers build is the ability to stuff their brains with context. The best can hold entire applications and application ecosystems in their head. A tremendous amount of context and world building goes into this skill, and it’s hugely helpful to the job and the underpinning of every mythical 10x engineer you’ve ever worked with.
When an engineer becomes a manager of engineers, they don’t lose this skill – their brain just gets filled with different context. It gets filled with meetings, and tickets, and charts and graphs. And people.
When they were an individual contributor, cranking on code each and every day, that context unlocks flow. They don’t need to ask questions or stop to explain things to anyone else. The only places that context needs to be shared in most cases is between their brain and their fingers flying across keyboards.
As a manager, though, there is no flow and a large part of your job is sharing that context with the folks that you manage.
Engineers are also generally advanced at pattern recognition – of mapping the current reality to some past experience or reality. Again, this is helpful for the work, but as an employee, this can work against the person managing them.
Because if they don’t know why you’re asking them to do something, engineers will fill it in with something familiar.
And, given the state of software engineering management, many past examples are not great patterns to match against – and not everyone assumes positive intent.
You can avoid this by being explicit with the context you’re working in.
For instance, let’s say you’ve asked your engineers or engineering managers to work through some metrics to measure each of their teams.
If you just make that ask, you lose control of the imagined world that request is being fulfilled in. You run the risk of it going into places you have no intention of pursuing.
So, be explicit about why the exercise is happening. And be explicit about what it’s not for.
I’m not asking you to go through this team scoring exercise to punish poorly performing teams. We’re trying to build a stronger engineering organization as a whole, and I have a training budget available to help teams that might need some help. We’re doing this to identify where to spend that money, and to identify any problems or bottlenecks in our process that we can address.
This is the sort of context that can get filed in a manager’s head as “Stuff everybody should already know.”
That’s a dangerous assumption, and one you shouldn’t make.
Because you never know what world is in the other person’s head.
And your job is to make it match yours.