Comment by CodeMage

The Coaching Habit is a fantastic book and is the right way to do. Managers don't exist to solve other peoples problems; it's vice versa.

Managers are accountable for a problem, and responsible for building a team that can solve it in the most cost effective way. Their team members are responsible for solving the problem. Managers are also responsible for a lot of other things (tracking, reporting, cost management, roadmaps, change management, hiring/firing, process improvement). IME the managers who don't like the coaching side largely don't really want to be managers or don't understand that distinction in responsibilities. (Not helped, TBF, by lots of pretty awful promotion schemes that don't support people on that path).

What The Coaching Habit does leave out is the need for mentoring. Mentoring is not a synonym for coaching, it's active: "my report does not know how to do this thing, I need to tell/show them how to do it." While coaching: "my report knows how to do this, they need a soundboard for getting to the right answer."

It can distinctly suck some time, for both parties. However, in the long run, when managers stop coddling, their team members start growing. One person who hated me bitterly when I started on the coaching road with them now thanks me for it because it helped them to build their confidence and ultimately their skills to become a CTO. I have similar stories from others. YMMV.

My biggest complaint about some people is that they measure success by the act of doing and rarely by the result.

If I help someone, I am checking if you no longer need help. If I say I’m going to be there at a certain time, I remember every time I’m late. If I do laundry a certain way so I won’t lose a sock, I make sure I haven’t lost a sock. When I do something, my brain replays me “Oh the last time you did this, you made this mistake. Do you want to try it a different way?”

People read how you are “supposed to do things” and feel good when they do it. If you switch to measuring your work by your result, you learn way faster and also get really good at things.

Three buckets of "management":

1. Mentoring: "this is what I did in a similar situation..." - overused and often not as similar or detailed as needed.

2. Coaching: "what do you think?" valuable for longer term development that depends on deeper thought and introspection; Your immediate problems a generally neither of these.

3. Sponsoring: "You mentioned you're looking for X and I heard about a new project where you could learn... want me to connect you?" under-used by managers, super valuable but harder to scale & can be hit/miss.

What your ICs actually need a lot of the time: "solve this problem for me." Most managers can't do this, which is why they became managers. The good ones combine their own skills with 1-3 above to unblock and DON'T push it back on the requestor.

This is a main reason why Agile Coaches often end up with such a bad rap, and the role is on the outs.

They're supposed to be people who can work with leadership to ensure the right people are on the right teams working on the right stuff at the right time. And turn around and be able to help teams untangle their QA and CI/CD processes to speed delivery.

Instead, the damn "life coaches" got their foot in the door and started infecting everything. The only time "coaching" is a valid approach is when both you and a coachee agree that the person has what they need to solve the issue and just needs a sounding board or a rubber duck. There's nothing more infuriating that needing help solving a problem and being told "well how would YOU solve the problem?" Idiot, if I knew that, I wouldn't be asking!

The "required" reading for newly minted managers in my $billion company was/is this shit called "One Minute Manager": https://en.wikipedia.org/wiki/The_One_Minute_Manager, including "one minute reprimands" as if employees are children. Happily, I am no longer a manager.

So basically a crash course in psychoanalysis?

> "The Coaching Habit."

Oh wow. This comment just completely explained the worst "manager" I ever had. They must have been using this terrible method.

>no matter how direct the request was or how much it really needed management authority behind it.

They nearly drove me insane with this circular cycle. It was the only job I ever walked out on. I emailed on a Sunday night that I would not be returning to the office after a particularly terrible cycle of this nonsense.

To be clear I am not a "needy" employee. When I ask a manager for something it is because I do not have the authority do the thing.

You're describing one end of an extreme.

The opposite extreme is you have someone on your team who is only able to resolve conflicts by having their boss intervene.

E.g. you leave some critical feedback in a PR review. The author of the PR doesn't like your comments, so they tell your mutual boss, then your boss comes to you to ask why you left the comments in the PR, instead of the author coming to you directly.

Obviously there are cases where it's appropriate for you and a coworker to address a problem directly with each other. And there are cases where it makes more sense for your boss to intervene.

The problem is the culture at some jobs gravitate towards either end of the extreme. The ideal is somewhere in the middle. A good manager will find that balance.

There's a good chance he was an executive's nephew or some other protected class.

Control, responsibility and accountability have to align.

* You should only be accountable for what you are responsible for.

* You should only be responsible for what you have control of.

Bad managers hate this structure because in makes them accountable for themselves and their subordinates and prevents deflection of blame to low level employees.

Being responsible for something while having little/no control is so demoralizing & infuriating.

