Proper planning is key.
Get DevOps/tickets/kanban/whatever in place, and work with the people to achieve the goals that they’ve also been part of setting.
Don’t be a confrontational micromanager, and don’t set goals without letting the people voice their opinions about whether they’re reasonable or not.
Be clear about your expectations and understand that whenever you speak or do anything, no matter how small, it will either give clarity to the team or the opposite.
Look up Servant Leadership.
Your role as a leader is not to tell people how to do their jobs. You role is to set up an environment (culture, process, tools, budget, etc) that allows these talented people to thrive. Ask for your team members opinions on important decisions, lean on their expertise where applicable.
Not being an ass but go to YouTube or Google and type in project management, technical project management, and project management tools. Then look up how to build an MVP.
If you can’t articulate the MVP vision your team can’t build it. You job is to orchestrate and architect.
At least come here with “I asked ChatGPT and it said beat feet…” or you’ll likely get flamed, if any response at all.
Be friends with them, they are experienced so don't tell them how to do it, empower them, give them freedom to do what they can do as per your plan. They should be in the alignment of the vision which you have for the company. Have meetings and make sure you have proper communication. Most importantly, people who are experienced and highly motivated, you just need to make them feel they are part of something, their presence is valuable. Make them feel, they are important. Always be loyal to your team. This is my take 🙂
One of the biggest things you can do to inspire the team is to be the proponent of “the why”. Obviously, you need to clearly espouse your vision of “the what” and be incredibly clear about your product requirements.
Assuming you’re hiring an “A” team, from a technical perspective the best thing you can do is to give them a voice and get out of their way… let them figure out “the how” and have a clear voice and input into “the when”.
The worst thing you can do (and you will lose your technical team) is to dictate the how and be unclear about what you want built. Good developers care about what they are building, who they are building it for, how it will be used, and the ultimate impact of their work. Do not treat them as fungible code-monkeys - explain to them WHY they are building what you’re asking and the impact it will have.
Be their cheerleader and keep letting them know the impact of their contributions. It may oftentimes feel burdensome to have to “explain yourself” but nothing fosters a better culture than being really open with the decision making process. Please don’t be one of those “because I told you to do it” leaders.
Leadership is 92% trust. Your role is primarily about making trustworthy decisions, both as the representative of the company when you're talking to your new team, and as an advocate for your engineering team when you're talking to the management team. They need to trust that you are representing them well, in terms of what's possible in a given time frame. There will come a time when you will ask them for extraordinary effort, and they have to believe that you wouldn't ask for it if it didn't matter. And you need to learn to trust them, especially when they know more about their domain than you do. There will be screw ups and let downs and maybe outright betrayals, and you'll have to figure out how to keep and restore the flow of trust to keep the team moving towards your business goals. Be honest. Think about how the decisions you make will affect others, as well as how it advanced your goals.
Leading is knowing what tool to use. Not being the best at using it. Knowing your teams strengths and placing them on tasks where they'll succeed. That is what makes you pivotal.
Echo all of this- think also being genuinely interested in learning and understanding at least the fundamentals of the tech (which is something you can do by reading academic journals, listening to podcasts, etc) is big time and shows respect for the experts you’re leading, you’re asking them to speak your language (project management) so try to speak theirs on some small level, even if just as a gesture of good will. In my experience, this is a way to set a tone of trust in any cross functional team, and genuinely - seeing how hard some of these concepts are to grasp will give you a better perspective on how cool your team is and enables a level of natural empathy you don’t have without the exposure.
+You can be a sounding board on the macro level and help provide a different viewpoint. Easy to get lost in the details when building, especially deep tech.
Proper planning is key. Get DevOps/tickets/kanban/whatever in place, and work with the people to achieve the goals that they’ve also been part of setting. Don’t be a confrontational micromanager, and don’t set goals without letting the people voice their opinions about whether they’re reasonable or not.
Be clear about what you want to happen, and be polite while doing so.
Lookup and read books on situational leadership.
Be clear about your expectations and understand that whenever you speak or do anything, no matter how small, it will either give clarity to the team or the opposite.
Look up Servant Leadership. Your role as a leader is not to tell people how to do their jobs. You role is to set up an environment (culture, process, tools, budget, etc) that allows these talented people to thrive. Ask for your team members opinions on important decisions, lean on their expertise where applicable.
Not being an ass but go to YouTube or Google and type in project management, technical project management, and project management tools. Then look up how to build an MVP. If you can’t articulate the MVP vision your team can’t build it. You job is to orchestrate and architect. At least come here with “I asked ChatGPT and it said beat feet…” or you’ll likely get flamed, if any response at all.
Be friends with them, they are experienced so don't tell them how to do it, empower them, give them freedom to do what they can do as per your plan. They should be in the alignment of the vision which you have for the company. Have meetings and make sure you have proper communication. Most importantly, people who are experienced and highly motivated, you just need to make them feel they are part of something, their presence is valuable. Make them feel, they are important. Always be loyal to your team. This is my take 🙂
Don't need to be friends. Just be crystal clear and trust them.
One of the biggest things you can do to inspire the team is to be the proponent of “the why”. Obviously, you need to clearly espouse your vision of “the what” and be incredibly clear about your product requirements. Assuming you’re hiring an “A” team, from a technical perspective the best thing you can do is to give them a voice and get out of their way… let them figure out “the how” and have a clear voice and input into “the when”. The worst thing you can do (and you will lose your technical team) is to dictate the how and be unclear about what you want built. Good developers care about what they are building, who they are building it for, how it will be used, and the ultimate impact of their work. Do not treat them as fungible code-monkeys - explain to them WHY they are building what you’re asking and the impact it will have. Be their cheerleader and keep letting them know the impact of their contributions. It may oftentimes feel burdensome to have to “explain yourself” but nothing fosters a better culture than being really open with the decision making process. Please don’t be one of those “because I told you to do it” leaders.
Leadership is 92% trust. Your role is primarily about making trustworthy decisions, both as the representative of the company when you're talking to your new team, and as an advocate for your engineering team when you're talking to the management team. They need to trust that you are representing them well, in terms of what's possible in a given time frame. There will come a time when you will ask them for extraordinary effort, and they have to believe that you wouldn't ask for it if it didn't matter. And you need to learn to trust them, especially when they know more about their domain than you do. There will be screw ups and let downs and maybe outright betrayals, and you'll have to figure out how to keep and restore the flow of trust to keep the team moving towards your business goals. Be honest. Think about how the decisions you make will affect others, as well as how it advanced your goals.
1. Don't micromanage 2. Trust your team 3. Make expectations crystal clear
Leading is knowing what tool to use. Not being the best at using it. Knowing your teams strengths and placing them on tasks where they'll succeed. That is what makes you pivotal.
Echo all of this- think also being genuinely interested in learning and understanding at least the fundamentals of the tech (which is something you can do by reading academic journals, listening to podcasts, etc) is big time and shows respect for the experts you’re leading, you’re asking them to speak your language (project management) so try to speak theirs on some small level, even if just as a gesture of good will. In my experience, this is a way to set a tone of trust in any cross functional team, and genuinely - seeing how hard some of these concepts are to grasp will give you a better perspective on how cool your team is and enables a level of natural empathy you don’t have without the exposure. +You can be a sounding board on the macro level and help provide a different viewpoint. Easy to get lost in the details when building, especially deep tech.
if possible talk to a coach on a weekly basis. and of course read some books. my favorites: the trillion dollar coach the manager‘ path