When I was a manager I had to take a training based on the book "The Coaching Habit." It left me really sour on the role, and explained some of the behavior of previous managers of mine that I least appreciated, specifically that their approach to management seemed to be to just get me to articulate and explain my problems over and over until I somehow rubber-ducked myself into solving them myself. When that didn't work, it transitioned to "so how can I help?", which would again eventually be turned around into "now you know how to go help yourself", no matter how direct the request was or how much it really needed management authority behind it.
I get that the point of the strategy is to help people with strong director-style personalities to listen and empathize a bit more, but in my experience it ended up being implemented as "my responsibility to my reports is to listen and nod."
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.
You've put into excellent words what I have done my whole life. Intent matters but it isn't sufficient. If you "meant to be on time" but weren't, you failed. Simple as. You don't need to lash yourself about it but too many folk are ready to give themselves a pat on the back for good intentions, or trying but failing, etc.
If you say you're gonna be somewhere, show the fuck up. Anything short is a miss. Failing to account for that makes you an asshole, IMO.
I did ceramics for a whole and noticed a common trend.
The creator judges the product compared to their imagining of what they wanted to make. Yhe piece invariably falls short (because our imagination is better than our skillset.)
Everyone else simply looked at the piece objectively. It was either beautiful or not.
I started to look at programs the same way. The criteria for judging my program differs to the criteria for judging other programs.
So for my software I care about architecture, clean code, the language I used, how clever it is.
I judge others by their UI, documentation, support, correctness, intuitiveness etc. I hate when their UI constantly changes. Even small (cosmetic) bugs turn me off.
But my stuff has no docs, the UI is butt ugly, there are some rough edges, but if you avoid the bugs it gives you the right answer (very fast) while consuming less ram, disk, or cpu. And I used new-framework or popular-new-language and runs on any OS etc.
“Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste.
But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you.
A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions.
And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.”
I tell this to everyone who will listen. This... paragraph? Statement? Whatever is pure gold.
Quit watching YouTube videos, quit reading tutorials, quit listening to podcasts. The only way you learn is by doing something, and by doing something I mean fucking up doing something. Over, and over, and over.
Just do the thing. That's how you learn. And after you make a whole ton of things that suck, you'll start making a few things that don't.
I personally feel this distinction does not apply at the granularity of people and this difference is unrelated to the issue of people who aren't observant.
I am very process-oriented about drawing. The simple act of drawing is fun and I never have a specific goal. I try different mediums and subjects for fun with no actual purpose, but I still gradually improve because of it. But I never have any idea of what I’m going to draw next.
However I am very outcome-oriented about engineering. I enjoy it but nowhere as much as drawing. If something I built has problems, I keep that in mind for the next system. I pick up new things for the sole purpose of being up to date.
But in either way, I won’t repeat something again that never seems to work. That’s the same whether I’m being process-oriented or outcome-oriented.
How do you measure results until something is done? It's simply not possible to reliably measure or predict the result of something before it's done, and at best any numbers will be incredibly rough estimates.
The only thing we can control for is the act of doing.
This works if you can connect your actions directly with the outcomes. How would would you assess the efficacy of preventative actions whose consequences are delayed and uncertain?
"I think we should X because it will probably contribute to Y."
What if Z happens? You could say "Doing X was pointless - Z happened anyway!" but then you are discounting at least two things:
1. the possibility that the magnitude of Z would be much higher
2. that it's a numbers game: sometimes you lose despite making the right decision
I don't really understand your examples in the context of decision making - they feel more like execution lapses than strategic choices.
Choosing to park my car correctly because I used get tickets is a reactive action. Helping someone because they asked for help is a reactive action. Being late and then doing things to stop being late is also reactive.
I’m not talking about preventing hypothetical consequences for events that could happen but have not even happened.
Bravo you are among 0.1% of people who check on your own behavior. 99.9% others just try random stuff until it works and don't want to bear the consequences of their mistakes
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.
Depends where you go, these two terms get used interchangeably (incorrectly IMO) and so there is some semantic drift.
If you were to read Julie Starr's "The Coaching Manual", or "The Coaching Habit", the definition is more or less what I outlined.
If you are familiar with the Leadership Continuum/Situational Leadership, the distinction from there becomes: tell/sell (mentoring), join/consult (coaching).
If tracking, reporting, cost management, roadmaps, change management, hiring/firing, process improvement, all aren't solving problems, why the heck are they doing it? Each of these tasks should be undertaken because they provide a solve a problem/provide a benefit.
As the manager is accountable for the problem being solved, they are responsible for making sure processes are optimal.
There definitely should be an onus on individuals and teams to reflect and generate their own improvement actions to that end. Scrum Retros are a good example of this. In this case, the manager is responsible for process improvement by chairing the retro, ensuring that the team has the info needed, and has the space to implement actions. Scrum Masters chairing retros can be seen as a form of coaching.
There are also times when process improvement means directly stepping in and directing the team to do something differently. This can happen for lots of reasons; one example may be a manager taking over an existing team under fire and identifying immediate changes needed to dig them out. I've seen several teams with entrenched mindsets in this situation where process improvement is directed rather than discovered.
Ideally, the team drives it, while the manager is responsible for ensuring it happens successfully.
E.g. there is a big difference between "Why did we loose a day here, what can we learn?" vs "From now on each dev needs to review every pull request twice per-day". Might be the same ultimate action, but in the latter the manager is solving the issue directly.
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.
In my experience people mostly become managers because that's the next step to more money and there is no other next step to more money. Nothing more nothing less. They certainly don't have a sophisticated philosophy on management and being the best manager they can be.
I've never worked for someone I felt was less able than I was. Maybe I had a specialty beyond theirs or more recent experience but you don't become a successful technical manager without knowing your shit. Maybe I've been lucky
Happened to me couple of times. If u have strict technical skills but lack ppl skills and u have a big team. The latter (soft skills) starts to matter more. If ur in this situation then hopefully your leader/manager understand that and gets technical advice/consultation from you.
You may not mean it but I do think sometimes framing it this way implies leading and managing is something that requires less ability (it's a skill in its own right).
What I think is true is people cap out their technical competency, and look to shift their skillset and, globally, we are bad at a) training them to be good managers (because there is a wrong assumption it's an innate skill) and b) weeding out the many who also lack the ability to be a manager.
Agree, it’s a skill, it can be learned and improved, and of course some people have some natural ability.
But for every skill there’s a floor and a ceiling. The floor for managers is imo far lower than it is for tech ICs. Incompetent managers have many options to hide their misdeeds. That doesn’t say anything about the average or the ceiling.
Why would a manager solve an IC's problems for them? Solving problems is generally the job of the IC. If an IC doesn't have the ability to solve a given problem, the manager should let them talk to a different IC with that skill.
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!
Also makes for a poor metaphor, because coaches in sports are supposed to be absolute experts in absolutely everything about the sport without the physical ability to implement it.
Imagine if a football player told their coach "I'm not sure how to deal with this specific opponent's strategy" and the coach was like "Well have you tried thinking about it more?"
there are lots of sports coaches that were not good players, but they are absolute experts in their sport. For some reason we've let agile/life coaches convince us that "management" is the event and someone with customer service management experience has a lot to say about software development management. Ted Lasso is a great show, but it's not gonna happen IRL.
Though the Diamond Dogs would be a great peer group for Engineering Managers...
They might suck at the sport, but then they think about it and learn why they suck, then they can be a good coach, compared to someone who is very good and thinks the reason is because they're smarter, rather then being on the right place on the right time, with the best genes.
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.
I'm not sure you understand just how dedicated they were to this whole turn it back on the employee method they were apparently using. I just skimmed the summary on the book after reading this comment. Its a toxic method of avoiding accountability masquerading as "mgmt"
You can't do whatever you describe if it needs sign off by a manager that simply ghosts on everything you try to send their way. You can assume responsibility but I'm not committing fraud for a company that does not care.
Also what you said means that you are now officially responsible for the mistakes which I'm pretty sure is what this whole "method" is about.
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.
I get that the point of the strategy is to help people with strong director-style personalities to listen and empathize a bit more, but in my experience it ended up being implemented as "my responsibility to my reports is to listen and nod."