Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to speak like a leader, not like an engineer?
511 points by yogrish on March 10, 2019 | hide | past | favorite | 211 comments
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.



A piece of simple, concrete, implementable advice I read recently that I really like is "communicate in the language of options, not demands, imperatives, requests, or preferences."

Imagine yourself having a conversation with your manager or someone in a relatively similar position about a decision or suggestion you have. How often do you say things like "we have to", "we need to", "we really should", "can we", or "I'd like to"? The problem with all of these statements, from the perspective of someone like your manager, is that they hint at a passion or personal preference that doesn't belong in a decision-making process or conversation. In the flow of a conversation, it may feel like you're merely emphasizing a point and bringing your (presumably solid) technical experience to the table, but to the listener it often makes your suggestions appear self-serving, poorly considered, and possibly irrational from the perspective of the business.

Try to replace the above phrases with "one option is to..." and change your thinking to complete the thought in a way that makes sense. Avoid picking favorite solutions and presenting them as the clear winner or only option. It'll get you thinking in terms of pros and cons and how to persuade other people by appealing to their point of view. It will make you appear more level-headed and capable of making decisions that are good for the business. It'll also remind you of (and force you to fully consider) the frequently hidden option that's often forgotten when presenting a new idea or direction, which is the status quo.


Given the support for this answer I will likely get downvoted for this, but I disagree with this advice.

I am a co-founder (and CTO) of a small company myself and hence get to talk to the folks in my company quite regularly. I disagree with the notion that passion or personal preference doesn't belong in a decision-making process. Not only does it belong there, it is even a critical part of it, assuming of course that you have good arguments to make for your point and convey it in a respectful and professional manner.

Having passion and personal preference displays that you are engaged in your job and identify with the work that you do and aren't afraid to speak your mind, which requires a certain level of trust. Even more, you were hired precisely because the company came to the conclusion that it can benefit from your (uncensored) input.

It sure depends on the context but presenting your thoughts as "one option is to...", is a marker that you are indifferent to the outcome. It generally does not display trust, confidence or engagement.

So, if your manager is worth her/his money he/she can handle strong opinions just fine and will also consider other viewpoints than yours in the decision making process.

W.r.t. "talk like a leader, not like an engineer", king_panic has the best answer IMO.


I used to provide several options with background and rationale to my boss.

One day, he said, with a slightly frustrated tone, something along the lines of : "Andy: you're providing what appear to be good options and detail here - but someone in a "senior" position should recommend a path forward. Don't just give me 3 options that I need to then go and figure out for myself."

from that point on I've always tried to provide a hard recommendation - and rationale that includes a sort of decision tree approach. "We start with ______ [with good reasons to do so] then if X comes to pass we continue with it and if Y comes to pass we can pick a a different path with another option I have as backup."

The result seems to often be a discussion more about the upsides/downsides and decision tree relative to the business the organization is trying to support (a good thing) vs technical merits of the options which the technical team is trusted to be well versed in.


This is the approach I often take. I'm paid to be an expert and have answers. If the situation has multiple paths, it is on me to weigh those with the context I have and be prepared to adapt when I inquire about other considerations I may have been previously unaware of.

There's nothing wrong with having an informed opinion as long as it isn't presented in a combative or selfish manner.

That said, depending on who else may be in the room, if you naturally take that approach, it is often good to sit back and let others speak, or encourage them to if they are not the assertive type. Leadership is as much (if not more) about listening than speaking.


I disagree. Talking about options is _not_ a black-and-white issue, and I feel that seeing this as being indifferent is somewhat of a stretch. Why not outline the options and their respective consequences (as far as you can observe them) as objectively as possible? Here's an example:

'One option is to do it this way. This has the following advantages. Moreover, we could also do it that way. This will likely result in ...'

And of course you _can_ give your preference---but you should be upfront about this. For example:

'Personally, I think it might be worth to pursue option 1 more because of ...'

Strong opinions are one thing, but being capable of seeing alternatives is also very, very valid. Not every [business] decision has _one_ easy answer.

(disclaimer: I am talking about my experience with academic teams inside academia; this is not 100% transferable to the business world, I would wager)


Yeah, the other thing to consider is that as you go up the chain the people you're talking to have more context across the business and may know something you don't.

Outlining options with consequences helps them make the right decision in the macro. I've have many decisions from the technical side that made sense but we're absolutely the wrong choice once I had more context around what other teams planned or the business constraints.


I agree. I'd restate it in a way that applies to both engineering and management: It's ok to be very opinionated about your job. You're paid the big bucks to be an expert, what's the point if you don't have a strong idea of what the Right Thing To Do(TM) is? If I go to a PM or manager with questions on a feature I'm supposed to develop I sure hope they have a strong opinion about what I'm supposed to be building!

Opinionated is orthogonal to being persuasive though. To work on a team you need both; you can't just say what you think is right without evidence and you need to be able to persuade others on your team that you're right. And it's orthogonal to being self aware as well, in particular knowing when you're wrong or a battle isn't worth winning.


There seems to be a confusion or overlap between what a CTO and a CEO needs to do in terms of leadership, they have different audiences.

While CTOs are expected to be heavily technical and fact based, CEOs often negotiate based on feelings, trust, wrong data and emotions with other parties (mostly non-tech) where it does make sense to open several options.

Any engineer growing into leadership will increasingly need to deal with non-tech people that will find the strong engineering opinions as leaving them out of the decision process, and subsequently be offended by that fact.

CTOs have little resilience to bullshit, they aren't known for soft-skills either and tend to be seen as leading the pack. There is a fine line of what being a leader means, depending very much on who your audience is.


Making sound decisions in engineering has nothing with personal preferences or passion. All too often these interfere with the process and, in fact, usually hide the lack of vision.


Interesting that you’re actually advocating for this type of “lord of the flies” culture. It actually indicates your org doesn’t have clear direction or technical competence (imo). I’d personally be wary of joining such a company. I’ve been a part of too many directionless zombies myself.


This might be the most uncharitable reading possible of what they wrote. Having people advocate for different decisions hardly means that the company is a “directionless zombie”. In fact, it’s exactly the opposite. Having a culture where people don’t advocate for something but just go along with whatever is handed down to them from on high sounds a lot more zombie-like to me.


I guess I’ve worked on to many apps that resulted from this sort of thing, over the course of years. In reality, everyone gets a voice and every opinion matters devolves to the vocal minority doing what they want, damn the consequences. Similar to online discussion forums really. It’s almost tautological that this vocal minority does NOT have the best interest of the product or company in mind, but only their own self aggrandizement and careerism.

Somebody at the top ought to have a vision and ability to work with feedback from real customers with real needs to deliver a product that users love and continue to pay for.

If you write an app idiots can use, idiots will

A fabulously illustrative email sig from the type of people who “win” in these orgs.


You can always come up with two options, for any problem. If one of them is terrible or expensive, say it anyway, and now you look like you’re making justified decisions and thinking things through.

The brilliance of “Design Thinking” is basically the same thing — designers and creative thinkers do their work as usual, but they present it as if they’re following some kind of methodology that even people who don’t understand the work can get around.

In the background, all of your engineering decisions are likely based in some kind of business truth, so bring it out and talk about it instead of Java GC tuning or other non-business nonsense.


A former Tech leader where I work used to say "Never say you can't do something. Just provide options, cost and consequences. The business/management/client will make the decision for you."


This is super important. Having someone come to the conclusion you care to on their own will solidify it in their own heads as their idea, making it an obvious choice. I’ve even gone so far as to argue against it with a few surface arguments, to cement it in their minds.

Is that manipulative? Sometimes. But if it’s for the benefit of the team, you do what has to be done.


This is literally the secret to being successful at business and politics.


I'm continually surprised by how many people don't recognize this as such a massive differentiator in one's ability to be persuasive.


I imagine this leading to situations where you say things like, “pursuing option X would require a research project of indeterminate cost and time, likely longer than 7 years for a 10-person team”


One place where this can fall down is when the cost is along the lines of "if we do X then we're closing down the option of doing Y" later.

Unless the business/management/client is better than average, there's a large risk that they'll say "fine, whatever, we want X", then a year later ask for Y and be unhappy that it's impossible or very expensive.


Speaking as a technical founder... That is ok.

"A cynic knows the price of everything and the value of nothing."

Marketing / sales / bd / etc do not understand most of the variables engineering is working theough. They can be big: impacting price to build/extend and when it starts being a profit center! The tricky bit is those depts also have their own tracked variables that need to be rolled into the decision. Non-engineering variables can also be critical: E.g., going to market before others, hitting some top account or partner, growing revenue by x% compounding now and using that to pay for tech debt, or even learning the workaround isn't worth improving from the customer's/market's perspective.

The humbling thing is no one has all the info, from engineering and product to sales and marketing to the execs. That is where your job comes in. So communicating opportunities at the level of time/cost/growth within engineering's field of view, and making this a non-unilateral discussion. (And if you are good, invisibly sneaking in color around all your other operational glue: who is doing well, what new ideas came in, etc.)


Never say no, always say yes but say what the costs are.


Agreed.

> Avoid picking favorite solutions and presenting them as the clear winner or only option.

That depends how stupid the management is. I remember when an ex-colleague of mine was designing a big complex thing (a mixed signal ASIC, if you care). He was a mere engineer. All the big decisions had to have management approval. But the management didn't understand much about how the complex thing worked. He tried the, "we must do this and that" approach, without success. He eventually figured out that he needed to present options. But it didn't seem to matter if all but one of the options were stupid. As long as there was a graph showing one option being better than the others, then the management could chose the option with the big score and feel like they were in control.