This is a wonderful, succinct way of capturing this danger to businesses as they grow & jump the gap!

Came here to say this. What he describes is not really servant leadership.

Servant leadership is more or less just the concept that the leader's job is to make sure the team are working to their full capacity. This is in contrast to authoritarian leadership which says that the team's job is to do whatever the leader tells them to do.

A lot of leaders have a problem with the "servant" in servant leadership, there's an ego hit in the title that doesn't sit well with people who have more authoritarian ideas about what leadership is. That doesn't seem to be the author's problem, though.

The author's idea of transparent leadership seems centred around the idea that the team doesn't need a leader, in that the leader should be trying to make themselves redundant and should be training everyone else to be able to function without them. I agree that this is an absent manager.

If they succeed in making themselves redundant, the team will have selected another, informal, leader. Possibly a dynamic set of leaders who each take up leadership in different circumstances. Humans just do this, it's how we work together.

I think the author just doesn't want to be a leader at all, and would prefer it if they could go back to solving technical problems. This is perfectly valid. Management isn't for everyone.

I suggest the author looks at Dyad Leadership [0] where the management role is split into two parts; one part provides the leadership role (setting the vision, coaching, quality, behaviours, etc) and the other provides the administration function (approving holidays, organising events, handling HR, etc). This is used in the healthcare industry a lot, and works in the right situation. It might work for the author because they're obviously providing leadership but don't seem keen about the management part.

No - Performance reviews are important legally, it's the only company IP you're entitled to take with you when you leave etc, so this is where you can have evidence of specific projects etc.

Also - If you write the PR you want to get and give to your manager, the burden of effort falls on the manager to correct it where they disagree. If your manager writes it, the burden of effort falls on the manager to comprehensively justify your value as a matter of record. It is better the former be halfassed than the latter

The reward is helping people hone their craft and grow in their careers. Being a shit shield sucks, but the trade-off is worth it.

First, let me make one thing clear: my comment was in no way meant to be a substitute for reading the post. I was not writing some kind of a review for people to decide whether they should read the post, or presenting a summary. I was commenting on what I disliked about it and everyone should read the post to form their own opinions.

That said, I disagree with you about the context. Yes, what you quoted is the immediate context, but I think the bigger context -- the one I described in the rest of my comment -- is the more important one.

Managers are welcome to try to integrate IC activities into their job. In fact, I wish more of them did it, so I didn't have to deal with managers who equate coding to "typing" and can't wait for the AI to replace those of us who have spent years honing that particular skill.

But the IC work should not come at the cost of doing what the manager is supposed to do in the first place: provide a higher level of integration and problem solving for their ICs. By "higher", I mean in the hierarchical sense. A manager is higher on the ladder than I am, and that means they should be able to see a wider perspective and help me integrate it into my work. And their manager should do that for them, so that they can pass it on to me, etc.

The author doesn't want to be a "paper-shuffler"? Guess what, that's one of the most important aspects of their job and, incidentally, one of the reasons why I didn't pick management as my career.

I can relate to the feeling of frustration one occasionally gets when a core aspect of one's job becomes unpleasant, but that's no excuse for straw man arguments.

> All that said, to be charitable, I think what the author meant to express is that you don't want to make yourself a bottleneck as a manager,

That's not being charitable, that's just having basic interpretation skills of the very next sentence of the article.

My first manager at Amazon was like that. Loved him to pieces. He didn't micro-manage, he didn't even fully care about the scrum. Just said "I can see the ticket status myself. If you are blocked by something, need any info or resource, I'll hunt it down for you, otherwise you keep cooking".

I often describe myself as a bulldozer for my team. My job is to lay out clear expectations, do my best to steady the course free of external chaos, and bulldoze a clear path for the team to get stuff done.

Agree and follow this principle to certain degree, however there are caveats here - something being a blocker shouldn't prevent you from trying to resolve the blockers by yourself or work with your boss to resolve them ie - "hey boss, I'm blocked with task A with refactor of this code; are you happy for me to do XYZ?". Then I have options to say: "yes! excellent! go ahead!" or "no, we need to do ASD here" or "no, we cannot do XYZ right now". If every time people encountering blockers would come to me to resolve them, or wait until they're resolved I'd not get anything done. On the flipside, if every time a blocker is encountered people were to handle it themselves, then a) it might not align with my vision on what actually needs to be done here b) I'm blindsighted with what was actually done.

Clear boundaries and strategies eliminate these caveats = team members are aligned on what they can make decision for and general direction the team is heading towards.

Reminds me of something Joel Spolsky wrote about on his blog. The best managers were those who "moved the furniture out the way". Basically clear the way for the people working on the problem to do so.