Many internet comics tell an entertaining story of interactions between managers and engineers and it’s also an interesting dynamic I’ve had the good fortune to observe from up close over the course of many different projects mainly as an engineer but also as a manager - or even something in between, mediating between the two.
With the engineering hat on, I can easily recall countless cases of getting ever changing requests in quick succession from an impatient manager (or client), asking for this to be looked at (and how long it’ll take) and this to have prototyped (and how long it’ll take) and finally that other thing analysed (and how long it’ll take).
We’ve all been there. Probably the most painful are the constant questions of how long it will take and the lack of understanding that answering that question itself takes time. Because we’re held accountable for our estimates, we’ve become wary of making them on a whim and therefore spend considerable amounts of time hedging our guesstimates by adding buffers (but not too much to look like we’re slow) and making sure we’re not missing anything major that’ll make our guesses fall embarrassingly short.
On the other hand there’s the manager, driven by external requirements mostly out of their control who need to provide timelines and progress reports. You need to find a solution for some problem which you either don’t have the time or domain knowledge to deal with yourself between two meetings and so you have to find a person or team to hand it off to.
As someone who’s been on both sides of the fence, I have sympathy for both the manager who needs an answer quickly and the developer who needs the time and peace to find that answer.
The worst thing a manager can do is keep hitting a development team with too many requests in a short time, possibly even conflicting ones. This will lead to them context switching constantly without ever getting anything done to completion.
The temptation to fire off all these requests stems from the different schedules these two roles operate under. The manager typically interfaces with many more departments and people and is therefore forced into a multitasking mode of absorbing information, collating it, and directing it to the right teams. When the results come in, the journey goes the other way and the information is passed back.
The engineer on the other hand is mainly a single-tasker due to the nature of the tasks he or she is working on: finding engineering solutions takes time and, contrary to managing tasks, task switching is expensive for engineers. Interruptions in the engineering workflow are much talked about and it’s something that every engineer can relate to. If there is not enough time to drill into a problem before the next request comes in you end up frustrated, feeling like you never get anything done.
Your sense of productivity suffers tremendously with every task that is abandoned.
This is why so many engineers meet their managers with reluctance and it’s why I feel it’s crucial as a manager to make sure your requests are meaningful and you demonstrate that you’ve done everything you can up front to ensure the requests that do come through are worth the engineer’s time and effort. As the manager you are the front desk that needs to triage requests and make sure the engineers spend as little time task switching as possible. Which means less worthwhile exercises fall on the managers’ shoulders to reject or resolve by themselves if at all possible.
This is easier when you’re an engineering manager who is still close to engineering and has retained some ability to solve technical tasks yourself. At the very least a manager should make a reasonable effort to research solutions – if only to demonstrate to the team that you’re not blindly dumping work on them that you couldn’t be bothered with yourself.
Think of it as the preamble to a question sent to an internet mailing list where you outline what you’ve tried and researched before asking your question. (If you don’t typically do that - you should.)
People are more willing to help if they see you’ve made an effort. The same goes for your team, probably even more so, because it is not that they work for you to solve your problems. Yes, you read that right.
I believe that engineering and management is a division of labour between people who methodically and in a time-consuming, high cost task-switching process produce solutions and others, who in a tedious, fuzzy, multi-tasking information collating / decision-making process triage what what types of solutions need to be found in the first place, and by when and in what order.
The manager works as much for the team as a gate-keeper and filter as the team works for the manager as a solutions machine.
One is trying to efficiently solve problems, the other is trying to effectively find out which ones to solve. One is tactical, the other strategic.
Of course this is a somewhat simplified picture but in essence it’s what I find is the defining difference between engineers and managers.
The best managers I’ve worked with have seen this as their role and it’s what I’ve always strived for whenever I was in a management position.
What is your experience with engineering or management positions? Can you relate to my observations? Drop me a line via Twitter or email and let me know!