Comment by redelbee | Hacker News Reader

Comment by redelbee | Hacker News Reader

Interruptions are productivity and creativity killers. Middle managers are of questionable utility but that layer of an organization would be much more effective if it focused ruthlessly on removing distractions.

I worked at a small company where a significant portion of my effort went toward shielding my team from the distractions created by a CEO who couldn’t seem to help meddling in every aspect of the business. I think it’s because he started out doing, or at least being involved with, many of the functions of the company and had a hard time letting go as we grew. Even after the organization grew to 50+ people he couldn’t keep himself out of the nitty gritty details, but the format of the distraction changed over time. Instead of walking up to people and interrupting them in person (a double whammy according to this study, including both an “important” person and the in-person aspect), he would send what we called “Slack attacks” throughout the day. These were paragraphs-long Slack messages without any semblance of organization, punctuation, or line breaks. Fortunately, many of these messages were sent during the very early hours of the morning so they could be dealt with first thing in the AM, but that wasn’t always the case.

In the first phase I literally moved my team location and reorganized the desk arrangement so it was harder for him to get in and bug everyone. I had to “guard” the area and try to stop him from physically entering the space, which was always a strange dance. I couldn’t control his Slack messaging behavior so I worked with people to understand that while yes “the CEO is asking you for urgent work in Slack” seems like a valid reason to switch gears, but instead let me work to figure out what actually needs to be done and we’ll catch up later about what to do.

It was a weird dynamic but there was no doubt the distractions were a drag on performance. Every time he went on vacation we saw a marked increase in productivity, and more creative solutions seemed to come up as well. I don’t wish this type of environment on anyone but in a way I’m glad to have gone through it and learned some lessons about interruptions and how to avoid them.

In defense of middle managers:

When I was a middle manager at a past job, my team kept getting bombarded with meeting requests (it was a "fire drill all the time" kind of place).

I ended up making a 4 hour "team meeting" every Friday morning to give them focus time.

I mentioned to them that they could have done the same on their own if they wanted. My team lead pointed out that since our calendars were visible in the department, having me as the organized gave the meeting more "weight" and so line employees were less likely to push for time in that slot.

That's a good point, thanks for saying it. Speaking as one of such developers who had trouble with it for a long time, plenty of us might end up feeling shy or insecure about making proactive interventions to secure time for ourselves or our teams - all while our managers might be assuming we'll make such moves when needed. Sometimes all it takes is an explicit permission from a person in position of power - them saying to subordinates, "it's fine if you block off focus time for the team in the company calendar". And, per your example, it's even better when followed by assurances of support, such as being an organizer or confirmed invitee. For better or worse, a lot of inter-team dynamics ends up being about looks.

Half my day is blocked with “no meetings please unless urgent” and it works great - but I guess it’s part of the org culture that we respect each others time and don’t do a lot of unnecessary meetings in general anyway so idk if it would work that well somewhere else

That's an interesting experience and a valuable info.

But I wonder what would be the CEO's side of the story. I'm sure his behavior was bad, I'm not pretending the opposite. But maybe he also had reasons (misguided reasons, sure, but still reasons) to act as he did. Or maybe he did not have any reasons, it's also possible.

I've observed cases where indeed people were disturbing too much software developers.

But I've also observed cases where software developers were not enough aligned with the business side, despite them being 100% sure they were.

It's a tricky situation: being in the team means that you are not impartial, you don't have a remote view, you are only seeing one side of the story. I had situations where I've observed some non-dev team explaining their needs, then the software team went away, and then came back with something that was not what the non-dev team asked. Not only the non-dev team was indeed not satisfied, but I was agreeing to them: it was not what they explained, I was there, I understood what they said at the time. Worst, in the majority of the cases, the non-devs don't just say "no, it's incorrect", they try to find a compromise. Usually, it comes from the fact they have no idea what is possible or not, and just assume that if the devs did not do what they were expected, it means there are good reasons for that (either it is not possible, or that there were others things they did not know about, such as other requests from other part of the business). As someone with a lot of developing experience, I was able to see that the problem was that the devs just underestimated the need to fully understand the business side.

It's very tricky, because for a dev (or a dev-side person), it is very easy to just ignore that. If they ask for adjustment, it's "they don't know what they want". If they point at some requirements and underline that it does not mean what the devs thought it meant, it's "these requirements were badly written". And in the majority of the case, the business-side just makes do with the sub-optimal solution and the dev-side is considering that they successfully delivered. And similarly, I've also seen some devs being happy to be very productive, going very fast in developing something ... that the business did not need at all. When not adopted, it was again blamed on the business-side for not using the solution they've developed, rather than to wonder if what they have done was indeed productive or not.

It's a manifestation of insecurity and lack of trust in the team.

This isn't tricky at all. If the CEO were concerned that developers weren't doing their jobs correctly, that's a really easy Slack message.

Why is it hard to accept that maybe being a CEO doesn't mean you're good at your job?

The CEO in this example is an idiot, but it does not mean that magically the other side is able to be impartial when judging the situation.

The fact that one is bad at their job does not imply that someone else is good at their job. Why is it hard to accept that maybe being in a dev team doesn't mean you're good at your job?

Reply on news.ycombinator.com