Ask HN: How to speak like a leader, not like an engineer?
I am a technical manager and currently in a leadership role. My manager who is an executive, keeps telling me“ don’t talk like an engineer, talk like a leader” when I go to him for any people or operational
Issues. I always see from an engineer lens and possibly missing leader or executive perspective. How do I develop or change the way I talk as a leader. Did any one face this issue in the transition. Any pointers can be of great help.
217 comments
[ 3.0 ms ] story [ 248 ms ] threadI’m a fan of Jack Welch when it comes to leadership, and I’d recommend thinking about the “4e’s and a p” method. https://jackwelch.strayer.edu/winning/leadership-4es-p-energ...
In particular, how can you energize others around you? As a leader, you need to motivate, inspire, and instill confidence, almost every day. You don’t have to be charismatic or a good orator to do that either. You need to learn how to connect with your people, understand their motivations, and utilize that understanding in how you speak to them (language, tone, timing, feedback).
Lots to unpack here, but that’s my rapid $0.02 on HN. Good luck!
I’d recommend “Winning” as a great place to start. It’s a good and quick book on tape too that you can listen to over a week.
https://www.amazon.com/Winning-Ultimate-Business-How-Book-eb...
Ben Horowitz also touches a lot on leadership in The Hard Thing About Hard Things, which is a personal favorite.
Checked out your website and love your cause! Please don’t hesitate to connect if I can be helpful. Email is in my profile.
Are those your are leading having issues with your communication style?
If this is accurate, you left a lot of details out of your first post. Most of the responses won’t help you at all with this specific situation.
This seems like a budgeting issue. What did you promise your direct report?
The third layer on top of all of this is strategic thinking (in theory, what your executive team is providing... even higher level and longer term abstract goals).
Your executive team thinks strategically about what the goal is, your engineering management thinks tactically about the people and tasks needed to complete the goal, your engineer thinks operationally about how to build or design the work in each task.
It's been 1.5 years since I transitioned from a Solution Architect role and into a Technical Manager role, and I still struggle to keep myself out of my devops-team's kitchen. I'll still offer advice and direction based upon my past experience, but try to maintain those "teachable moments."
But for me, the only way I could fully scratch that technical itch is to pick up some hobby electronics projects at home.
Ironically, most recently I ended up building an Arduino traffic signal light for the office, interpreting data from our Sensu/Telegraf/New Relic APIs, just to show my team when our servers are struggling. Heh
I have also seen some still be able to get into the nitty gritty too to help solve problems that are critical & beyond their reports' abilities at the time and to ease the pressure.
I block off some time each day to do ‘something technical’. Sometimes it’s making something pretty that was ugly before. Sometimes it’s learning a new tool my team is considering to pick up. Generally these are things that are important, but not urgent.
For larger projects, I often attend the design reviews. Sometimes I help on the designs, especially if it’s a new product altogether.
All managers on our team are also required to participate in the on-call rotation.
Between those three, I feel like I am still “in the trenches” enough to not forget what it’s like.
But you can certainly do something small in between.
Lets think about clarifying business ideas. Non technical people are familiar with issues in their business areas, but they may not be able to clearly describe the issue or identify root causes. Your job as a managerial level engineer may be to interpret a vague understanding that something is not as they want, into statement that can be evaluated as a engineering problem. You may in that interpretation process find that the problem at hand is not a technical problem or that there may be effective non technical means to solve it. Remember that people you are dealing with have developed very different skills to address issues in their businesses areas, and engineering style problem definition is likely not one of those skills. For example, a typical sales manager might deal with sales issues by getting a lot of people in a room, generating visibility, enthusiasm and consensus. He may see that as the way to solve engineering issues as well. Just as you may not have developed the skills to generate institutional momentum and enthusiasm, others may not have the developed the skills to approach problems with engineering perspective. Your value comes from doing that transformation for them and then communicating it to them in terms of their skill set.
Take an example, suppose a peer tells you that it is a problem that you do not "talk like a leader". What does he mean by a leader? I have heard hundreds of definitions of what a leader should be over the years. He is trying to express a mismatch between your managerial execution and his ideal, but I'm not sure if leader is the exact word he wants to express that mismatch. Which of my hundreds of "leader" definitions would most closely match his primary complaint about your execution style? Lets go a step backwards to "dont talk like an engineer". I suspect this statement is getting to the source of his primary complaint so lets investigate this statement.
I mentioned above that you need to advise at the proper level of abstraction and in terms of other peoples skill sets. If you are in a managerial meeting about a new product X and you start talking about Ruby on Rails vs Django or using C++ vs Rust, then you are talking at the wrong level of abstraction. The business does not care if X is Ruby on Rails or Django. They care about whether its a good technical idea. Should they put resources into X? How much will X cost? How long will X take to create? And most importantly how well X might or might not solve the well defined problem you clearly communicate? If you have ever talked technical details in a meeting, then you are talking like an engineer, and your talk is irrelevant to their concerns. Conversely, if you are ever in a meeting, and a peer manager suggests they really need a Y implemented to solve their problem Z, then your job is not to give them cost and timeline information on Y. Your job is to understand that your peer manager might, himself, be operating at the wrong level of abstraction. Y might the the solution to his problem, but maybe he would be better off with a different technical solution. Or maybe he needs to see the problem in a slightly different light.
I cant be sure, but I suspect that you dont have to change perspective and become a leader. Your perspective probably has a great deal of value to your company but you are just not presenting that perspective in a way your peers find maximally useful.
If you want to get such experience without sourcing and paying a coach, read Jocko's Extreme Ownership: https://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs/dp/1...
Marc Andreessen called this out as the book he gifts most often, which IMO is a strong positive signal.
I personally found the book a bit difficult, but I think that's a flaw in me more than the book. The person I received it from is someone who lives it much more fully with staggeringly impressive results.
What do you mean when you say, you "found the book a bit difficult"? As in tedious to read, or difficult to implement?
Of course I have responsibility for my reaction and my mindset in situations, but it seems that the book creeps into "taking the blame for everything". Though I get the feeling that fuzziness comes from my worldviews as much as Jocko's.
I've got a background that involves a good amount of shame and anxiety, so I think I have problems with the distinction between feeling "responsible" for situations in the "shepherding" sense, which is what I think Jocko wants, and feeling "culpable" for situations which is what the inner voice of shame freaks out about.
The difference between "culpable" (bad?) and "accountable" (good?) is a very nuanced one, and I haven't been able to fully reconcile those ideas.
It reminds me of this SSC post, about different people needing different things or getting different things from books.
https://slatestarcodex.com/2013/06/09/all-debates-are-braver...
It's been a year or so since I read the book. Sounds like I need to revisit it and get some clarity on my stance.
1) try to teach them something new or interesting that has been learned that they can add to their box of tricks/intel that they can pull out later in other conversations. Include people/orgs that are involved. Include observed successes/failures.
The goal is that when they leave the conversation - they've learned something - and they've pegged you as someone who has something interesting to share.
2) avoid status reporting - that can move up through the regular chain of command.
3) discuss side projects or other things orthogonal to the immediate business - but that might be value to another or future part of the business.
4) avoid too much of the "idea guy" stuff - keep the things talked about to things that are real and tangible. I'v'e found that idea's that often seem grand and cool to me on reflection appear rather naive and unattainable.
..take all of the above with some salt - your millage may vary.
I'm trying to think of what such a thing might be and coming up short. Could you expand on that with a simple example?
"talked to my buddy who works for X they did this thing _____ ...big mistake"
"I've been collecting articles about ______, interesting trends X,Y..."
edit: another good one: "I went to meetup, talked to a bunch of people and heard some interesting experiences with _______"
* Robert Cialdini's "Influence: The Psychology of Persuasion * Jeff Cannon's "Leadership Lessons of the Navy Seals" * Dale Carnegie's "How to Win Friends and Influence People"
Attend Public Speaking workshops. If there's a ToastMasters club in your area, join it. Improv can be another great way to learn how to get "less rigid" and more open with your communication style.
https://www.amazon.com/Influence-Psychology-Persuasion-Rober...
https://www.amazon.com/dp/B0053ALPPQ/ref=dp-kindle-redirect?...
https://www.amazon.com/How-Win-Friends-Influence-People/dp/0...
It helped me go from being too shy to give a presentation in front of one person to giving talks to hundreds of strangers at a time.
Pro-tip: you can attend the first one or two meetings of each toastmasters group for free so if you're a broke student like I was at the time, just rotate the groups since there are several in each city. Also universities often have great toastmasters clubs.
IMO it's the valuable part of Toastmasters. Toastmasters in general was too much of a cult-like environment for me, I wish there was a toast-masters 'lite' with just the table topics.
The thing about table-topics is you can't simulate it. People think they can do it until they get up in front of an audience of strangers. It's like that Mike Tyson quote: "everyone has a plan until they get punthed in the face" (couldn't resist)
If something you say is wrong, respond with that’s what I was told to deflect blame.
Gather information from your subordinates and then report it to your superiors without giving your subordinates any credit.
Read books by Peter Drucker and Harvard Business Review.
Pepper your conversations with terms like: "knowledge transfer", "velocity", “MoSCoW”, “KPIs”, and talk about “surfacing” information to your users.
Good luck!
This reads bitter. In truth, higher ups generally do not care about who needs to be credited.
If anyone in their org accomplished something, the higher up has accomplished it personally, by representation.
Trying to take credit up the chain is like your hand taking credit for putting the spoon of food to your mouth.
Leadership requires some psychopathic traits: https://www.elitedaily.com/life/motivation/psychopaths-make-...
Besides your boss keeps you in engineering class position and criticizing the way you talk without conveying his thoughts clearly or specific ways for you to talk.
I'd question his leadership skills. It maybe that you don't need to change much after all.
I wouldn’t consider anyone without these qualities as a leader, no matter their pedigrees.
First, litter your conversation with baseball metaphor. You want to be fielding questions, starting sales plays, being the biggest swinger, and touching base. All this right off the bat of course (to get the ball rolling).
Second, make prestige noun/verb mistakes. After goaling your IT spend, you'll want to incent team members. Share your learnings from a go to market perspective. This is the best way to add logos.
I'd share more but I'm currently out of pocket. Going forward, feel free to reach out to learn more about talking like a leader.
Despite the win-win dialog we're having, maybe we should take it offline.
It's a type of obscurantism. It also sounds like a bunch of shibboleths, secret handshakes of the C level people.
Why do we accept terms like re-structuring, downsizing etc? Can't we just call it what it is: "Firing people?"
All downsizing involves firing people, but not all "firing people" involves downsizing.
True, people can abuse those terms for a doublespeak effect, but they have legitimate uses.
Yeah, and opium sometimes has legitimate uses in pain management.
Language as signal - jargon:
I'm going to steal a couple lines from this comic: https://xkcd.com/1735/
* Appreciate that the way you are interpreted is your responsibility
* Understand that there's no way to opt out of sending messages based on how you present yourself, and that attempts to do so send strong messages of their own
Signaling that you're in somebody's ingroup can result in comfort and credibility. You want this.
Used positively, tribal language lowers the cost of communication between parties. When I'm talking to engineers, our shared word for "diffing", when referencing things that aren't code, saves a LOT of time, because it's a "symlink" to a more complicated and specific concept of comparison. It has the secondary benefit of signaling, in a very short space, a certain minimum depth of familiarity with a domain. People who are neither technical nor curious don't hear those words as potential references to deeper concepts. They just hear silliness. They are missing something important and useful.
All jargon falls on a spectrum between "deadly effective", "tryhard", and "absolute horseshit" depending on its specific use. Leadership jargon can be every bit as deep as nerd jargon.
There are a lot of comments in this thread with various levels of butthurt that lash out at the unproductive use. When jargon is used ineffectively – or performatively to signal competence, insight, or proximity to the perceived cutting edge – its power is diluted and it risks becoming a cartoon of itself. The people who are misusing it have turned it from a thing that sounds silly to outsiders into a thing that is legitimately silly.
But don't make the mistake of assuming leadership jargon is hollow by default. If you are the conversation partner with weaker domain familiarity, you are poorly equipped to determine whether a piece of jargon is being used to convey something hollow or something important. Every piece of it started out meaning something. Dig in a little. Embrace the language of other people's domains instead of acting too good for it.
Level of detail:
Speaking of language and signaling...
In engineering land, getting in the weeds, knowing very specific things, spending lots of time exploring finer points all equate to thoroughness and signal that you're a good nerd. In management land this can signal the opposite: an inability to prioritize. "Getting The Big Picture" can come off like a quip from a hellish 80s yuppie boss, but it's important to scope your level of abstraction to your audience, and the higher up the org chart you go, the higher level your conversations are expected to be. People are going to have their own ideas about what's important, so there's a multi-level game of knowing how to find out what you need to know, knowing those things, knowing what other people think is important to know, and sending a signal accordingly.
Range of vision/concern:
One of the lessons I had to learn painfully a couple times is that sometimes being protective of or generous to your team can be bad leadership. For as much as you are a downward facing shepherd of the people who report to you, so too are you an upward facing shepherd of the organization that sustains you and all below you.
There were times when I pushed for product directions, features, headcount/budget allocations, etc that would be best for my team, the people on it, or the problems we cared about. I butted heads with the C suite a bunch, everybody had a bad time, and it was only once I had some time and distance that I looked back, apathetic where I was once deeply passionate, and realized that the things I was p...