similar products:
comments:
Some people are naturally better at it than others; sure. Anyone can learn how do it and do it well. My advice would be to be confident in what you know and don't be afraid to admit you don't have all of the answers. Being confidently wrong will backfire on you with those stakeholders. The trick is to figure out how to wrap difficult technical things in something that other folks can digest. For example, just yesterday I was talking with the Security lead... some of our facilities are saying "We should have sys admin training!" and the reason is because in some cases they have knowledge of some administrative credentials. We obviously don't want to do this because they shouldn't be making changes; being confidently wrong in what they are doing because they've been given training on "how" to be a sys admin. The way I suggested explaining it to the more non-technical leadership was "It would be like saying the secretary at the trucking company, whom has access to the semitruck keys, should have a CDL" It is being able to talk to them when they say, "I want a button to do X!" to guide them to what they really want. "What are you trying to do?" ... "Oh, so what you really need is a better way to do Y?!". Often times they 'design' the solution because they don't understand what is happening in the background. The button they wanted would allow them to fix some property that was set incorrectly earlier on when the real fix is just making it so that doesn't happen in the first place. The real issue is they don't know about that or how to think about it. Your goal is to develop the 'soft' skill to interpret their ask and figure out what the real pain point is. Also, read this: https://www.amazon.com/Radical-Candor-Revised-Kick-Ass-Humanity-ebook/dp/B07P9LPXPT
I went through this transition; and there are any number of methods or advice (below are sever of the books / resources I used and like) but the gods honest truth is nobody gets this perfect and there is no one single way to do it. You have to take bits and pieces and build your system. You have to develop systems that work for you and work for your team. Be honest, be open, listen more than you talk, care about the answers. Don't say you don't know what you are doing -- but don't act like you have it perfectly figured out either. Frequency of 1:1 and status reports depend on the environment. It depends on what the team needs. https://www.amazon.com/Radical-Candor-Revised-Kick-Ass-Humanity-ebook/dp/B07P9LPXPT https://www.amazon.com/Becoming-Technical-Leader-Gerald-Weinberg-ebook/dp/B004J4VV3I https://wherewithall.com/tools/#book https://shop.beplucky.com/products/the-plucky-1-1-starter-pack-new-and-improved https://softwareleadweekly.com/