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."
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."
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.
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.
A LOT of workplace conflict arises out of outcome oriented ppl having to work with process oriented people.
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.”
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.
There's no way around it.
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.
The only thing we can control for is the act of doing.
Some people just don’t seem to measure after though.
"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.
How do you explain someone who chooses to park correctly and has never received a parking ticket?
This thread chain is about people who do something and it doesn’t work out.
If you answered "no" to the above question then you answered wrong. This is true for s/parking/*/ because perfect doesn't exist.
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.
Coaching is about skills.
Mentoring is about advice/soundboard.
Mentoring is about adding information or skills such that the individual becomes more capable and thus are able to solve a problem.
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).
Seems like it got hand waived by but it's the crux of the situation, no?
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.
At least be thoughtful and say "Won't" (because they prefer management)
In plenty of places in London you’ll get to senior engineer and then that’s basically it.
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.
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.
I fully subscribe to the Conway's law, so I love creating system architecture through organizational setup.
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!
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?"
Though the Diamond Dogs would be a great peer group for Engineering Managers...
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 will force the answer out of them either way
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.