Moral - Figuring out how to control your boss is a good strategy but probably only works if you are cleverer than they are. I prefer having a boss who is clever than me and when I say, "we must do this", they explain why that's a stupid idea.


I have seen this in my own example.

I usually would say "To run website for customer X, we have to setup separate database server because their requirement is not having multi tenancy".

What I found out, it is something you can communicate to fellow engineer when all tasks are signed off. It is technically correct, and I did not understood why it would not be valid statement.

When you are in meeting with higher ups planning roll out for that customer, there is no "we have to". There are only options and maybe that customer was just shooting from the hip with those requirements and if we tell him what the price is we won't have that customer or he will reduce his wish list. So it would be "To run website for customer X, one option is setup new server but it will be 100$ a month and one person working on it for 2-4 days to have configuration working and tested".

Setting up separate server is not interesting part for business. Setting up server for me is interesting part because I have to put it in the context of our infrastructure, what rights should be assigned to that server, what packages I need to install on it.


When in Rome, do as the Romans do.

So, when talking to C-levels/suite, speak as they do. Listen to them for 10mins, and mirror the language.

C-suite need to say 10 things in 1 line.

When speaking technical the opposite happens. Speaking 10 lines to explain 1 thing.

Keep in mind, they don't expand. They compress/winzip/winrar.

The above 'option' is a great manner and I will change this in my vocabulary starting today!


The nice thing about presenting options along with their pros and cons is the option accepted by management also has its attached cons explicitly accepted too (often in writing)


Not sure if I agree.

When you give options, you can still have a strong preference for one or the other. Like logo A v. Logo B. It can be passive agressive to make one option looks very good and the other looks like shit. Whereas a transparent conversation will be, I really like option A, but at the end of the day is your area of responsability and if you want to do option B it’s perfectly fine.


The way I do it is mention the options and my preferred option with the justification on why my preference is better. That shows that I have thought through the problem and possible solutions carefully.


Thank you! This is so helpful.


Sigh. I suppose another batch of engineers will read this and start participating in rounds of bullshit instead of just doing what is clearly the right thing to do. If there are options, present options. If you know only one good way to do it, just say so.


As someone who has to continually push back against people who have the "one good way to do it", I'd prefer everything was presented as options.

People make these statements in front of customers and then we have to dance around it to the next option. It takes a hint of introspection to know when you might not have all the bases covered in your head before pushing things out of your mouth.

Saying something is an option at least can be interpreted as not being fully sure at this second, whereas saying "we have to do this" and being wrong just makes you look incompetent as a representative of my team.


I've had situations where I think one path forward is the clearly only sane option. But because I was told years ago to present options I say, "Okay, option X will will take a week to set up and cost $100 a month. Option Y will take three months to setup and cost $20,000 a month." But management doesn't bat an eye, they reply "Oh great! No problem, we'll get you the budget for option Y." And while I fight to keep my chin from hitting the floor, they sign off on the funds and move on the next item on the meeting agenda.

And what do I care? My conscience is clear because I presented the facts as I know them. And we get staff and budget as needed. Maybe there was some political motivation I didn't know, maybe the exec wanted to justify higher budget. Fine. I did my job and things move on.


Not doing something is still an "option".


I am an app developer who interfaces with c-suite executives weekly.

Every time I get into the weeds with them I lose their attention. EVERY time. They don't care about the technical aspects of my solutions, they care about what it means to their customers functionality, the price they pay for the solution or the time it takes a product to be delivered. So I put things in those terms. I NEVER get very technical anymore unless it's absolutely required.

In short, summarize your choices, decisions and solutions in high level language from the perspective of what they care about -- that's it.


One thing that makes this especially difficult: you will feel like you're leaving out critical information, from your perspective. An executive summary or similar communication should include the key details for high-level understanding and decision-making, not the key details for engineering, operation, or implementation. This will run right up against the fundamental human desire to be understood, because you know the person you're talking to doesn't have the complete picture of the system that you have in your head. When you're in the process of giving an explanation, it'll feel important to add those extra details to convey that rich picture. But the person you're talking to may not need that level of detail.


In short when communicating with anyone outside of engineering, figure out what they care about and speak to that.


I 100% agree. And one of the tricks I believe for this to work is that the first step is listening. And when you're tempted to talk, don't. Listen more. Ask questions in the vocabulary they're using if you want clarification, but primarily just keep listening.

Because that is how you figure out what it is they actually care about.


Yep! I agree as well, the less you speak, the more you listen, the better!


That is great advice for anyone, anywhere!


Thanks! This is the condensed version of what the OP's manager is asking him to do. As mentioned elsewhere, also keep in mind you can't change peoples' minds or make a decision for them, you have to present the your case so that your audience comes to the conclusion you want them to.


Here's a useful signal: If you are getting crickets or curt responses ("ok", "great") after you finish speaking, then you are not talking their language.

This was the first sign I wasn't communicating effectively in my client-facing role.


Leadership is basically just people-engineering and business-engineering. Engineers use tools to build products, and so do leaders.

The immediate assumption is that people are tools/resources to build the product. That's talking like an engineer.

Don't use your team to work on a project/product. Use the project to work on your team. They're not there to build the product. They're there to gain some personal fulfillment. Use the development of the product to grow them.

In my humble opinion, that's talking like a leader. Flip the engineering perspective over and communicate a new set of values with a layer of empathy.


> The immediate assumption is that people are tools/resources to build the product. That's talking like an engineer.

That's more management-speak than engineer, in my experience. I hate being referred to as a resource.


Agree.

Whenever I get contacted by a recruiter from Tek* .com or * Resource.com, I absolutely cringe.

Who uses these companies? Who entrusts them to negotiate salaries on their behalf?


I think the OP is saying that a good manager does not treat employees as resources


In this case, the boss is telling OP to talk like a leader rather than engineer to him, not necessarily to the engineers below. To the engineers below, you still have to talk like an engineer to some extent, some of the time. That's the virtue/advantage of a manager that is from the engineering background.


> Don't use your team to work on a project/product. Use the project to work on your team. They're not there to build the product. They're there to gain some personal fulfillment. Use the development of the product to grow them.

This is extremely well said and something I’ve been dancing around in my head and couldn’t quite articulate. THANK YOU.


People often say to me “it must be nice not to have a boss.” I explain to them that I have no idea what that’s like, since I have 12 or 13 bosses.

My job is to empower my reports to do their best work, using empathy and engineering the team as a well-oiled system. Sure, they report to me, but my job is to keep them productive.


Sorry if I sound harsh but I disagree extremely strongly with this. If you are evaluating someone's work and you can fire them, then you are their boss.

There is a trend of calling managers "supporters" where I work, and I absolutely can't stand it. It seriously reminds me of "War is Peace" from 1984. I don't mind having a boss; hierarchies are fine. But I feel extremely patronized and condescended to when people try to pretend they don't exist.

> my job is to keep them productive

Well, you could say the same thing about a manager at Wal-Mart or McDonald's. Their job is to make sure their underlings are productive. "Empower my reports too do their best work" is just an unusually nice way to put it.

The thing that sounds nice to most people about not having a boss is exactly that: nobody that you feel is judging whether you are productive.


Where I work, direct reports evaluate their managers and managers can't arbitrarily fire people. As a manager my job is primarily to help engineers grow and clear obstacles for them and provide air cover when they need it. Not all companies view management this way - I've worked at other companies where the role of a manager was to make sure that every ounce of productivity is being squeezed out of engineers, and at places where growth wasn't even a consideration, but there really are places where managers are supporters, and some managers are better at that than others.


Well where I work is the same way, but presumably it's not the same where the person I was replying to works, since he refers to himself as not having a boss (i.e., presumably he is pretty high up the hierarchy).

And even though managers can't arbitrarily fire you at big/reputable companies, they certainly have a gigantic amount of influence in performance review discussions.


It's not that I'm not their boss; of course I am, pretty much by definition. I'm higher up on the hierarchy (context: I'm a cofounder and CTO)

The point I'm trying to make isn't that I'm not their boss, but that by virtue of great employees being hard to find, it's my job to keep them happy and productive. Not just productive, but happy is important too. It costs the company way more to find a new employee than to keep an existing one. As such, provided an employee is doing a good job (which is a requirement in any role), it's my job to ensure they are as productive and happy as possible. That doesn't mean I don't have the hard conversation or fire if they stop working, but it does mean that my role is to be an effective shit-umbrella and keep them happy, inspired, and excited.


Right, that's the ideal of a good boss, but a boss, nonetheless. I think we agree about more than we disagree about, here. I just think words can be important, and when someone in a position of hierarchical power, no matter how benevolently they wield it, says things like "really, they're MY boss", it might be intended completely harmlessly, but can actually come off as patronizing.


I suspect we agree on the concept as well.

That’s the thing about colloquialisms; they’re not meant to be taken literally.

For example, the phrase “kicked the bucket” does not literally mean a foot had come into contact with a bucket. Similarly, to say that I have 13 bosses does not literally mean that I have 13 people above me in the hierarchy. It is a colloquialism used to describe a feeling and intention, rather than a literal description.

