I recently completed my 6-month onboarding process and am now beginning to take on the full scope of the VP of Engineering role for our team. The journey was unique, fun, and also instrumental in setting me up for success to lead our team. While every organization is different, I believe sharing my experience can be useful for other teams as they bring in external engineering leaders.
I’ve divided my story into two parts. This first part is a high-level summary of the process and my experience going through it, and it aims at providing insights as to why this approach could be great for your team (as it was for ours). In the second post, I will share implementation details that I believe will make it easier for others to adopt this approach.
Approach
How to onboard a VP of Engineering? This was one of the many considerations our engineering managers and tech leads incorporated into the hiring efforts for this role. They discussed, asked candidates (myself included) about their thoughts regarding onboarding, and eventually decided to try the “Embedding Process” that Hubspot uses when bringing in external engineering leaders. In this approach, the new leader spends their first several months (5 ½ in my case) working as an individual contributor and they are treated just like any other engineer who joins the team. The new leader is not given any leadership responsibilities or assignments and must resist the peer pressure and their own temptation to jump in and solve problems they’ve solved in the past and now detect in their new team.
I embedded with a total of 11 squads, staying 2 weeks with each one. Keeping the total onboarding time to about 6 months is ideal: it allows for discovery and learning to occur and consolidate, but it doesn’t stretch it to the point of diminishing returns. At the same time, it’s crucial to embed with every team. So there is a tradeoff between total time and the time with each squad. In our case, I couldn’t spend as much time with each squad as I would consider optimal (I believe this to be 4 weeks/squad – I’ll expand on this in my next post), but overall the schedule worked well.
To many, this process might sound counter-intuitive, ineffective, and inefficient. But there are sound reasons why this makes sense for onboarding engineering leaders, and specifically why it was good for us.
Objectives and Experience
We considered a few key objectives as indicators of success for this process. I briefly describe these below and share my own experience around them.
Strengthen the foundation
Foundation here refers to our core engineering principles, values, culture, organizational structures, processes, architecture, techniques, patterns, style, and domain knowledge. In an established team (I consider Seeq’s team to be in this category), this engineering foundation has been carefully and thoughtfully built. It reflects years of collective efforts, experiences, learnings, and adjustments made by a solid team. When a new leader joins from the outside (myself included) their leadership skills and the way they guide their team to build software will naturally reflect the style they have acquired, which is not necessarily the same as what is established on the team. Therefore, there’s a risk that this foundation begins to be misaligned and even crack. The embedding process allowed me to become intimately familiar with our engineering foundation and adjust to it. As a result, I’m more confident when thinking about future endeavors to strengthen, expand, and evolve this foundation as we continue to grow our business.
Build trust, credibility, and empathy
The embedding approach offered three avenues to accomplish this:
- working together on technical tasks
- meeting 1-on-1 and participating in squad activities and ceremonies
- gathering feedback from each squad after the rotation.
Code has connecting powers: the technical tasks I worked on gave me plenty of opportunities to collaborate with team members at all levels. I learned a lot about their abilities, strengths, knowledge, and creativity. They supported me and helped me complete my tasks. More importantly, we started to establish a relationship without any sort of hierarchical barriers or power struggles: we were at the same level when we worked together to solve problems – I was not “the boss” or an intimidating figure. I also developed a good understanding of the challenges, friction, and pain points the team members experience regularly while doing their job (note this varies from squad to squad). As a result, I now have a higher, reality-grounded level of empathy and intuition that I can use to plan, propose, and/or sponsor improvements.
After I finished embedding with a squad, we sent out an anonymous survey to ask for feedback about me (kudos and/or constructive criticism) and about the process. This proved to be extremely useful to fine-tune and adjust as I went along, and I very much appreciated the transparency and honesty of everyone. I’ll share details of the survey and feedback in my next post.
Understand our product and our customer needs
We are a product company, and that is the main way we add value as engineers at Seeq: to build and ship a delightful, high-quality, and effective product for our customers. Our product has significant depth and breadth. We have multiple applications (Workbench, Organizer, Data Lab), developed in multiple languages, deployed across multiple cloud providers (AWS, Azure), integration points (Connectors and Plugins), and extensions (Add-ons). Moreover, these are assembled by using many different services, modules, and components that we develop and maintain. Embedding allowed me plenty of time and opportunities to interact with our software, experience the awesomeness of our suite, but also feel some of the same pains our customers experience as I bumped into some bugs, performance issues, UX nuances, etc. Using the software and at the same time digging into the underlying code and architecture that makes it do what it does was extremely helpful at giving me a holistic understanding of “the system” by the time I finished the onboarding, in a way I believe would not be possible otherwise. I also had a chance to see first-hand the level of support the engineering team provides to our users by embedding with our Support squad and participating in several customer calls. I also watched how our engineers interact with our customers asynchronously via our shared development and support tracking system (JIRA). Finally, I am thrilled about the fact that I delivered some new features, enhancements, bug fixes, and prototyped some new ideas. Now I am excited to see our customers put these to good use and hear their feedback.
Learn our tech stack (and the joy of programming)
I consider this more of a byproduct than a primary objective of the embedding; nevertheless, I find it to be a significant outcome. The role of VP of Engineering is demanding, and while having strong technical chops and knowing the tech stack are crucial to success, the typical day does not present many chances to exercise these muscles. One must be intentional in balancing all of the responsibilities of the role and find creative ways to stay attuned to what is going on at the ground level, without ever becoming a bottleneck or even a point of failure. Over the years, I have developed mechanisms to do this effectively, but there’s always that dream of being able to dedicate a few days just to code and build something occasionally. In this regard, the embedding process has been a gift. As silly as it may sound, I find this “stockpile of joy” an invaluable reserve of energy that helps offset the frustration and pressure that inevitably arises when “things break.” But more importantly, having worked on a significant number of our core components and having had time to “go deep” is also greatly beneficial for me to support, sponsor, guide, propose, and assess technical initiatives as I move on to the full scope of the VPE role.
Conclusion
All in all, I’m exceedingly grateful that I was presented with this opportunity and for all the support I received from everyone on team Seeq. We have a terrific engineering team, and I am convinced the insights and learnings obtained during this period will be essential for the road that lies ahead. I am excited about taking on the next challenges and I see tremendous opportunities for growth, success, and excellence.
Our team and I learned a lot as we went through this process for the first time at Seeq, and I believe this approach was not only helpful for us but it can be helpful for any other engineering organization as they grow and onboard new leaders.
In my next post, I will share details on “how to implement” the embedding process for leaders, which I hope will make it easier for others to try and adopt this approach.
Credits
As I mentioned and linked above, the original idea of the “embedding process” came from Hubspot, and having that frame of reference was super helpful for our squads and me. I highly recommend their Product Team Blog, they have a great variety of insightful and practical posts there.
Finally, big thanks to everyone on Seeq’s team who helped and supported me through this onboarding phase – you’re the #1 reason for it being a success story.
Thank you so much.