61–70 of 218 posts
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.
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 fulfillme…
That's more management-speak than engineer, in my experience. I hate being referred to as a resource.
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…
This is just bad advice. Don't listen to this guy.
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.
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.
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.
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?
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.
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 e…
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…
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.
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 "…
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.