Can you elaborate on "attention", and what does "protecting" it look like? (I've seen this reasoning used to keep developers out of requirements gathering, for example.)
I've never been an engineering manager so this is my perspective as a software engineer:
My attention is my ability to concentrate on what I need to do right now -- not what the company needs in a broad strategic sense, not what the stock is doing, not what might be on the horizon in a few weeks. All of those things are important to me but my attention can only be on one at a time. And I think the reality of serious software engineering is that sometimes you need to concentrate on the code and not on the other things.
Protecting my attention means knowing when I need to be in the "zone" (asking if you aren't sure); giving me plenty of warning if I'm going to be involved in things like requirements meetings; totally insulating me from any corporate politics except where I've asked to be informed or it directly affects me; and escalating appropriately (HELO phone?) if I'm too busy to answer e-mails/chats.
I absolutely think you want engineers in requirements meetings, but I also think that if you have an engineer who should be in the requirements meeting and she's super busy implementing that autonomous social-graph API then hey, move the meeting.
I am an engineering manager, formerly a dev, so I know what you mean.
I have a rule that I'm the gatekeeper to my group's time. My people know that if someone tries to contact them directly (unless as part of an ongoing project/conversation), they're to direct that person to me, where I can set expectations appropriately. It doesn't happen much anymore.
I see part of my role as a liaison between my group and the rest of the company.
My people don't fight fires, there's a team for that. I'm sorry that you don't feel like your issue gets the attention it deserves over there. Those guys are swamped. Pinging my team directly is not the appropriate resolution.
Usually, what happens is someone from some other group (sales, support, services) will come to me to ask a question. If I don't directly know the answer, I'll throw the question in a Slack channel. My ask of my team is that they check that before they head out to lunch, head home, etc., because it's usually a 5-minute investigation.
We had a "visionary VP" who'd visit the devs personally. I placed my desk at the entrance to our area, so that I could catch and block him (and others).
We had a basket of shiny toys (eg books about XP) to keep this VP amused, satisfied that we were sufficiently forward thinking enough.
For my part, I've always moved my devs closer to the customers, bypassing the internal hierarchy. More signal, less noise.
>I've seen this reasoning used to keep developers out of requirements gathering, for example.
That can be fair reasoning if you already have difficult work to do and your customers are noisy, disorganized, or inexperienced with developing requirements (think NYC window-shopping for features on someone else's credit card).
On a serious note, I have seen more projects ending into dumpster because we listened to customer too well and didn't actually infer the meaning which lies between the lines.
Most managers I have encountered are just messenger pigeons. Sometimes I wonder how system still works!
The best way to do it would be to funnel all communication with the engineers through the manager. This includes questions, ideas for new features, feedback from customers, and so on.
What you want to avoid is random people (and that includes higher ups) pinging the engineers directly. That can be incredibly distracting and can result in large decreases in productivity, not to mention higher likelihood of bugs and other problems as the engineer is kicked out of their "zone" and loses their concentration.
I've worked in larger organizations where communications got funneled through so many managers that any problem, once it was a cross-team or cross-department issue, got lost in a giant game of telephone.
A pretty significant issue that could have been solved by a single configuration property change took nearly a month to accomplish just because the problem got lost through a miss in communications in one link of the chain.
Definitely. If a simple config needs to be flipped, the engineers can communicate directly across teams.
The problem is when requests for larger ideas and tasks do not go through your PM/PO (they should be protecting their team from "malicious" requests so they can meet their milestones on time).
For example, someone from product or marketing shouldn't be able to walk up to you randomly and request that you build something for them. (When they do, redirect them to your PM/PO.)
Can you elaborate on "attention", and what does "protecting" it look like? (I've seen this reasoning used to keep developers out of requirements gathering, for example.)