- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
I generally don’t like “listicles”, especially ones that try to make you feel bad by suggesting that you “need” these skills as a senior engineer.
However, I do find this list valuable because it serves as a self-reflection tool.
Here are some areas I am pretty weak in:
- How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time
- How to convince management that they need to invest in a non-trivial technical project
- How to repeat yourself enough that people start to listen
Anything here resonate with y’all?
You must log in or register to comment.
Most of the points are good advise, a few of them rub me the wrong way. Considering that the author is somebody in higher management, a few of them sound like “how to collect brownie points” and “how I’d like my butt to be kissed by my underlings”, utterly self-serving - OTOH maybe those indeed are the rules of the game, and those who think that particular game is worth playing might want to pay attention.
Any specific examples? I never got that impression, but maybe I’m being naive.
More likely that I am the naive one - I know that there is no place without politics (we’re all humans after all), but I strive to minimize politics, because it drains me.
What I meant specifically were those two points:
How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid
and
How to get other engineers to listen to your ideas without making them feel threatened
Beyond basic human courtesy, I don’t agree that the fragility of other peoples ego should be the leitmotif of communication in a professional setting. I’d think a senior engineer should be able to speak up without beating around the bush, both to peers and higher-ups. I would assume for the higher-ups it should be more valuable to get candid responses from those in the trenches than smile-and-nod-yes-men responses.
And I think the counterpart of the second “listen to other engineers’ ideas without feeling threatened” is really good advice, because unlike the other one it is under your control and also a good thing in itself.
Then I also find “How to get another engineer to do something for you by asking for help in a way that makes them feel appreciated” has a bit of a manipulative touch.
That doesn’t seem politics to me, but empathy. Approaching people without considering their moods and feelings is a recipe to be badly interpreted (specially given the ambiguities in human interaction).
I would say part of being truly efficient in any role is being able to do the role efficiently even in less than ideal situations or with less than ideal coworkers.
In my personal experience significantly more people think they don’t react emotionally than actually don’t react emotionally so it’s better to support each other than trying to inefficiently turn into machine together.
How to convince management that they need to invest in a non-trivial technical project
How to convince management to stop throwing money at a dead end plan
In my sad experience, you don’t but simply try to avoid getting caught in the blast radius of it failing. Someone approved/supported the project and someone approved/supported the sunk cost that already went into it. Those people have more power than you and they will not like looking bad due to you.
How to repeat yourself enough that people start to listen
I mean, if it works for parrots, there is no doubt it works in corporations too.
I’ve seen this text when it was published, and it was pretty eye-opening at the time. I liked it so much I’ve set a quarterly reminder to go back to it and review where did I manage to improve.
Seems like a solid advice.
Soft Skills are soooo important, and the number one (which I think is getting kind of pointed out above) is communication!
-
You need to be able to explain things in a non technical way.
-
You need to understand who your audience is and what is important to them. Do you have a technical priority that you want to get built? Then you need to explain it in terms of your company goals, quarterly OKR’s or how it could impact revenue.
-
You need to be able navigate conflict, know which battles to fight, and how to deescalate if necessary.
-
You need to be emphatic, and you need to use that empathy to help guide less senior developers.
-
