A New Job as a VP of Engineering: A Lesson in Trust and Collaboration
30 June, 2020
When I joined my current company not only was the company new, but also the team, product, and culture were new as well. I was genuinely concerned about how I should approach the first three to six months as a VP of Engineering as it was my first time to land a leadership position at a company in which I didn’t grow organically as a leader. I had to earn respect and build trust and therefore I deliberated on what to do and how to approach change management and adaption (both for myself and the team). I saw that there was lots of room for improvement and was intrigued by how to prioritize and tackle the changes through an efficient, highly organized, and caring approach.
I obviously introduced myself first, but immediately I began to observe, listen carefully, talk to people, and not assume anything. The first few weeks were about getting up to speed with the new dynamic. I had sit-downs and conversations with everyone trying to understand what was driving them, what were their challenges, etc. I listened to their pour outs as I was working to establish trust -- a value I cherish the most -- while learning about our team, processes, strengths, risks, and areas to improve on. In addition, since the person before me in my role was our co-founder and CTO (and was still with the company as a CTO), we had to explain the team in full detail the difference between a CTO and a VP of Engineering.
Once I compiled all of my notes and processed all of my observations, I rolled my sleeves to build my own roadmap and address key issues. For example, How we structure the engineering organisation from a scrappy startup to a scale-up, How we deal with a still-prevalent Waterfall approach, How can we leverage the knowledge of long-tenured engineers which became bottlenecks, or any other issue like lack of clarity when it comes to personal growth, unstructured teams with external dependencies, compensation vs market rates, technical debt, etc.
I prioritized my goals using several rubrics (the business value it brings, the risk involved, the effort required, etc), and based on that I completed my roadmap. My mission was to establish self-organized, cross-functional, high performing teams.
I bounced off ideas and vision with my CTO and other leaders in the company and received valuable feedback which I applied to my initiatives. Then I communicated the plan to my team. It’s important to not kick the hive with your big boots -- when the team understands why you’re doing what you’re doing and how you plan to get there, you would get support and alignment. Make sure they feel that their feedback is heard and valued.
I delegated some of the things to my team leads where that was possible. Obviously, you can’t do it all by yourself, and change management is easier when familiar faces are on the driver seat! Make sure that your team leads get the recognition for the work they did. Your role is to empower your teams, not to be a superhero going to battle alone.
Once things were implemented I would rely on data to measure impact and provide visibility on progress and success. For example, by re-adjusting Waterfall, we could highlight the cycle time to deliver features that saved a lot of time.
Those first three to six months have been very productive and galvanizing for me. I treated all those problems, in the same manner, I did as an IC -- I would reiterate, move fast, get feedback.
- Self-organizing teams require a close partnership with Product Management and Design and it is crucial that those three functions are collaborating closely as part of the same team.
- To build trust, you should empower people. Even if you did your own research it is important to delegate some initiative to address them: For example, my team leads were keen on introducing some big structural changes, delegating that helped them build trust between them and their teams and them and me.
- A leadership position almost always entails the risk of introducing an erroneous change, but nevertheless it is important to introduce those changes with a caring approach. Different people react to change in different ways and they need to understand the reason for a change. Listen to them and provide additional guidance especially if the new process or framework that will impact their work.
Peter Fedorocko, Director of Engineering at Workday, discusses if a manager should keep his skip-level one-on-ones and describes how he introduced the Open Doors instead.
Director of Engineering at Workday
Peter Fedorocko, Director of Engineering at Workday, recalls his early efforts to build a large, multilevel engineering organization in a short period of time -- one step at a time.
Director of Engineering at Workday
Virendra Vase, who has had numerous Executive Engineering Leadership roles like CTO, COO, SVP at startups like Patreon, Life360 as well bigger companies like Salesforce, Yahoo and Experian,, shares five useful tips he wishes someone had given him as he was embarking on his career as an emerging leader in the business world.
CTO/COO/SVP at Patreon, Life360, Salesforce, Yahoo
Fraser Carlisle, Vice President and Global Head of Digital Product of iShares at BlackRock, dissects how he got executives to buy-in into his ideas and how he managed to retain them through the whole process.
VP, Head of Digital Product, iShares at BlackRock
Andrew First, Co-Founder and Chief Technologist at Leanplum, discusses how he managed to complete a large infrastructure project by instilling confidence in his team, setting precise benchmarks, and streamlining his focus on what really mattered.
Co-founder & Chief Technologist at Leanplum
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.