A New Job as a VP of Engineering: A Lesson in Trust and Collaboration

Problem

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.

Actions taken

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.

Lessons learned

• 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.