Perhaps it would be patronizing to say that without explaining what I meant, but I do explain that, in the same comment. Lastly, in many ways, they do control their own fate - that is, they can choose to leave if they’re unhappy, and be happier elsewhere. In that way, because they are in no way conscripted (at least in the State of California), you could make the argument that they control my actions. That may be a specious argument. I’m not certain. But one perhaps worth exploring.


Another way to put it is building a culture that helps everyone perform better. There are conscious levers that conscious managers can pull to make sure his happen. Have you ever worked in an environment where managers created conflicting goals or perverse incentives? Did that help teamwork, or create frustration? Do frustrated teams perform at their best? How many people have you managed?


Everywhere I've worked from McDonald's to tech companies, managers were trying to help everyone perform better (i.e., make more money for the business per hour).


Ah, you're conflating things here. Bad managers often think making more money for the business per hour is a 'get more work out of the employees per minute' strategy. That doesn't work, due to the off-pay benefits a happy employee provides that a bullied or unhappy one doesn't. Staying a few minutes late to finish up a job, coming on time, not fudging their hours a few minutes here and there, recruiting on your behalf by telling their smart friends about how much they love their job, being willing to come up with new ideas to improve the business, etc.

Many bad managers think short term, and are looking to squeeze every ounce of work out of their employees, which leads to burnout, disillusionment, and resentment. My point is it's far more important to make them happy and have them convinced they want to do their best work, not because they fear losing their job, but because they feel inspired, capable, trusted, well-compensated / rewarded, and like they have autonomy.

If McDonald's had that, their turnover would be a hell of a lot lower, guaranteed.

[edit] Here's an example of what I mean by the unpaid extras I refer to: https://economictimes.indiatimes.com/jobs/bullying-bosses-ne...


> If you are evaluating someone's work and you can fire them, then you are their boss.

At least given the current job market, if an engineer isn't evaluating and at least prepared to "fire" her employer, she's probably misunderstanding the employment dynamics.

If the compensation, freedom to work, and growth expected aren't there, ask for them. If you don't get good answers and actions to back them up, say, "Thanks! I'll see you around."


Maybe this should really be split up? Managers should be relegated to their stated role - being servants and shit umbrellas, not bosses. And since there is a need for a boss over a team, why not create a second job type, Commissar, whose job is to evaluate performance of the underlings and fire underperformers?


I recently heard the perspective that a good leader is always thinking about how to bring value to their team, and reviewing how much value they contributed to their team the previous day, and trying to come up with new ways to bring value to their team, and so on. This is paraphrased from my notes that someone else paraphrased for me, but it really struck a cord for me.


This is very wise advice, and I can especially appreciate the layer of empathy: empower engineers to add to their toolchain (mgmt or technical).

To complement this thinking, however, I also expect a leader to align engineers to business priorities. There is a fine line to walk in balancing the growth of engineers with the needs of a business. I expect engineers with certain years of experience to understand that as professionals we are hired to address these needs.

Of course there is also the flip side of this alignment: aligning the business to the real (vs. imagined) capabilities or investment needed.


I love this take.


An engineer focuses on the what, where, and how...a leader focuses on the who and why. For example you are considering adding a feature to your app. As an engineer you think of what you need to build how to implement it, where to store the data or put the logic. A manager focuses on why you should or shouldn't build it, who on the team does what part, how much it costs, etc. Imagine the transition from line cook to executive chef...when you're in charge you have to think big picture about menus and marketing and let your team handle the tasks of chopping of vegetables and plating entrees.


One of my favorite ways to sum this up is thinking tactically (who and why) vs operationally (what and how).

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.


That's a great way to visualize it. One of the hardest parts about my transition from engineer to director of engineering was planning ahead for headcount without knowing what upper management had in mind 12 months down the line (they didn't know either).


It was a hard part for me as well. How did you approach it? Maybe, you could also share some useful links if you keep them?


I think you’re mixing up tactical and operational though. In the standard military vocabulary at least, the operational level of decisionmaking (what) is between strategic (why; the most abstract) and tactical (how; the most concrete).


nicely explained, thanks!


I was an engineering manager until recently, didn't get much enjoyment out of my role since I had to focus more on whats and whys instead of hows which is what excites my engineering mind. Now I have changed job to an engineering role and having lots of fun building stuff and learning new things. However at times I wonder whether I made the right call, whether my career will stagnate if I am not interested in moving up the org ladder. Make no mistake, I absolutely loved the responsibility and freedom that came with a managerial role, it was just my engineering appetite that was left unsatiated. Is there anyway to keep oneself occupied with technical stuff in a managerial role? Doing your teams work is not the right thing neither for the team nor for the company.


[disclaimer: I haven’t been a people manager for too long, so take it with a grain of salt]

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.


I help write unit tests for code my team is working on. It's fairly non-blocking (we won't slip a delivery date if I get pulled into something else for a few days) but still requires me to understand the code base and ask questions of the engineers.


> Is there anyway to keep oneself occupied with technical stuff in a managerial role?

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


One thing I have seen some managers do at my company is use their coding skills to help streamline their work, i.e. create scripts to help pull data so they can create charts or query for data to form some analytics to help inform decision making on the right path forward.

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.


+1. Due to the small size of our company, my role still is somewhere between lead engineer and a pure managing position, but it‘s enough of the management schedule that I can no longer be a reliable partner for working on the core product. So I try to automate/optimize internal workflows with my coding skills, i.e., I build tools that improve things if they exist but do not break or block things if they‘re delayed due to too many meetings creeping in.


It's funny but sometimes I feel like I spend as much time doing reporting as someone as when I was entry level. The difference is sometimes my team isn't able to run these reports or I'd rather they focus on other things.


A way to keep yourself occupied? No. You’ll just be interrupted every 5 minutes.

But you can certainly do something small in between.


Do another online MS CS degree from a top school like Georgia Tech, UIUC, UAustin etc. and study everything you ever wanted to know. That should keep the technological fire inside you. As a bonus, you can do iMBA at UIUC in parallel and have both engineering and management covered.


Even as an engineer I often focus on the ‘why?’, since answering that first prevents me from having to do anything else.


Totally agree -- I too had to learn this the hard way. Also, I wrote this during the difficult period when I myself was transitioning from tech to lead a few years ago. Hope it helps: https://www.linkedin.com/pulse/failure-delegate-pitfall-tran...


Just building on the who and why idea ... as a technical manager an important aspect of your job is use your technical aptitude to help your non technical peers clarify business ideas related to, possibly, technical problems. Once problems are clarified, it should be clear whether they are technical or not. At that point you then need to advise at the proper level of abstraction on cost, timelines, possible solution benefits and shortcomings.

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.


I do both and it's probably less effective (comparatively)


Here's my strategy whenever I have 1:1's or hallway "walking conversations" with execs/GMs that are at least 2 levels above me:

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.


All good thoughts on managing up for sure, which is definitely a component of becoming a good leader. How you’re able to influence those “above” you can drastically impact your team and their effectiveness. This is one of those traits that sometimes your team doesn’t know you have, but gives them direct and tangible benefit almost “magically”.


> 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.

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?


"I watched this YouTube video on X, it was interesting because..."

"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 _______"


Leadership and management are fundamentally different things. Leadership is about making sure the ship is sailing towards the right spot — management is making sure people keep rowing effectively. You can have the best team of rowers, but if no one is focused on where the ship is actually headed, you’re not gonna get where you need to be.

Therefore, speaking like a leader means being more focused on principles, goals, mission. Delegate the “how” and focus on the “why”. Paint the broader picture for the team so that they’re motivated to figure out how to accomplish it.

At the highest level, leaders make decisions no one else is able to make. Focus meetings by throwing questions back to the team to make sure they really can’t solve the problem themselves, and then resolve to make decisions on everything else so that they aren’t blocked.


Management jobs have two aspects: people management (which you talk about) and team management. The latter definitely falls into "where to row" in your analogy. You can call that aspect of being a manager "leadership" but in practice it's not a separate job. A manager that ignores that part of it is failing.


This is such a great point! Experiencing this balancing act right now.


I run a free mentoring program as a form of community service, specifically for managers and leaders. Happy to talk live if you prefer: https://freemanagermentors.com

I’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!


Appreciated this — thank you!


Absolutely!

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.


Hey Wes! Upvoted your prev comment before I realized it was you. Hope all's well; doing great here. A couple years ago when I worked for you, on your recommendation, I listened to unabridged audiobooks of both "Winning" and "The Hard Thing About Hard Things". Got more out of the latter than the former, but both were worthwhile. Slainte, CW


Study persuasion and communication.

* 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...


toastmasters - especially the improv "table topics" activities - has been indescribably valuable for me.

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.


+1 on the table topics.

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.


Haha yeah I felt the same weird cult-like vibe.

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)


But also don't overdo it. People can tell when you're just parroting the countless business/persuasion books.


Whenever I use a technique I've learned about in a book, I try to make it a point that I'm doing that, and I frequently mention the book the technique comes from. Just because it's in a book doesn't disqualify it as an effective method. At the same time, being transparent about your methods is important, since the methods themselves should be subject to scrutiny and understanding.


This. It's so obvious when people start using tips from these kinds of books. If you read them, you also start to notice people _everywhere_ using it.


That's easy champ, let me help.

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.


This is just bad advice. Don't listen to this guy.


Honestly, it's not even wrong.


Jokes aside, some of this is just normal communication used in business and that's not a bad thing. The consistency is actually useful when communicating between businesses. Makes it easier to integrate and speak the same language so everyone stays on the same page.


