Engineers are the brains that solve problems. The rest is pretty much on managers. However, sometimes engineers are solving not the right problem. And the manager’s job is to spot these cases and along with that – to comprehend how much deviation there is between what’s engineer’s brain is focused on now and what the business needs for the foreseeable future. And there always are some and there always should be some. Otherwise, I’d argue, you wouldn’t need an engineer in the 1st place, you’d need a blue-collar worker at maximum.
If the deviation looks significant to a manager, then their job is to explain to the engineer where that deviation is and why it looks like a deviation (and, it becomes obvious, there can be an argument there). Once the argument has been resolved positively meaning that both agreed on the fact that there is a deviation, the manager’s responsibility is to find a way to put things back on track.
Finding that way can be done together with an engineer in a more collaborative manner or in a more directive manner. And, I believe, the manner should be based on two measures:
a_ how much technical detail the manager understands about the project or a task
b_ and how much of an experience the engineer has
And finding “golden ratio” here can be quite tricky. However, the thing that (based on this system model) becomes required here is that the manager should have a specific point of view about both the developer’s experience and about her own level of technical expertise in a context of that particular project or task. And in order to have this view, the manager should know the developer quite well, the more the better.
That’s been said, a number of times I was quite surprised seeing how easily projects have been assigned to developers by some people who do not manage the project execution at any measurable level. I. e. developers are essentially being thrown to some project managed by some manager that at some point (hopefully, the 1st work week, but not necessarily) introduces herself to the developers as short as “hey, I’m the manager and we all need to work really well here!”
The simplified version of the back story may look like this: a boss says to a developer “hi, this is the guy who’s going to interview you; that is the guy whom you’ll never see again, but he’s also important; this is a project that you will be working on with 40% of chances (obviously, if you pass the interview); and there is another person who’s not here right and whom you won’t meet during the next 4 weeks, will be your manager; good luck”… and then, after few months, or maybe even years, of working, but not later than any issue pops up out of a sudden, the developer may discover that her project manager (that’s she been in touch with on a daily or weekly basis) doesn’t even understand who that developer is, what that developer’s been doing as a professional before joining the project, what that developer is good at or bad at. I think the essence of such project-management tactics can be summarized as “nurturing ignorance till it bombs”.
Have you ever questioned what one-on-one calls can be useful for? I hope the above provides at least one hint. Though it’s also true that some people see that project management jobs are about putting calls into the shared calendar, calculating time zone differences and creating gantt-charts (maybe even colorful gantt charts). Whatever you think the manager’s role and responsibility is primarily about, good luck with that!