The Manager as Debugger | Hacker News Reader

The Manager as Debugger

whilefalse.blogspot.com

87 pointspshaw11 comments

I like this metaphor, it accurately captures a lot of what managing is about, though it's worth mentioning that the greatest difficulties are never, ever technical, they're always about people and feelings, which can surprise a lot of new managers.

This article outlines some great first things to look for, but something important is missing: sometimes, after trying everything, it turns out that your team just has some truly terrible, morale-sucking people on it, and they need to be fired before things will pick up. That's sort of the "file a compiler bug" option of last resort, but there really are a lot of toxic people like that out there, especially amongst programmers, and as a manager you'll need to be able to pick them out and deal with them. That's almost the most important part of your job.

though it's worth mentioning that the greatest difficulties are never, ever technical, they're always about people and feelings, which can surprise a lot of new managers

I wholeheartedly agree, and would like to add that this surprises developers and individual contributors perhaps even more than it surprises managers.

>>though it's worth mentioning that the greatest difficulties are never, ever technical, they're always about people and feelings, which can surprise a lot of new managers

It can also frustrate developer-turned-managers. Dealing with software is in some ways easy because, for the most part, software is predictable: you get the same output for a given input. If you open your browser console and do:

console.log("Hello")

The output is always "Hello".

But if you go to a human and say hello, depending on their mood and feelings at that moment, you can get wildly different reactions.

P.S. I oversimplified, of course. The same function can give different results based on state, data, etc. But the point is, software is rational whereas humans are not always thus.

All you need is a mood monad. That'll fix the pesky state problem.

Can you give me a quote for a hundred man-year supply of it? Preferably in a tasteless, soluble form, so I can add it to their lunch.

I'm kind of appalled by the mention of looking through the team's emails and IMs. Is this common practice?

Maybe my experience isn't representative, but everywhere I've ever worked, we've operated under the assumption emails and private IMs are, just that, private. We know that ultimately management could look at those things, but the assumption has been that privilege is reserved for extreme situations (e.g. a lawsuit, an HR dispute, etc.).

Would love to know how it works elsewhere.

Above is my understanding where I work as well, and I am in management fwiw. I would never ever want to read my employees' private emails and IMs. The thought alone makes me feel dirty.

I worked somewhere that had an 'open' policy - you could log into the email account of anybody in the company at any time. Inevitably, people stopped sending emails.

> Look at the team chats and emails

I parsed this as group chat rooms and emails, not the team's members individual mail. As in reading the mails everybody is CCed to, Slack channels (vs direct messages), ...

The author is talking about publicly viewable emails and chats (e.g. mailing lists, IRC, Slack). I think the surrounding context makes that clear:

"When talking about a team that is not producing work fast enough, look at the records. Look at the team chats and emails, look at the tickets, look at the repository code reviews and checkins."

Balancing the focus and solitude that programming requires with the communication skills required to be a leader can be really tough. In Boulder/Denver some friends and I started a monthly CTO lunch where we can all just chat about our shared challenges. I sent this post to the group because I think it does a great job of helping technical people approach something non-technical in a way we can understand. Awesome post!

Reply on news.ycombinator.com