Yes, I can tell you and I have synergy. B2B consistency is not just useful, it is impactful.

Despite the win-win dialog we're having, maybe we should take it offline.


That was funny. I get your /s


Except that many of these terms exist not to make communication clearer, but to obfuscate, to hedge.

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?"


Because there's more information being communicated in "downsizing" or "re-restructuring."

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.


> 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.


That was awesome. Dilbert but in prose. Do consider creating a twitter channel with this persona, in case you dont have one already.


I would assume you're giving too many details. People higher up the chain don't have time for details: that's why they hire you, so you can make decisions at that level.

You need to communicate:

  - status of the project
  - external blockers
  - progress on OKRs or KPIs
  - important personnel issues (e.g. people leaving, big HR issues, things that eventually will affect your deliverables)
The key is not to overwhelm with noise and learn to communicate what they want to know.


Something I was taught during manager training in an unrelated field was the mantra “clear and concise”.

Details are important but there is a time and place. Most of the time people asking questions will ask for more info if they want it.


Think about your Audience. That's all there is to it.

Your team's job is execution, Executives job is prioritisation. Your job as a first level manager is to make sure your teams work is prioritised correctly and that your people visible and valued.

When you're talking to your manager, think about what details he would be interested in and give him ONLY what he wants. In some cases it is about omitting details, and in other cases it's about processing the details into more digestible metrics.

As an example, if your team is spending time on a recurring issue and you want to get executive blessing for a project to develop an automation tool, you would open the dialog by hard-selling the problem. You are loosing a huge amount of productive time, atleast 'x' man-days every week. Your engineers are frustrated by this. Every team in your company is impacted by this, not just yours... and guess what, MY TEAM can solve this.


Engineer doesn't mean "NOT a leader".

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.


Your manager is being vague. Either purposefully or not.

If purposeful I would be concerned and ask why.

If not, he is not very good at communicating. So. The next time he says that ask him:

“what do you mean by talk like a leader not an engineer, because every engineer and leader I know talks with their own distinct style”


I'm not a manager, but I've been in some leadership positions in the past, and I can say my efficacy came from my ability to persuade others to do the things I wanted to accomplish, and trust/delegate to others much of the execution. I say this both having executed okay at some things at some times and having completely failed at executing the rest of the time. These constants were there when I was successful and not there when I failed.

I found it hard because I approached the problem with an engineering mindset - there is a right way to do things, a solution is fixed or deterministic, and interfaces are efficient. While they may be true in code they are not with respect to people. Often times the right way to do things depends on your perspective, or there is no right way to do things, only less wrong ways. The problem space, like figuring out what customers want/need/alignment between both, is fluid and fast-paced. Interfaces between people are horribly inefficient and communications latency and breakdowns destroy shared understanding and undermine organizational trust/integrity, which in the end calcifies organizations and teams.

In this environment, be humble. Recognize that physical intelligence does not matter beyond some basic level, and emotional intelligence will save the day. Always blame systems and processes over people. Be very, very, careful with your words, body language, and actions; understand/appreciate that you start off with less than complete trust because you hold financial/social power over people now, and if you don't want to constantly hold court, you need to actively/consistently build that trust and alignment with your team.


I don’t know how to you advise you in a precise and concise manner, and I’m still learning and hope to do more. Let me try.

I’ve worked at massive service companies, including Razorfish, where I excelled at allocating the right people at the right time, with optimization for the best profit to the company. I’ve also worked on many products (for my own Startups and for other Founders), and I’ve begun to realize the best way to be a leader is to assume that 'everyone else is as good as you were, perhaps even much better than you.'

I used to research ahead, prototype, and articulate solutions and ask the team to make it better, execute it. Now, I just poke the tip of the problem and let the team get involved early on, handle the problems and the solutions. I try to acknowledge their accomplishments, let everyone know the awesome things they did, the sacrifices they made and help them connect to one another. Give enough warnings to non-performers and try to help them in private. Of course, if even after a few tries, they are let go.

Earlier, I used to say that I’m good with designs, development, and business too. These days, I believe I’m just a designer - I design opportunities, careers, teams, products, and organizations.

That is my current method of leadership - talk less, let others be doers, make others the hero of their stories. “Do now what you wish (or have) to be doing 1 year from now.”

You might have seen and heard many inspiring videos. Here is one I recently saw and it strikes deep, Patty McCord’s 8 lessons on building a company people enjoy working for https://youtu.be/iBa9EoEbb38?t=18


I don't want to be a jerk, but if your manager was a better leader, he would explain what he means in a way so you wouldn't have to ask the internet about it...


There is nothing wrong about being an engineer. In fact, most of the best leaders I know are engineers, because having both operative skills and decisions skills is incredible powerful.

You don't need to negate your engineering skills, just acquire leadership skills over them. You will need:

-Skills about people, phycology types, influence, procrastination, deals and negotiation skills.

-Knowledge about the "Forrest" perspective of your business, in engineering you will have deep knowledge about the trees. It doesn't matter if you do a perfect job if you do the wrong job. If you do you will fail, and your best people will leave soon.

-You need caring about your people(the people on your team). Isolate the blame on yourself(and your system, change your system when things go wrong) for all errors of your people. Give credit to them when things go well.

People know when you care about them, they sense it. This overpowers anything you say.

In today's business it is all words about how the most important things in the business is its people, and they they trow their people under the bus. You can even joke and say all day you don't care about your team that if they know you care it doesn't matter.

This is very easy to state and say, but it requires years of practice and lots of mistakes before you are good at this. Focus on improving one skill at a time and log improvements on a notebook or something.


"Talk like a leader" could be code for:

- more (realistic) optimism

- accountability / ownership

- more listening, asking questions, versus making statements

- stating things in business terms versus technical ones. For example, if there's a technical problem, speak to options, costs and timelines instead of the detailed reasons why something isn't working.

- paying attention to business goals. For example, if there's a focus on lowering expense (as opposed to capital), show the finance team that they may be able to capitalize reserved instances in AWS.

- weigh business goals versus technical goals. Does rewriting that tech debt benefit the company now, or is there a temporary situation where deferring it for 6 months is better? (say, using that time for a long wanted feature instead)


As a fellow engineer facing the same problem, I don't believe it's so much in the language, but more the outlook and how you perceive things. As an engineer, we tend to get into a lot of nitty gritty, with a lot of "it might be possible if we first do X, Y and Z, but that assumes A and B don't take place, in which case we need to do..." I guess the "correct" answer here would be "Yes it should be possible, but give me a couple of days to confirm" - Most people don't care about the details. In their minds that's why they hired you.

But again, the language is only a fraction of it. It's how you handle situations. When you change your approach to problems then your language changes as well. I'd highly recommend reading some books. The two I've read in the past month and really liked where "Extreme Ownership" by Jocko Willink & Leif Babin and "The Five Dysfunctions of a Team" and Patrick Lencioni Both books give examples of how they handled situations, and you begin seeing patterns in the speech they use.


I'll second 'extreme ownership'

It is particularly pertinent to working across groups, organizations or even separate businesses.


Management is a trade, just like engineering, so you pick it up like you picked up engineering, with education and practice.

I’ve spend two years learning leadership skills and I’m still often stuck on the technical details. Because technical details matter to me, but they don’t really matter in management. What matters is how well you execute, and you execute well by picking the right staff, keeping them motivated and on target.

If the engine on a freighter breaks or needs a larger upgrade, then the captain doesn’t really care why. He wants to know his options, how they’ll benefit the ship, what they cost and what risk they come with. The same thing goes for personnel problems, executives don’t care about what went wrong or why, they care about how you plan to fix it.

If you’re looking for mentoring, it’s almost always better to do that with a management colleague that isn’t your boss. Because your boss has the exact same leader/employee responsibilities that you do.


surround yourself with non engineers and the language will come automatically. Also read non engineering content. The Economist or CIO or other magazines and books that use a non technical language and describe technical concepts without jargon.

What you're asking here can be massive career changer and lift you up from a skill perspective. Many business types have not much idea how your world works but if you can bridge over into theirs it will certainly open doors.

After a while you might see a huge contrast when comparing to HN, reddit and technical mailing-lists or any chat & digital channels. While "growing up on Usenet" can give you an edge with reasoning / arguing in the technical world, it can massively backfire in business.

Everyone in the business world I know makes their connections IRL (and not online). So having hobbies that get you off your screen and into real human groups would be a boon.


As a manager who transitioned from technical to commercial, the biggest shift is speaking concisely and having an opinion on which direction to go and why. Leave the details out and think big picture about how the issue affects the entire organisation and what decisions/actions your manager needs to take. Present solution options, articulate the benefits and costs, offer your opinion and have a discussion.


Leadership is sales, the team are your customers, and your product is ‘Why I should care’. Learn to sell, which means aligning with diverse motivations.


brilliant analogy


I would start by reading and listening to Radical Candor's books and podcasts: https://www.radicalcandor.com

"We believe that the relationships you have with your team are at the center of being a great boss. At the heart of these relationships is Radical Candor, the ability to Care Personally at the same time that you Challenge Directly when you fulfill your core responsibilities as a leader..."

They helped me a lot to connect with the people in my team, to create an environment of positive communication, but most importantly it helped me shift the way I communicate with other people in the company.


Has your manager offered any specific feedback? Ask him what he perceives as talking like a leader.

