How to Drive a Team Vision as a First-Time Manager
23 February, 2021

Engineering Manager (BI & Data) at Amazon
Problem
My memories of those early days are fairly fresh since I stepped into management by taking over a team that didn’t have the vision. Not only that the team lacked the vision, they also lacked the roadmap that would steer their efforts in the right direction. Lacking the vision was a critical blocker for the team to achieve job satisfaction, be motivated and productive. As a manager, I feel very strongly that the team’s job satisfaction is tightly knit to their understanding of what the purpose of the team is -- why we are doing what we are doing and how it maps back to the overall organization strategy.
Actions taken
Getting rid of an IC mindset
As a first-time manager, I was initially reluctant to deep dive into creating and driving a new team vision. As a first-time manager, I was leaning towards my IC instinct and let other leaders draft those documents and be happy to follow that. But I quickly realized within first two weeks that I needed to have a leadership mindset and I decided to take ownership and come up with the proposal I believed would work the best for my team.
Setting up the vision: three steps
To set up the team vision, I had to do three things:
- Understand what the business goals we were trying to accomplish as an organization were;
- Identify how my team could contribute to delivering on those goals. That included talking to my team members and assessing their strengths and experience, but also dissecting how their contribution could be the most impactful;
- Learn from our customers what they perceived to be our strengths, areas for improvement, etc.
By combining all three, I was able to put together the vision that was translated into a roadmap document and incorporated into our prospective actions for the next 12 months. The document itself laid out what we would do in the upcoming period and why we would focus on those things, but also clarifying why other things remained below the line. As much it is essential to highlight the yes part, the no part should be also clear to the team.
Lessons learned
- Prioritize heavily. I initially thought that we should do A, B, and C -- and ten more things -- but once I laid them out and better understood the scope of things we had to deliver I realized that I will have to heavily prioritize on those things. I had to narrow it down to things that will have the highest impact for my team and the most important part of narrowing things down is the ability to say no.
- Get buy-in from all the stakeholders for items you selected to work on. Focus on things that make the most sense for your team to work on. Things that remained below the line might be there for multiple reasons -- for example, not being important or requiring excessive resources -- and the team should be aware of those reasons.
- Don’t be afraid to reach out to your customers for feedback. I was pleasantly surprised by how people were willing to share their feedback and discuss our strengths and areas for improvement. I was very proactive and didn’t shy away from contacting them. By doing so, I established an informal mechanism where customers could deliver their feedback on a monthly or quarterly basis that could directly influence our roadmap.
- If I asked someone from the team what we do, I would be able to get a clear explanation captured in a couple of sentences. They were able to connect their day-to-day work to long-term goals and comprehend the whole process end-to-end. We used to spend 90 minutes on our bi-weekly planning to detail what we would work on in the upcoming 30 days. The process now takes 30 minutes, and we are saving 60 minutes that we can put into execution.
- The overall satisfaction of the team went up. Understanding the purpose behind their day-to-day work and how they are contributing to the bigger picture, was immensely rewarding for the team.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
9 April
As software engineers, we mainly talk about the power of tech skills and spending time learning new skills. However, there is also the influence that impacts your career as well.

Otavio Santana
Java champion, software engineer, architect, and open-source Contributor at Independent Technical Advisor
29 March
Have you ever had a business idea that you just couldn't shake off? Maybe it's a side project you've been working on in your spare time or a passion project that you've always dreamed of turning into a business.?

Sherman Poon
CIO /Partner at Blockchain, Media, AI and Medical Services Startup
21 March
A short overview of a very effective leadership assessment by Jack Welch, that is easily transferred to other industries is the 4Es of leadership – energy, energize, edge, and execution.

Ramesh Dewangan
CEO at Quantum Vision Consulting
7 March
3 ways leaders can cultivate relationships that lead to better products.

Guy Jenkins
SVP Global Customer Experience at Salesforce
25 March
Oftentimes Engineers work in silos, developing products to specified requirements, while they remain disconnected from the most important of questions - "WHY are we building this?" We'll explore the consequences of this mindset, as well as how to connect your Engineers to the larger Company Vision.

Eric Adams
VP of Engineering at ExecThread