What We Do At VMware

What does a Senior Staff Engineer do at VMware?

In the #WhatWeDoAtVMware series, we will introduce you to colleagues from different roles and explain what they actually do. Today we are talking to Tony Ganchev, Senior Staff Engineer. Learn more about his role from the video:

What does a Senior Staff Engineer do at VMware?

Senior Staff Engineers are the first level of senior technical leadership at the company preceding Principal and Fellow Engineers. Senior technical leads tend to steer the technical side of the product portfolio of the company and ensure the technology evolves to meet long-term objectives of the company – including ones not on the current road map of product management. Senior Staff Engineers are responsible for a large chunk of the tech stack of one or multiple products or often specialize in one major component in a bigger product. 

I specialize in the problems of user interfaces part of our infrastructure-management products – vSphere and VMware Cloud in particular – and have a particular interest in building extensible systems and evolving a partner ecosystem of plugins around such systems. Senior Staff Engineers are recognized authority in their respective domain of expertise and often carry great influences on other product and domain leads across the company they do not lead directly. A lot of Senior Staff Engineers are system architects – responsible for the design of (parts of) multiple components of a distributed system. We mostly focus on the following activities:

  • Define the technical strategy for the areas we own – short to long-term.
  • Socializing and aligning with peers and more senior technical leads on the strategy and any other projects in the company that would affect our work.
  • Mentoring more junior architects to deliver pieces of the technical strategy.
  • Prepare some of the most critical architectural documents that outline the technical strategy.
  • Work with engineering and product management to get the resources to materialize architecture documents into actual products and features.
  • Present the work of the teams involved to wider forums. Evangelize the technical vision and win support.
  • Implement critical pieces of the functionality – often as prototype – to validate the architecture or to present a demo to hire-ups or the team.

How is your time spread across your responsibilities?

  • 30% Socialization, consultation, mentoring and alignment in or across teams
  • 20% Strategy building
  • 20% Architecture work and reviews
  • 30% Miscellaneous (yes, that includes coding)

How do you become a Senior Staff Engineer at VMware?

Overall, as with other levels you become a Senior Staff by achieving the level of influence and impact that VMware considers the threshold for that level. One example is that the candidate is successful in the activities I gave as examples above about the work Senior Staff Engineers do. As we said, Senior Staff Engineers can have different profiles – architects, technologists, unmatched problem solvers or community builders etc. – so evaluation matches the candidates’ skillsets to the particular needs of available roles in the organization.

Tell us about your career journey to date?

I started with the vSphere Client team in 2010 working on porting the Networking UI to Flash for what came to be known as the vSphere Web Client. While working on this, I wanted to work on more platform features, and I was trying to always find ways to have my work overlap with this desire. An intern I mentored gave me a chance to develop a wild idea about running plugins for the vSphere Client written in HTML using server-side rendering and streaming to the Client – in a vein similar to what Opera Mini or Kindle Fire were doing for underpowered devices, we did to bridge incompatible technologies. This was my first foray into extensible interfaces that defined my future career at the company. Once I joined a new UI Platform team put together in Sofia (and a newly promoted Staff engineer) I showed interest in taking over responsibilities for our plugin platform – first ensuring we address most pressing matter with our existing architecture and then to build the architecture we should have had from the beginning. 

Achieving the second got me a promotion to Staff II Engineer. Throughout the journey I always had an important asset in the managers I worked with who recognized the potential in my ideas and gave me first the opportunities and resources to pursue these ideas which coincided with the interest of the company. The latest stage of my journey started in early 2020 as the newly appointed lead UI architect for the infrastructure business group – a role that eventually expanded to more products and domains including automation. In this role, my responsibility has been to bridge the technical and organizational gaps between parts of VMware to deliver the next-generation cloud and on-premises consolidated infrastructure management user experience. My role and work toward it were recognized as deserving of a promotion to Senior Staff in the middle of 2022. A great testament to my journey has been the decent amount of intellectual property we generated that eventually resulted in eight filed patent applications, five of which have already ended up as granted patents.

What are some critical skills to be successful as a Senior Staff Engineer?

Coding and technical prowess are a given but beyond the level of Staff engineer they carry less weight. Across the different flavors of Senior Staff Engineers, the most important attribute is the ability to generate ideas and solutions to bigger problems. This does not happen in isolation, so it is important that a senior technical lead connects and socializes with people. This does not seem natural as most of us became engineers because we like talking to computers and not people. This works to a point but growth even in the technical track can only be possible if the engineer manages to align a wide forum of technical and product leads to their ideas. Sr Staffs need to constantly keep up with their peers and superiors as to what is happening across the company and industry, what are new challenges from outside, with what projects by other groups they need to align. Sr Staffs need to represent a huge number of engineers and need to sell not only their own but also their teammates’ ideas. They need to mentor younger engineers who aspire to reach their level and influence engineers to work for the Sr Staff’s ideas.

How do you keep yourself in the loop? What are the channels you follow for your professional interests?

In my case the most important source of information are my peers and technical and product leads. We work in a field where you don’t find the answers on Stack Overflow right away and our Principal engineers do not have the time to share their knowledge as freely on Medium as an OSS evangelist would (note that Kostadis Roussos, our multi-cloud architect is a great exception and shares his opinions on software and the world on https://wrongtool.kostadis.com/ regularly). Your best chance to pick their brain is to spend as much time as possible with them in the same room or on the phone.

Another great source of learning is diving into open source projects or going through the architecture presentations of existing systems. Hopefully, examples are still available on https://dzone.com/, for example. A great online source is also The Architecture of Open Source Applications that has essays about the design of at least ten applications each one of us uses on a daily basis. If you want to focus on UI or in general the control plane and want to design efficient distributed and fault tolerant systems, a non-obvious source of inspiration are game engines. Thanks to id Software always open-sourcing their older engines, you can find tons of information about what powers legendary games such as Doom, Wolfenstein and can take these learnings into any real-time visualization or network-communication library.

Since we design for human beings, we should not test their habits and intuition and rely on a century of findings in the field of industrial design captured in seminal books such as Don Norman’s The Design of Everyday Things. And to reiterate on the topic of engineering being a discipline of interpersonal relations, Engineering at Google, and Tom DeMarco’s Peopleware. Beyond that all the standard channels apply for information coming from the industry – both software engineering, and enterprise / datacenter / cloud. It is always important to be hands-on with the things users are doing to keep an eye on the industry such as managing lab environments and implementing applications on top of ours and our competitors’ tech stack.

A piece of advice to aspiring software engineers?

Focus on soft skills – engineers constantly need to work on problems that seem to have a logical answer but once these involve other people and groups, what is logical changes significantly. Every engineer needs to understand that selling an idea is a prerequisite for getting the chance to implement it as somebody needs to fund the implementation. The only thing changing with the growth in positions is the position of the person that is needed to fund your idea. Aspiring engineers need to understand what makes the person on the other side tick and promote the aspect of the idea the person is passionate about. Engineers lack a budget therefore they always need to either influence a manager or engineers with spare cycles to work on a particular idea. Overall engineers need to learn to socialize – talk about their work, be interested in the work of others, figure out ways to reach more people, and a way to connect with these people on a level beyond your work projects – thus building trust, relationships, and – best-case – lasting friendships. More great ideas happened around a coffee table than in a conference room or on somebody’s desk.

Learn how to find information – every company has internal documents that are extensive but tend to become disorganized with time. Figuring out what is the current state of a project – especially a project in which you are not directly involved is hard. Knowing who to ask is a good way to uncover the mystery.

Learn your domain, products, and industry inside out. Engineers do not just implement products; they also pitch products. The split organization between engineering and product management is not an exercise in silosing of expertise but a partnership where each side has some overlap in knowing the pieces of the puzzle so they should always be able to offer an alternative point of view. I do not need to wait for my product manager to tell me our Java SDK should be published on Maven Central and that users should sign in only once when navigating between our applications.

Recognize what makes you unique and valuable to the company, and double down on becoming better at it. Remember, this is why your company invests in you specifically. A friend of mine in Sales was once asked by HR “what are you good at and what do you want to improve?”. To both questions he smiled and answered, “selling products”.

Finally, make sure you keep enjoying yourself. Software engineering is both a profession and a hobby to a lot of us, but even more importantly – a calling. Look for things to do that make you feel fulfilled and take care of the environment around you as you would be spending a large chunk of your awake hours inside it.