Are those your are leading having issues with your communication style?


He didn’t offer any feedback. I went to him with a problem of my reportee’s salary concern. Where in, I cannot take a call and do false promise. But, he says that I need to come with a solution. And says he can’t spoon feed me on how to solve the issue.


A direct report has a salary concern. You promised something to the direct report. You take this to your manager, and he tells you to “speak like a leader, not an engineer”. Did I get all that right?

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?


This is certainly only one small aspect, but: Don't upspeak. [1]

It's one example for non-verbal behavior that impacts the perception of your stance and status.

[1] https://en.wikipedia.org/wiki/High_rising_terminal


Engineer: we can get to the town by bus, by car or by train. Each mode of transportation has it's pluses and minuses. Specifically, bus is cheaper....

Leader: guys, we need to get to the town and we're taking the train, unless right now I hear an extremely convincing reason not to.


Or when reporting status up the chain, simply: “we’re on schedule to arrive in town, estimated time is between 4 and 6pm.”

Side note, one key to estimating is to start with a realistic and wide window which you regularly update and gradually narrow as you get closer to done. Being able to give forecasts that other people can count on is a big deal.


1. Keep your discussions high level.

2. A leader’s job is to make sure the ship reaches its destination. A real leader assumes responsibility for taking the entire team where it needs to go.

3. Don’t be petty. Leadership is tough. You’re going to have to tolerate a lot more and give a lot more than the others. Make sure your communications reflect that.

4. Dive into details only as needed, and better in a one on one where you’re only speaking the parties its relevant to. Everyone doesn’t need to hear everything.

5. Other leaders in your same rank don’t have as much visibility into your day to day as you do. All details won’t be relevant to them. Keep it high level. Develop the skill of having a normal conversation, keep a few appropriate jokes in your back pocket, and use a story or two to illustrate your point instead of numbers and statistics. People remember how you make them feel.

6. Be observant, develop your skills on reading and displaying appropriate body language, communication is more than just the words that come out of our mouths.

7. Know yourself, your pitfalls and strengths. Are you glass half full or half empty. How does that impact your communication and your team. Find complentary people and try to take insight from them.

8. Make an effort to find a mentor if you haven’t already, these are excellent conversations to have with them.

9. PhD interview. Explain your research to a layman (doesn’t have to be research and you don’t have to be a PhD)

10. Celebrate wins, learn from losses, build some positive momentum around your team and project.

All the best!


> don’t talk like an engineer, talk like a leader

one thing that's important to remember in general is to stay on topic. an executive won't care to a certain extent about the technology choices or the day to day work. figure out his goals within the company and only bring to attention topics that can actually impact those, those might be technical of course but most likely than not they will be about people and resources scheduling, deadlines met and missed or possibilities for raising the team efficiency and other cost savings that might impact the bottom line.

if you bring up a major technical point it must be something that actually impact the company strategy, otherwise if it's within your responsibility to call the shots, then call the shots. for example we are going to change our multi-tenant strategy, now that I had to bring up for consideration because it impacts the running cost per client, each client cost per scalability unit and has wide effects on how we package, deliver and deploy each client customization projects that's on top of our products offering; still you talk about how all of this would enable independence between each other delivery team and what you lose in term of increased costs for parallel development, not about the technicalities of the task per se, that's what you talk with your team, albeit if you want an happy team you let them figure out from a very accurately described problem statement, because that what engineers like to do.

you don't need to drop the engineering lens. you just need to stay on topic and focus on talking about what's important to your other conversation party, and that doesn't just apply to management and it's not "talk like a leader" per se.


I'd ask him "can you give me advice on how to do that?" There is probably some piece of context in his head that he's referring to (and he didn't realize that the piece of context doesn't exist in your head).


He doesn’t sound like much of a mentor. Unstructured criticism just reduces morale amongst rank and file when the message is constantly berating.


Not sure how relevant this is to the question but a leader to me is someone who has your back. Someone who is not afraid to throw himself for you. Someone who helps you grow beyond your abilities. Someone who lowers himself and elevate others.

I wouldn’t consider anyone without these qualities as a leader, no matter their pedigrees.


Didn't face the issue, but focus on solutions, not on giving him the details on your issues and asking for help. I.e. tell him confidently what you are going to do and how it'll help the company. And give him some positive news also, not just worries...


Yes, he likes to listen to solutions rather than teams problems/worries. Good advice.


Engineers set and impose product/service definitions. Leaders impose people definitions. Set goals, policies, and directives for you people. Make the goals realistic, but don't let your people convinced you to lower the bar. Use your engineering experience to destroy their weak excuses.

When your people meet challenging expectations reward them. When they fail find out why. If there is an opportunity to improve a failing member of your team then fix them. Otherwise get rid of them. usually everybody that is qualified to be there can be improved to meet reasonable expectations. The people who can't are usually not qualified for the position or don't want to achieve your baseline.


Think about who your audience is before talking to them, talk in language that they can understand. I know a great engineer friend of mine who when he talks to analysts or business people delves into "stored procs, threading model", this is not what you want to convey to people who don't know what those things are, focus on high level overview, think about what would be important for them to know from their perspective. To do this ideally, you must as a manager understand business need, and what is valuable to them, then based on that you can communicate with whoever in the context of whatever they can understand and want to know about.


There are three roles in play here: * individual contributor (engineer). someone has skills to do something. works out how to achieve something. * manager. someone who ensures teams are happy, succeed and progress. manages resources (money and time), allocating to deliver results. * leader. someone who others can follow, paints a vision of where we want to get to, and why.

most people ask others to be leaders, when they mean managers.

you can be a IC and a Leader at the same time, or a manager and a Leader at the same time, but IC and Manager is often disaster (too busy focus on solving an issue to look up and see other issues).


Two books well worth reading in this context are;

- Getting More by Stuart Diamond - https://www.amazon.com/Getting-More-Negotiate-Succeed-Work/d... . On the cover it’s about negotiation but most of what a leader does involves negotiation. Rather than try to convince you, I’ll just say Google engages Stuart Diamond to trail engineers in negotiation. There’s a talk by him here at Google that might convince - https://youtu.be/2QtZ-vObJrk

- The other is “Corps Business” - https://www.amazon.com/Corps-Business-Management-Principles-... - about how the US Marines do management. The big thing you can get some this book is expressing projects and tasks in terms of the _end goal_ instead of the steps required to get there. Make sure teams collectively understand the end goal and let them figure out how to get there is the basic message. That implies you need to put your effort in being good at story telling and presentation


he is telling you:

Operational level - to keep the technical jargon out, dont give technical details but give business strategy related details. if you need then go in tactical ways you can solve the problem. - your information should be bulleted list of 4-5 words per line in business terms. - you should talk in terms of program level, org level strategy, program level budget/matrix work, dependencies etc. - your metrics conversation should be in terms of business terms such as basis point impact to the program. - you should not talk architecture or logic level design but in terms of connecting orgs, blockers due to various programs. - view and think in terms of non-biased decisions to be made objectively. - talk in terms of process not code - i do not want my team members to have crap excuse about defects occur b/c this and that issues but i want to know metric based impact and recommendations and alternatives. - present 2-3 options (unbiased) to help make right decisions.

People Level talk in terms of - strengths and opportunities. - building bench strength. - talk in terms of pipeline - team building activities, team collaboration, compensation packages, org chart and skill needed. -

lastly, do not go to your boss with your daily problems, he is your last resort.


Don’t begin sentences with I think - state your opinions as facts.

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!


> Gather information from your subordinates and then report it to your superiors without giving your subordinates any credit.

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.


Here is one pointer. Your Question is: "How do I develop or change the way I talk as a leader?"

* Lead with your point first. The above question should've been first in your HN post. Try it yourself. Cut the above line, put it first, and then the rest of the text, and reread your HN entry.

* When you start writing with your point first, you start practicing how you should write/talk to higher ups.

* Once you get better at writing point first, you then should start speaking point first.

* When you speak point first, you will grab attention. Once the attention is there, only then can you go into detail, should you be asked to go further into detail.

Examples for your question:

People Issues:

(GOOD): We may have to replace so and so. ... then proceed why so and so is not performing as a conversation.

Do not start with: (BAD) So and so is getting on my nerves. I asked him to write the code for widget and he keeps not reading the APIs and going off the tracks blah blah blah.

The same applies for operational matters. Start with the point, and if details are asked of you, then keep going. It's a conversation, not a one sided rant.

I won't add to the numerous books and links that people have added of "great" leaders and how to be a great leader because there a lot of good ones in this thread.


While suggestions around self improvement are very important, please also evaluate the competence of your manager and then adapt. Self improvement is essential but not sufficient.

More than once I have encountered clueless executives who are happy only when you are a mirror. They are not interested in solving any issues from below unless something personal for them is at stake.


> 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.

What does your manager say that means? This strikes me as the 'critical thinking skills' of management -- nobody knows what the phrase really means, and if they did they wouldn't want it. It is every manager's job is to provide clarity to their directs, even executives.

At a first brush, your job is to speak like both a leader and an engineer. You lead engineers, after all. That means connecting the engineering, the "how", with the business results, the "why." One of your team's goals might be to reduce AWS costs, by tweaking Java GC parameters.

