Hacker News Reader

Comment by biztos | Hacker News Reader

Having just spent a couple weeks on a pretty hard engineering problem, after having done more "architecture" stuff for quite a while, I would definitely add one thing to the Do's:

* Protect your engineers' attention.

As a manager you are the primary firewall between the world of distraction and the world of getting shit done. Most places these days have institutionalized some amount of distraction -- the various recurring "ceremonies" -- but anything beyond that, it's essential that the manager can protect the engineers from being distracted when they're working on hard problems.

(I've been pretty lucky in this regard throughout my career, but now that part of my job is to live among the distractions it's really been driven home.)

Also:

> You’re the one who makes hiring and firing decisions. Everything that happens on your team is your responsibility.

This is, to put it gently, not quite true in larger organizations.

View on HN

While I agree with the general point here, I'm not convinced priorities are necessarily the right was around. Talking to customers/users usually seems to end up paying off in the long run, even (perhaps especially) if it's a bit rambling. On the other hand, it's the regular ceremonial stuff that leaves me agitated and unable to focus afterwards.

For me, this would mean not that managers should prevent interaction, but that managers should work to structure that interaction so that it is productive and well organized rather than a constant distraction/interruption..

I think the intent is to have a "question by default" mentality. I'm a lead and my default answer is almost always (in my head) "no" when asked for something from the team that doesn't have direct development value. I then try to get the requestor to demonstrate why e.g. a meeting is needed.

More often than not we end up solving the issue via email.

> Protect your engineers' attention.

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 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).

Correct, butttt "Customer is king."

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.

http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-...

There needs to be a balance here.

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.)

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.

That's what I thought you were getting at. Thanks for elaborating.

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.

In the Google SRE book, they have a concept of "toil".

If your engineers and builders are focused on the crisis of the moment, they aren't building.

Fundamentally, people don't do multiple different types of tasks well at the same time. Let the builders build, and the operators operate.

Sometimes literally.

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.

>We had a basket of shiny toys (eg books about XP) to keep this VP amused, satisfied that we were sufficiently forward thinking enough.

This might be the single best example of "managing upward" that anyone has ever written on Hacker News.

Context switching. Or in other words the exact opposite of Flow.

I've seen so many companies regularly invite engineers into meetings or have multiple disruptions throughout the day.

I personally believe in taking ownership of everything that happens. Learning how to work with others, get decisions made the way you think they should, how to get more resources from the org when you need them, etc are all skills. If you take ownership of them, even if failing there is not really your 'fault', you have the most opportunity to improve and end up where you want. No excuses.

Reply on news.ycombinator.com