Having a non-linear career path may seem unconventional to many, however I found that having a diverse background helped me enormously in my first year as a VP of Engineering.

My education and experience have taken me through several different disciplines. I studied Material Science and Engineering at university, then spent my early career in academic research and industrial engineering, before transitioning into ecommerce, and now digital identity.

The industries I worked in were diverse, but they allowed me to cultivate a varied skill set, from data science techniques, to deploying software applications, website migration, routing algorithms, and more.

When I first started at my current company, I joined as a technical program manager and grew the team while delivering large-scale technical initiatives. Now, I am leading the infrastructure and platform group.

Looking back, I realize that my career path has been that of a “multipotentialite” –  a term coined by Emilie Wapnick for someone with many interests and creative pursuits, who explores them all sequentially or simultaneously. 

Not all teams and individuals need the same thing from you

When I became a VP of Engineering, I inherited six teams with varying scopes and levels of seniority across the following roles: software engineering, test engineering, DevOps, and technical program management. 

When you inherit a role with such a varied amount of responsibility, it’s important to remember not to try and be all things to all people. Instead, try to discern what each team member or team needs from you at any specific juncture in time.

I created a template to track staffing and people matters across each team, objectives and key results (OKRs), things to monitor over time, and areas of improvement. These are the areas that were most helpful for myself and my teams, but there may be other sections you wish to add for yours. Ultimately, having access to this sort of information in one chart can help you focus on what is important, deprioritize or delegate areas that needed less attention, and monitor long-term effectiveness.

Each week I would review and update the chart for each team. Doing this showed where my teams’ pain points were and allowed me to direct my attention on areas where they most needed help. For instance, issues I placed under “things to monitor” helped me not to just think tactically, but to measure the long term effectiveness of anything we were changing. In the book The ONE Thing: The Surprisingly Simple Truth Behind Extraordinary Results by Gary W Keller and Jay Papasan, the authors say, “Prioritize the one thing that must be done in order to make everything else easier or unnecessary.”

Accordingly, the final section of each table had that one thing which I’d need to do for every team based on priority. I would update the section on a Monday morning, so that it could inform my week ahead, and I could pull from the toolbox of skills and past experiences to best suit the challenge at hand.

It’s interesting to note that in the weeks where I did not get around to pinpointing this one thing, my schedule would take me in whatever direction was shouting the loudest, which is not always the same as the most important. A few teams of mine have now adopted the one thing concept into their updates and stand ups.

Expectations of leaders 

• You don’t need to be a specialist. Trying to be a specialist in each of my team members’ roles would have limited my ability to perform my own tasks effectively.
  
  Instead, I relied on my understanding of the foundational elements of their roles and how they contributed to the larger picture. This was possible as a result of working closely with each team and being exposed to their fields or having played those roles in the past. Using a range of past experiences allowed me to use my breadth of knowledge to provide direction and clarity in proactive, reactive, and reflective scenarios.
  
  My role is not only to be understanding of the constituent parts, but to have a firm grasp on how everything comes together for the whole solution and system. Being clear on the outcomes we want to deliver, defining a technical strategy that aligns with our business goals and customer needs, and connecting each person’s work to the broader context.
   
• Be quick on your feet. I often need to make data-driven decisions urgently and efficiently. For example, a team member may ask if we can release a feature before a code freeze. This sort of rapid-fire scenario necessitates a quick assessment of the data and the context, often requiring further probing questions.
  
  With a level head and well thought out responses, steering our teams towards the right conclusion shouldn’t be too difficult. Multipotentialites are often aware they don’t know everything. This will make them more inclined to seek out or probe for key areas or risks. Once having found them, they can be delegated to team members that have the most applicable expertise to deal with that particular challenge.
   
• Bring visibility. Another crucial aspect of my role is to bring visibility to the work my teams are doing. This not only helps other teams better understand their work and consider dependencies sooner, but it also allows for recognition of the core work being performed.
  
  The work of infrastructure and platform teams, for example, is often essential to enable, de-risk, or make feature releases more scalable. To ensure everyone is on the same page, I summarize the work of my team in a quarterly review and share it with the wider organization and leadership executives, using the WRAP framework (wins, results, alignment, pivot).
  
  Bringing visibility also has the benefit of showing alternative approaches. There is something called the Einstellung Effect, a term for when problem solvers only employ familiar methods, even if better ones are available. We are all fallible to this, but multipotentialites are more likely to borrow techniques from the different domains they play in.

Nothing is really new 

My diverse experience helped me better lead my teams, which spanned across various technical disciplines. Whilst it can be intimidating to step into a new role or domain, each time you also learn challenges, sometimes across different industries, which seem to follow familiar patterns. 