Going deeper, you might consider personality traits. The DISC model of personality divides humanity into four categories: Dominance, Influence, Steadiness, and Conscientious. To keep it brief, we generally perceive high D personalities as 'leaders' and high C personalities as 'engineers.' Talking like a leader in this context means demanding results, and making decisions under uncertainty, while an engineer is more likely to ask for more time or more data, obsess over quality beyond what the customer needs or expects, and avoid talking to people. High D communications tend to be brief, while high C communications may be overly detailed.

More pessimistically, perhaps your exec simply means to stop talking about technology they don't understand, and have no interest in understanding. If this is the case, you should consider whether an executive responsible for a technical team is sustainable. Certainly some amount of simplifying explanations can be expected of middle management, but this is a two way street and some efforts should be made to understand the tools used to solve your business problems.


Things i learn't the hard way on transition from a Founder to Product Manager being a non technical guy:

Firstly understand the transition means a lot of unlearning, sometimes with parts that you hold dear to you. My advice to you is to be honest with yourself, your team and stakeholders about the same. Makes it easier on all of the folks and eases the transition.

3 Circles of X: As you start going up the ladder, your focus is on a birds eye view of three circles: Your Customers/Markets, Your Products and Your Team. You are here since you get the bigger picture and you need to help your team do all of their core functions with as little hassle as possible. I came to terms with myself when i started thinking of myself as a lubricant, and it all made sense.

Tons of people go through this, find people that have recently gone through the transition and talk your problems out. Also probably give Managing Humans by Michael Lopp a read.

Hope this helps!


I would assume this is more about talking like a manager. Engineers are leaders too. Technical leaders.

Talking like a manager primarily means to focus on time and money. How much does it cost/save/earn? How long will it take? Just two numbers. At least managers would like it to be that simple. It isn't and that makes the translation between management and engineering hard.

You still must try to answer the questions though. Pick a random open bug or feature: How long will it take? How much value does it bring to the company? If you can answer both questions precisely in a sentence you should be fine. You probably cannot. Now try harder. What has to change so you can? Just get some info from someone? Change fundamental processes in your company?

Now you have work to do. Before you start doing that, ask again: What is the value in dollars? How long will it take?

Oh, and put a limit on the recursion there.


I went through hearing the similar ("talking like an engineer") comment myself. One thing made a big difference in transitioning to company leadership.

I thought I was a leader of the people reporting to me. A leader in a generic sense, as in civic leaders. I have to fight for or work towards their betterment.

With that thinking, every discussion with upper management would come across as the defence, for the team, for the processes.

One executed corrected my understanding that I am not a generic leader. I am a company leader. That means the company is first and foremost. My communication and thought process has to reflect that.

It sounded a bit harsh in the beginning but it helped me become a better company leader and good for the people reporting to me and customers in the long run.


An aspect of it that I've been taught is, rather than explaining why something can't or shouldn't be done, explain what it will take to get something done. E.g. don't say "we can't do X because it's too expensive, requires too many people, is too risky, ..." Instead say "doing X would require raising additional funding or diverting funding, we'd need to pull people from other teams and/or hire additional headcount, will require some risk reduction investigation for two weeks before we can give a complete assessment, etc." Then let your CEO, board, whatever decide or help decide if the costs are too high.


Actually rhetoric is one of the things Aristotle still has valuable things to say.

Basically all the rhetoric books I've read (not that many, not an expert) are just expanding and giving examples to Aristotles "Rhetoric".

The modern english translations are quite readable and the concepts are straightforward. They circle around the concepts of ethos, pathos and logos. I.e. you must convince the audience you are worth listening to, then you must appeal to both of their feelings and logic.

This means various things, including toning your message depending on the audience. And, even engineers are affected by emotions, you just need to find the right context :)


Think about commercial goals, not just technical goals. What will make us successful as a business? What do our clients need?

Have answers rather than questions. Many posters pointed out that it is good to provide options as potential solutions. But this may not be leadership. Engineers love options because we are creative and options are opportunities to experiment. The problem is that we need to be bold when a decision must be made. A decision is explicitly closing off our chance to explore all but one of the options. This is tough leadership.

(We need to know when it is time to make a decision and when it is a time to explore options)


In University, I would see this message written on one of the college's best Electrical Engineer professors' office door:

"Efficiency with machines, effectiveness with humans"

It's a powerful idea, and I think the point is obvious.


What your manager is implying but won't say is, "talk like me". So do that. Think of how he rephrases your reports, how he puts things - and talk like him. That's what he wants to hear.


Learn to use words like synergy, leverage, no-brainer, disrupt, and incentivize. Use phrases like deep dive, core competencies, outside the box, and move the needle. Presto, you're talking like a leader.


Tongue-in-cheek, but i'll rephrase it a bit to be maybe slightly useful. Look at the words above, and notice what they're not. So, imagine you're not allowed to talk using words that talk about the implementation, but only from a high level using words like those above. Given these constraints, how do you provide more value to your team and to the company than someone who implements?


Your impact depends on the authenticity and emotions you put behind it. Faking any particular style is bound to get you into trouble in the long run. That does not mean specific techniques are not worth trying out and seeing whether they fit you.

As a leader you are making decisions and stand behind them - not all of them are purely based on the subject matter but take the wider context in. As an engineer you are evaluating options. These are distinctive roles and lower level managers have to do both. Be clear with yourself and others when you are doing what.


With platitudes like that, good chance your manager is not really a leader either. It’s popular, especially amongst MBA types, to toss the word “leader” around with no concept of what it actually means.


Joined just to respond as I have some experience in this area.

I went from engineer, to engineering manager, to engineering director and had a similar conversation with my boss who is an Exec VP.

It's not clear whether he's responding to how you talk to your team or how you talk to him, or both.

If the latter there a few things to consider. You need to come to your boss with several possible solutions to your problems when you bring your problems to him. Let him advise you and give you ideas you haven't thought of, but he's not going to want to just solve all your problems. He has plenty problems of his own. He hired you to make decisions at a lower level.

You should bounce your instincts off of him and let him course correct you. Tell him how you're approaching solving the underlying causes of problems, not just addressing symptoms.

Be careful what your bring to him and how you talk about your problems. When you say 'fire' to an exec, they think you mean a forest fire, not a camp fire and they'll act with a heavy hand and get upset with you if they end up over reacting. The exec's wagons include artillery and nukes, not small arms. My mentor used to say 'Executive exposure can be good... But you can die from exposure'.

Talk about engineering risk, milestones, long term plans, etc. He wants to know you've considered the risks and have mitigation strategies. He wants to know that you know what things will cost. He wants to know what your effort estimates are. He wants to know that you've done due diligence in procurements and hiring to prove you need what you say you need.

He doesn't want to know who is doing what or what isn't working well, unless you need him to solve the problem with a nuke. If something isn't working, come up with new ideas.

If he's referring to how you address your team, you need to not help people solve their immediate problem by only talking with them about how to address the problem at hand.

You need to talk to them about expectations, habits, and behaviors. You need to have accountability conversations.

I had a training course from the folks that wrote 'Crucial Accountability' in how to have these conversations. It is incredibly effective. I highly recommend this approach.

You need to assess operational execution and develop procedures to improve it rather than just fighting fires. You need to help them be better, correct, rebuild, stay out of trouble in the future.

For operational leadership the book 'The Phoenix Project' really helped me develop a strategy.

A great book for personnel leadership that I used is 'First break all the rules'. It will help you cultivate talent in employees.

Develop a leadership philosophy of your own that you believe in and use it in your conversations with your teams. A great resource is the book 'One Piece of Paper'.

I hope these help.


