Ask HN: How to speak like a leader, not like an engineer?

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.

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.

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.

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

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.