Let’s take the example of backpressure, which is when the process of turning input to output is resisted. I have seen this in the following cases and industries:

• Software cloud services: A simple queue service (SQS) sending messages faster than a lambda function can process them.
• Software user interfaces (UIs): A keyboard inputting faster than the UI can update. 
• Software databases or file systems: Writes being slower than reads on a database. 
• Manufacturing engineering injection molding: Resistance on the return action of the screw after injecting the molten material. 
• Fulfillment centers warehouse management systems and physical conveyors: A backlog of orders manifesting both digitally and physically in a warehouse.

Recognizing common problem patterns and framing them for yourself and your team goes a significant way to actually solving it. Ideally this still gives the team autonomy on how to solve it but makes it clear where and how it needs to be addressed to bring about the solution.

The above examples of backpressure, despite them being completely different problem domains, all fall under queueing theory. While each case will require specific instrumentation, the solutions typically fall into a few general categories:

• Restrict the producer
• Buffer input
• Drop a percentage of the input
• Increase consumer/processor capacity 

We can take comfort in the fact that even when working in a new domain or with a new technology, not everything has to be entirely unfamiliar or overwhelming. In my recent experience attending an AI conference, I also came to find that we all faced the same problems. For example, determining ground truth, scarcity of samples, labeling accuracy, and ethical and sustainable concerns came up as common challenges across all industries employing AI.

Innovation is supposed to be challenging, but people are far more complex 

There was some apprehension when I first became VP of Engineering. Despite my having worked at the organization for three years before taking the position, I had never actually taken on the role of a software developer here. Others too reflected my sentiments and expressed their doubts. “Perhaps people won’t want to work for someone not technical,” they said. Some were concerned that my team might not respect me due to the non-traditional path I took to get there. 

However, I had great leaders that communicated with me the value I had already brought to the organization and why they thought I would be the best for the job. Unfortunately, as a woman of color taking on a career in the STEM world, you will always have doubters. But you will also have great champions in your leaders, peers, and teams. Being technical does not exclusively equal being a software developer.

The teams I inherited were fantastic – eager to work and collaborate together. There were, of course, technical complexities for us to solve throughout that first year, but it was nothing our combined efforts could not handle. Often, it was these challenging moments that we found the most fun; after all, if there’s no uncertainty, there’s no innovation.

Championing your teams 

From a customers’ perspective, the technologies, roles, and teams that power your software product are not always visible or even relevant. What matters to them is using the product to fulfill their needs.

Behind the scenes, however, our platforms rely on various technologies, services, and roles. Leadership requires a deep understanding of how they interact and interface with one another. Above all, effective leaders will use this knowledge to better enable everyone to work together cohesively. Learning things, sharing that knowledge, and succeeding together are some of the core values at my company for this very reason. 

I’ll admit that even as a highly empathetic person, maintaining the enthusiasm, retention, and development of an organization of 60+ can be more challenging than the technical work itself. This may look like supporting colleagues who are not feeling well, understanding different cultural sensitivities and working across time zones and countries, or leading in both times of market growth and contraction (where I have had to iterate and learn probably the most). Having a diverse set of experiences, not just professionally, but through life experiences and travel, prepared me for this kind of environment and being open to learn from and work with anyone.

Another way of building meaningful working connections is through 1:1s and group sessions with direct reports. Finding the right frequency of 1:1s is crucial to be able to cover key metrics, business as usual or OKR progress, as well career aspirations. Outside of this, it can also be a great time to connect, laugh, or cry. I also hold lead meetings, bringing together my leads to share expertise, learn from each other, and grow our range.

For those not directly reporting to me, I tried open office hours. This failed because only those who already knew me or were more confident would book time with me. Subsequently, I switched to scheduling 1:1s with three individual contributors from across my teams each week. These informal chats allowed me to connect, ask questions, get to know them, find out about what they were working on, give my insights, learn, and identify patterns across teams. During these meetings we would discuss career ladders and mentorship opportunities, and I would connect them with the right people and projects, while also getting insights for leads.

Keep in mind that having multipotential is not just drawing on your own skill, but also on the skills of your leads and team members. Delegation is essential to avoid becoming a bottleneck. And remember, help others grow and get visibility to support their career progression. 

Final thoughts 

To sum up, my career journey has been anything but linear, but I wouldn’t have it any other way. Each experience has taught me something valuable that I now bring to my role in leadership. 

Whether it’s being adaptable and focusing on what each team needs from me, leveraging both my breadth of experience and depth of experience, making data-driven decisions quickly, or bringing visibility to my team’s work, I’ve found that my multipotentialite background has uniquely prepared me for the demands of being VP of Engineering.