In my experience with engineers (I'm not an engineer.) they think that technical details are the whole thing, and are the totality of what they need to communicate. But nonengineers need more, contextual information to understand a project, like the intellectual history of the technology, a story about the development process, maybe some examples of it in use, an image or video is useful. To my mind a leader would talk the whole enchilada.


Give your perspective as it fits into and supports the larger business context of the company. This perspective (in moderation) would likely benefit your team as well.

I've also found that many non-technical executives have some level of fear of technology, so remembering to explain things in ways that they can understand (and helping them gain some degree of technical understanding in the process) can also be effective.


Replace half of the meaningful sentences that you were about to say with some random bullshit (with the appropriate buzzwords), and you are good to go.


As a leader, you should talk differently with your team and with execs. With your team: understand what they are saying quickly, ask good questions, make them think, teach them how to think and work with your principles and wisdom. With execs: understand what they want, "own" and ask what you need (logically) and "get things done". The buck should stop with you.


In my experience engineers think that technical details are the whole story. But nonengineers (I am not an engineer.) need more contextual information, like some intellectual history of the idea, examples of the technology in use, stories about the development process, maybe an image or video. To me a leader is someone who can talk the whole enchilada.


A lot has already been said in the thread about identifying, aligning with and assisting in achieving your organisations goals. I'd also add part of "speaking like a leader" is speaking in a persuasive manner, convincing other in helping with the above.

I found "Thank You For Arguing" by Jay Heinrichs a really good introduction to this.


Solutions, not problems. Schedule times for your reports up the chain and before you discuss, remove yourself from the details and reflect. Write a summary for yourself with key take aways. Try to avoid real time discussions about "how's it going" with someone who is asking for summary, not detail. Get back by end of day.


My only advice based on the information you have provided is you shouldn't go to your manager with "people or operational issues", you should go to him only when you need him to unblock something so you can apply your solutions to "people or operational issues". In other words, don't bring him your problems.


Talk about strategy, and when anyone asks for detail say "well, that's a bit operational but I'll get someone to put together a report for you", then wait for a day, then tell them what you would have told them anyway. But with the addition of SPC charts and references to a (potentially mythical) Gantt chart.


"How to talk like a leader, not like an engineer"

Leadership requires some psychopathic traits: https://www.elitedaily.com/life/motivation/psychopaths-make-...


Think about your people first and foremost.


Here’s a good summary from ‘Career Warfare’ about how you are being perceived by your manager/boss and what they need. https://www.slideshare.net/happysammy/career-warfare


Vagueish advice for a vaguiesh problem-- When presenting issues, I'll almost always fallback on something like this-- 1. Details of the problem with history of other related issues. 2. 1-2 sentence assessment of the problem that helps summarize everything. 3. 1-2 possible solutions.


How do I describe this in engineer terms...

You need a cohesive interface to your boss. He doesn't need the implementation details of your problem. You should return a clean, terse data model from your TechLeader.ReportStatus() function.

You are a complexity manager in leadership just like you are as a developer. He's your customer like your sister team consuming your API is your customer.

He needs decisions you make, summaries of your problems if you cannot solve them, and multiple solution summaries if you need help picking one.

On the flip side, managers need to understand why, and you need to be capable of explaining why if the problem is not intuitive to them. But you'd be surprised how many problems are intuitive to them when the fundamental moving parts are summarized well. If the boss needs more detail, he will ask.

EDIT: one last thing: focus on actions, not reasons. We did X, then Y, and Y didn't work, so we did Z. Now our timeline is at risk. We need to push back two sprints.

He doesnt need to know reasons Y1,Y2,and Y3 why Y didnt work. If he wants them, he'll ask. Actions, not reasons.


Side question on the leadership bit (not OP): my friend told me about this whole Toastmaster concept recently, does anyone here have experience? I a very wary of these kind of things, so would love to hear from another engineer's point of view.


I'm currently a happy member.

I'm getting a lot of value by voluntarily exposing myself to talking and it has thus far made me more aware of the way I speak, the way my body reacts and that the stage fright is something that never really goes away, even for "experienced" speakers.

To get a feel for the structure, meetings are commonly comprised of three parts:

1) prepared speeches (these are members doing their assignments according to a specific course they're working towards),

2) table topics (impromptu speeches, also available for guests to participate),

3) evaluation and feedback.

Prepared speeches are the most visible thing and a way to progress towards the completion of a course.

Table topics are 1 to 2 minute speeches in reply a given situation, that can be a question, a picture, a situation or anything else. It's a practice for getting better at unexpected speaking opportunities and usually a way for a guest to see how valuable the feedback is and the existence of a real need to improve. They're moderated by topics master.

Big part of the meeting is evaluation and feedback, which is a thing that's rarely given in real life. Toastmasters make for a playground where you can practice giving feedback. There's several evaluation roles in a meeting: speech evaluator, timer, ah-counter, grammarian and general evaluator. I personally see most growth in the evaluation roles, as they can be quite difficult to master.

The event is held together by someone in the role of toastmaster, which opens, moderates and closes the event.

THEN AGAIN, similarly to the number of ice cream tastes, there's also a number of ways the Toastmasters meetings can be held. For someone who dreads public speaking, a critical feedback might kill off the willingness to speak entirely. Culture of acceptance can differ widely between clubs, so my advice would be to visit multiple clubs, if possible, to see which you find most fitting.

If you do decide to join, the Toastmasters membership fee is 90$ yearly + 20$ new members fee, which is usually not that big of a deal for any decent human in tech, but clubs might have higher fees to cover other expenses, eg. renting a room.


My cynical answer is that engineers often work with “yes”/“no” about feasibility.

Leaders usually keep the conversation above that level and think in terms of which problem needs solving rather than yes/no’ing specific implementations.


Absorbing Uncertainity and Emitting Certainity is what leaders do, so I think the ask here is to not quantify the uncertainity not explain dimensions of it but give an output of what can be done given all the uncertainities


I think it's bullshit advice. It sounds like the remnants of a dying mysogynist corporate culture where appearances mattered more than substance.

Working people are smarter now than they were at any point in history. They're just pretending to be stupid in order to fit into existing social power structures. But they can't continue to pretend forever.

The notion of a working class which is smarter and better informed than the ruling class is a new situation which did not exist before and it's going to be interesting to see how it unravels as the intelligence and ambition gap widens.

We are currently in a transition period; a dark age for progress. Smart people are being suppressed and coerced by a powerful class of ruling idiots who are using any means necessary to maintain a highly unstable status quo which is the enemy of progress itself.


I strongly disagree. Leadership is fundamentally emotional-political-strategic, which are not skills that most engineers invest in. You can argue that more engineers should and do have those skills, but when someone says something like take an executive/leader lens rather than an engineering lens, they're trying to imply that you're only thinking about solving a logic puzzle rather than trying to win sales.


It is a capitalist world order that we live in. The masses are not going to rise up and demand worker cooperatives. It is essential to the system of wage slavery that the managers don't know what they are doing. In tech there is this veneer of having some power and ability to negotiate pay due to having the tech skills. Hence nobody in tech thinks of things like collective bargaining, everyone's pay level is secret. People in tech are just skilled craftsmen, the thing about YC is that it is about getting beyond being a hired hand. Get it right and you could be in the capitalist ruling class, hiring managers to keep people in their places so maximal wealth can be extracted from them.

Work all your life to pay off the mortgage to the bank, make your bosses rich and retire quietly is what is expected. Some individual rights are given along the way, you can now have non standard dress codes and ping pong tables at work. But the premise is capitalism. Once people have the mortgage, the car, the two weeks of holiday and some tow word job title they are quite happy. There is no pretending about it, it is a system which is considered normal and the only way.


I'd recommend a year of Toastmasters. Both the communication and leadership track will be immensely helpful. Additionally, it will provide direct evaluation from a more diverse audience that you likely have at work.


I notice that big tech companies are run by people who are technical. This allows you to talk to them far more efficiently. If I recall, the most common professional background of CEOs in the fortune 500 is Engineering


There's not enough info here about whether your actual language is the issue, or if it's your ability to think or communicate more broadly. I'll try to touch on both.

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 pushing for made no goddamn sense if it had been my money, or would not have impacted the higher level business outcomes in ways that justified some kind of cost (not necessarily monetary cost). This leads to the next point:

Quality tolerance:

Engineering culture frequently rewards obsessive concern with the quality of what you're making. The cost of this pursuit often has diminishing returns very early on, and it can be painful to adjust your mind to view "we only ever shipped the bare minimum across 5 domains" from a source of deep shame to a source of resolute pride, or at least grim acceptance. Sure, another 3 headcount would let us take some section of the company from 3/10 to 9/10 in quality, but if the resultant gains can't pay that extra ~million in salary, maybe it's not the right time for that idea, even if you mean well. Lots of things that seem "right" to do are not actually justifiable. (See the section on Ought world and Is World.) Engineering culture says "make the best thing". Sometimes leadership culture says "don't fucking die". This doesn't mean you should ship shit by default, or go in expecting to build bad things, as this can be really toxic for morale. It just means that you should measure the cost – in cash, opportunity, morale, and more – from a broader scope, and optimize for rightness at those higher levels instead of at the lower ones. Sometimes this means making sacrifices.

Metagame:

https://www.epsilontheory.com/too-clever-by-half/

Related to the "shepherd up as well as down" idea, your goal is not to win single games. Your goal is to win the set of all games. If you get the feature you want this sprint but burn up the goodwill of someone you'll have many consequential interactions with in the future, you've lost a metagame. Today is better, at the expense of all tomorrows. Inversely, sometimes losing is winning. Let some stuff slide. Give more than you take. Position yourself so that when something seriously important comes along, you have a cache of influence, credibility, and good will to spend on it.

Ought World and Is World:

Great engineers and great leaders both have their eye on a north star. Ambition is important. But it's a trap to mistake to use your mental playbook for the world that you WANT to exist in the world as it actually is. In the world that ought to be, your peers, customers, market, vendors, etc are rational actors who make sane decisions and have sane values, for your personal definition of "sane". In the is world, there are many combinations of quizzically different values, ignorance, and malice – in that order. One concept to be especially careful of here is "Justice". I'm not saying you should behave unethically. You should be an ethical leader. But a lot of the time I find that when my gut speaks with words like "deserve", "fair", or "unreasonable" – I'm looking at the world through an intermediate lens that's colored by my value structures. I like to try and reverse that lens, and imagine to the best of my ability a world where the argument I'm against is as true, sane, and worthy as I view my own arguments to be (steelmanning – the inverse of a straw man). Very often this reveals a credible alternate perspective where it turns out my answer is just an answer and not The Answer.

---

There are lots of other comments here from people who have been spurned by bullies, sociopaths, or some other management phenomena.

The peter principle: high performers are promoted until they are in a position where they cannot highly perform, so they stay there, sucking.

The dilbert principle: incompetent people are promoted to the position where they can do the least damage.

My take is only one version of the answer to your question. It's intentionally focused on metacognition, metagame, and the assumption of positive intent. For a fairly different take that spends more time on bad actors and incompetence, I highly recommend The Gervais Principle: https://www.ribbonfarm.com/the-gervais-principle/


Why don’t you ask him/the company to pay for some management training for you - he’s identified a weakness and has given you this role, it’s his problem to develop you.


I think the Six Thinking Hats technique by Edward De Bono is a good framework for shifting into different perspectives of thinking and might be relevant to this topic.


As someone who stepped up from an engineer to a leader, I've been struggling with this talking-in-2-roles problem. Thank you very much for bringing this up.


Ask your manager to send you to this: http://coleadership.com


Is he referring to the way that you talk to your team, or the way that you talk to him? If the latter, there's a chance he's insecure about his lack of technical knowledge and reassures himself that his role is to be the "leader" so he doesn't need it. And so when he hears you getting outside his comfort zone he projects that value onto you.

If he means to your team, or it has nothing to do with technical language, then I'm way off!


Keep in mind that being a manager is a different career. You’ll have different objectives and need different skills.


I'd recommend a year of Toastmasters. Both the communication and leadership track will help immensely.


Learn about the rhetorical triangle, especially its ethos and pathos aspects.


Watch Movies and channel your favorite Monologues.


Just pay the advice forward. Tell everyone you're managing "don't [talk|act] like a(n) [job title], [talk|act] like a leader".


Do you mean the CTO position?


I really like some of the feedback on this question, but I think one thing is missing. Ask your manager what he means, and have them give you an example. Preferably an example of something you did that was like an engineer and what should the leader have said.

We don’t know you or how you talk or bring problems forward, so we’re pulling very general examples. Good managers should not speak in ridles, if you don’t understand what they’re asking ask them. This isn’t a problem you have to go and solve, you’re not trying to devine meaning from tea leaves.

——

Some generic thoughts, cause well this is an ask. :)

1. Bringing problems to your manager. Are they of the right level or could you have solved it yourself? As you move up the career ladder/responsibility you have more responsiblity which means you deal with problems that have larger scope. My Jr guys solves (and creates) problems in functions, my Sr guy solves problems in systems, I solve problems that affect product lines accorss departments, and my VP solves problems that can affect the future of the company. But don’t bury problems that can’t solve quickly. The judgement is knowing which is your problem and which is theirs.

Ex: My manager is worried about the next generation systems and how to improve companby operation by adding new widgets faster, cheaper etc. I’m worried about the next few quarter of road map and how to transition from current development to the new system, how to hire for growth. My Sr guys are worried about getting the next firmware release out, planning for the one after, and making sure we hire engineers they want to work with.

—-

2. Options, don’t always bring problems bring options to help fix them and allow them to add their own. I have a project that needs to be done June 30th, if I bring him “it’s impossible” a good manager will go “but what if we hired contractors?”

So what options can you bring forward for the impossible project:

a. Shift the end date (generally something you can’t do, but make sure you understand why it’s June 30th and not July 31st. Did you promise this date earlier before unstanding scope? Doy you understand the ramifications of missing it?)

b. Redcuce scope, work overtimes/long hours/burn out the team, other engineering direct solutions.

c. Can you find new resources, how much would it cost? Are they internal, external? Could you shift someone from another low priority project? What’s your projects priority?

d. What’s the cost of your various options compared to being late/early, etc.

—-

3. Think of the organization not just your project. How does your work fit into the whole and what’s its importance, etc.

4. What people issues are you bringing your manager? Are you making sure to understand people aren’t computers/resources. They have feelings, different drives and desires, etc.

Anyways, ask your manager what they mean!


Ask more questions.

You got like one little answer about this but this is like general life hacking, tied to an axiom from salesfolk you might’ve never heard before, “Tellin’ ain’t sellin’.” You never, in other words, start talking to a new client by telling them all about your company and your products and what they do, you start by asking about their day, about their family if you know their family, about their business level problems.

What is at stake is that in every conversation you are like an anthropologist doing ethnographic study. I don’t mean that as normative but descriptive—I don’t mean “this is the attitude I recommend you adopt” but rather “this is how every conversation is right now, today, whether you like it or not.” There is always something like an ‘immediate local culture’ and you are always trying to discover it and speak in that language. In most corporate contexts you would very happily tell people that the company is posting record profits—but you might get a different reaction at a subset of the company that was informed that the company is changing strategic directions and will therefore be laying them off. An employee who just found out that his wife is pregnant might not mention it to a boss who was expecting too, but then she had a miscarriage. Someone from accounting comes in and says that your data does not match the general ledger under WB-code Y104-B and wants to make sure that nobody is stealing money and now you have to figure out what they consider to be a WB-code and what Y104-B is and what they were expecting and why those do not match up perfectly. In each of these three cases you are an observer of a local context who needs to learn what some local culture considers acceptable or unacceptable.

Now there is a sneaky way that salesfolk fit in to most local cultures, and it is to be genuinely curious. I want to know what your problems are, as you describe them, and as you do I will be able to learn a lot more about your language and your priorities and your values. You will be teaching me, indirectly, how to sell you my product: “So you were talking about how you need to be able to periodically monitor each of the Floozels in your company, we have technology which automatically periodically monitors web sites for changes, I wonder if there's a way that we could treat each Floozel as a web site or so, even if we didn‘t solve the monitoring problem immediately we could at least give all your Floozel Monitors at your company a weekly automatically-up-to-date checklist of every Floozel they're supposed to review, just by pretending that each one is a web site that changes every week when we send out the new email batches... but maybe we can make it even more smart than that, I’ll talk to my engineers.” I cannot have that conversation if I come in from the get-go talking about web site monitoring solutions, they will never tell me about their problems with Floozels and they will just say, “uh, we have not updated our web site in two months, I don't think it needs weekly monitoring” and the conversation will be over.

Ask a lot of questions when talking to your superiors, identify what their interests are and what sort of problems or constraints they feel around them. Ask a lot of questions when talking to your subordinates and peers, too. Especially ask questions about your own understanding: “So if I'm hearing you right, you’re saying that the shop floor system is not an information tracker, you already had gone paperless on your shop floors since two years ago?” “Well I mean we would still like it to track the same information because we don’t want to have two separate computer systems but yeah, if that is the only thing that this does then I don’t see the point either.” “OK so what is the point, what do you actually need here?” “I mean sometimes adding a supervisor will slow down the output of my shop floor, and I don’t have a great sense of where things get stuck and where we could add resources to make money. I really need to know what everyone is spending their time on and how fast stuff has come out in the past with different configurations of people.” “Aha, so this is a time tracker?” “Well uh, I guess yeah, it is, but uh, you gotta be careful talking about tracking time in this industry. Guys on the floor will just assume that you mean that you’re not going to pay them when they go to the bathroom.” “Oh so we're talking about tracking the time of the projects, not the time of the people.” “Exactly, exactly.”

Do not rush to speak, either. You can nod and give confirmatory grunts to let someone know you are listening when you are not summarizing your guess about what they just said in a question, but just... lay off a bit. Give them a silence, see if they fill it up with some more words. And when you do speak, remember the advice of Hillel the Elder, not to say anything that you do not want someone else to hear, no matter how much you trust the people you are talking to. Or if you prefer the New Testament, James 3 is a direct lesson for you about speaking like a leader.


1. Don't pass technical info up the food chain

2. Executives only wanna know, why and what and who, not how.

3. See Engineers are minions whoes work is to handle complexity for the company in return of payment, if you've to think about the complexity yourself as a manager or executive, your engineers aren't doing a very good job at it and someone must be fired, adopt this view.

4. You and executives are on another level controlling technical resources which are like sheeps, so be a German shepherd and guide them properly.

Pass down only the information essentially to operate. Engineers having more info/control is dangerous.

5. When being asked about a particular hire, use this language. Well Rick is technically sound but doesn't know much about how things work in business (plaster a wicked smile), he has to be tamed then he will be good for the company. You've to express that you've total reality bending mind control over your minions.

Executives like bullying character because they get job done. So think about how you can appear like a bully to your executives.

You need to make executive feel in control, like you are his loyal dog who is like a jail warden/bully to minion working for the company.

Infantize the Engineers in your language when talking to Executives. After all infants can't take of their own food and need on-campus sushi to feed themselves

Stop asking for advise on HN, here Engineers outnumbered executives so good answers will only receive downvotes.

In real life, being politically or ethically or morally correct has nothing to do with the Success.


Depends on who you’re working with, and for. I think it’s extreme to say that’s universally true.

One of the core tenets of the company I’m currently working for is to acknowledge, share knowledge, and own the “what” and the “how”. This is codified in explicitly those terms, as well. It’s a large and old company in the radio technology and communications space. (Note that there’s plenty of criticism to level at it, but that area is one where they’re very good)


Damn that's cynical. I hope you find something better.


Talk like https://en.m.wikipedia.org/wiki/Sales_engineering


a leader would ask for clarification, so there's always that.


Great way to immediately lose credibility.


My advice to yo is to hire an assistant who is capable of teaching you these things. Unshakable trust will be needed on both side. Try to find someone like a recently mustered out Army Ranger. I am not kidding.


I think this is an impractical first step, but for the downvoters, executive coaching – including specifically ex-mil coaching – is a real thing that people do and get value from.

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.


Hehe, I also recommended the same book in my reply. Definitely, a must read! :p

What do you mean when you say, you "found the book a bit difficult"? As in tedious to read, or difficult to implement?


Difficult to implement, by way of being difficult to agree with in some places. It advocates a level of self-blame that feels like it would be effective from a self-motivation perspective but is not necessarily always reflective of reality.

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.


Repeat the name of the person you’re talking to frequently, and lie a lot.


So that's where that "Tim Apple" thing came from! That's genius - only a true leader could have thought of it!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: