Role of the VPE in Management

The role of the VPE has two essential tasks: (1) to build and direct an efficient organization that can do the work and to which operational responsibility can be delegated, and (2) manage the complex web of communications between the Engineering organization and all the other interested parties, be they other managers, customers, board members, VCs, customers, etc… The exact nature of these tasks evolves quite a bit as the company grows, which in turn means that the VPE has to grow themselves with the company.

All these tasks involve working with people. In this chapter we will introduce three concepts that define the successful VPE’s relationship with all the people they deal with:

• Integrity
• Leadership
• Management

We’ll also look at how these concepts evolve as the company grows.

Integrity

The number one rule of being a successful VPE is to always maintain your integrity. That means being honest with your staff, our superiors, your customers, your community. It’s all to easy to take the easy way and try to hide bad news, or overstate good news. In the short run it’s often painful to be honest. But in the long run, you will create a tremendous amount of credibility by being honest. We can easily illustrate the power of integrity with a couple of stories from our professional lives:

Story #1: Competitive Bids

Our company did well with competitive bids.. there was a case where a competitor came in with a lower bid 40-45% less to try to buy their way into the business. I told the customer he just couldn’t build it for this price.. the customer had to go with another vendor because of internal regulations… but 6 months later the vendor was kicked out and we got the job..

Story #2: Coming Clean with the customer

My company had a long history of quality problems. We got a huge OEM contract from a much bigger firm. I admitted to them that contrary to what was implied during the contract negotiation, our bug database was misleading, and we had a huge backlog of issues, 3000 of them. I explained our action plan for correcting these. Over the last couple of months we have corrected most of these problems. Initially senior management was very nervous but admitting this. But in the meantime, the customer greatly respects us for being honest as well as acting on our promises, and engineering morale is way up for management being honest about the quality situation.

Leadership and Management

As a VPE your job is both to lead and manage the organization; that implies both setting direction, and ensuring execution. Finding the right balance between these in terms of managing your time is very important. How you strike that balance will be different between a small 6-12 engineer startup and a 300+ person organization. The choices you make will in the long run also affect your career development.

Be a Leader

Being a manager is a bureaucratic exercise unless grounded in good leadership. A good definition of being a leader is:

A leader is someone whom people will follow.

There are two aspects to this. One is the attributes of the leader that cause someone to follow them, and the second the attributes that cause them to lead successfully in a proper direction.

The good leader – Studies have shown that as a cultural invariant people perceive leaders to be individuals who are honest, competent, inspiring and forward looking. This makes sense – it’s hard to follow a leader one can’t trust, and someone who is apparently dishonest or incompetent is not worth following. And since leadership invariably implies a leap of faith to do something hard, the leader needs to be able to inspire people into believing the message and following.

Urgency – Once you’ve got people following you, a sense of urgency is key. “Time is money” is the old adage. A key role of the leader is to continually push, pull and cajole the team into producing at the highest level. While keeping the pressure up won’t necessarily make you more popular, it will keep you delivering on your roadmap.

Skepticism – Another key attribute of a successful leader is skepticism. The bigger your organization the more people will “manage up” and tell you what they think you want to hear. You have to relentlessly probe to get at the real truth and question assertions to make sure people have thought things through and are presenting honest, factual and thoughtful accounts. This also sets the expectation throughout the organization that critical thinking is valued.

Direction – Finally, and this is clearly part of the inspirational/forward looking part of being a leader, you need to be able to communicate a clear vision to the team. This doesn’t require clairvoyance on your part, although that helps. It does require guiding the team into spending enough time on long term planning, and making sure your development efforts are well aligned with the general business vision of the executive team. A lot of this is about communication with other stakeholders and ensuring that enough time is left for strategic as well as tactical planning. Make sure you can tell both your long term as well as your short term story, and that your short term story logically leads to the long term story. Enforce that with your team too.

A lot of good leadership is simply modeling the right values for your team and getting them to follow you in adopting these.

Be a Manager

A good manager sets (or communicates effectively) the direction for the team, energizes and motivates, and then removes obstacles so that the team can be as productive and high-flow as possible. That’s the management job. S/He ensures the team’s resources are up to the task, that the responsibilities are effectively apportioned, defined, and complementary. Once in place and running, the manager’s job is to identify impediments to progress and eliminate them. This includes people, as well as ambiguity, resources, and support.

You can’t create the products yourself, but if you create the right team with the right culture, then things will happen on their own. As they say:

• When it’s done right, it’s the team
• When it’s not done right, it’s the manager

Management has many aspects, including setting culture, creating an organizational structure, dealing with transitions in the group and hard people, and simply adjusting the to the effects of growth. We’ll look at all of these in this and the following chapters. We’ll start by examining the basics of managing an organization effectively.

Managing Organizations and Scale

Small and growing organization

Management Characteristics (in the context of a fast growing startup)

The VPE in a startup is typically the executive (individual) with the largest number of peer-level and subordinate colleagues. Typically in a startup, the other departments are not fully grown / staffed-up, until there is product to sell. So in the early stage, the other execs don’t have nearly as many direct reports as the VPE does. This creates a unique situation for the VPE, because s/he has the largest number of individuals he must work with. Since the company is still in the formative stages, s/he doesn’t have a layer of managers who can be devoted to the engineering staff; this is still the VPE’s responsibility. At the same time, the executive team is at full-speed on positioning, fund-raising, product specification, messaging, etc. and the VPE must represent engineering in all of these discussions as well. At this stage, the VPE can wear many hats, including HR, Purchasing, IT, Program Manager, Technical Manager, QA Manager and Documentation Manager. The main focus has to be to advance the product as quickly as possible while burning as little cash as possible. It is a very challenging role, with a lot of risks, but ultimately very rewarding, financially or otherwise.

In such environment, you will typically face all types of shortages, personnel shortage, equipment inadequacy, tight budget, lack of specific expertise, etc. Naturally, time management and prioritization are very critical here, not just for your own time, but for your team’s time as well.

Staffing – Who to Hire

As in a larger organization, the first sets of hires should be to fill your most critical needs. These are typically skills or expertise areas that existing staff or yourself cannot fulfill.

Because you won’t have much time for hand-holding your staff at this stage, it is best to initially hire experienced engineers who can work without much supervision. As you grow, you can start filling in middle management roles as needed.

One method that is very effective is to create a spreadsheet with columns mapped to skills required for your team like C++, Java, Db Design, etc and the lists representing the employees. For each employee there will two values: one to represent the effective skill for that employee. Effective skill means, how much he/she can contribute to the team considering that he can be pulled to tasks besides his/her main responsibilities. Some examples for this case are consulting for another group, helping on maintenance, etc.

This table will give you a good vision of where you are and what are the positions missing.

Structure

Initially, you will likely have a flat structure, where you manage the entire staff directly. However, don’t equate flat organization as being unstructured. Roles need to be defined, even if you only have a handful of people in the team, or you will risk overlapped effort, and worse, trampling of each others work. Roles clarification also breeds stronger sense of ownership, which in turns breeds good behaviors such as proactive drive for improvement. The role should fit the personnel and expertise area well. A database expert should own the database area, although he/she may also work on programming in other areas. Since the VPE can have between 10 to 20 direct reports, some of them junior engineers, mentoring is a key role, spreading the vision and the clearly communicating the roadmap goals is paramount. Weekly 1:1 meetings with each direct report are important to ensure that less senior employees are ‘on-track’.

1:1 meetings are one of the most effective ways to connect and sense how your reports are doing, their concerns and needs. It’s recommended to do as much one on ones as you can, this will help the VPE to match company needs to employee needs unlocking the full potential of your team.

Medium Organization

Management Characteristics

In a medium size organization there is a single Engineering organization run by the VPE, which encompasses a broad range of teams focusing both on product teams as well as functional specialties, often including besides development also QA, technical writing and lab management. Product management may or may not be included. At this point the VPE has to focus on building effective teams underneath him to free up his/her time to work on planning, communication with other parts of the company, customer discussions, etc. At this stage, the company has accrued an installed base of customers who need support and maintenance. The development focus begins to shift generally from feature prioritization to a balance of features and quality.

Structure

In a medium-sized organization the VPE is a second-line manager, supervising a set of first-line managers. In this case much more time is spend on communication. Key to success is having strong enough first-line managers to be able to trust them and delegate to them, while still knowing when to intervene and fix problems.

Here is where some leaders can fail if they don’t recognize the need for supervised delegation. Centralize too much and you are not going to grow the engineering organization. Delegate to much and you will loose control of the key factors that keep the organization together.

Large Organization

Management Characteristics

In very large companies engineering is no longer monolithic. In this case the overall product development organization is often run by pure business people who may have their own p/l responsibilities. In this case the VPE is running just a part of the Engineering organization typically reporting to a general manager of some kind. The relationship to the general manager may be similar to that with a CEO in a smaller organization. However, the need to understand underlying business issues is really heightened because one may need to interact with and gain support from several layers of essentially non-technical management. As the development organization grows, the number of management layers also grows. There may be as many as 3 to 5 layers of organization, with Senior Directors, Directors, Managers and Project Leads. Unless communication is managed effectively, the VPE can quickly get out of touch with the state of projects, releases, strengths and weaknesses of the hands-on team. Likewise, the team may not have an accurate up-to-date understanding of the company directives, etc.This is why it’s important to have skip level meetings and ‘all-hands’ meetings to disseminate information in a timely manner.

Time Management

In large organizations it is easy to get stretched too thin, because there are simply too many things to keep track of, too many meetings to go to, too many people to meet. The key to success is careful setting of priorities, and delegation. On the whole one has to allow ones direct reports to run their teams on their own. Then one can focus on setting the agenda for the team, and deep diving as required into the teams to investigate or help with particular issues. This model is flexible and highly scalable. That requires having managers working for one who can be trusted. It also requires you to master an often very broad range of product and market issues, without getting too bogged down in detail. There is a fine line between knowing enough to help set strategic plans, and be able to spout trouble, and trying to know too much, which becomes futile in larger teams. Learning to quickly dive into things and then coming up quickly again for air is a useful skill at this level.

Staffing

In a large organization the VPE is often a fourth level manager, with Directors, Senior Managers and Managers reporting to them. Typically, the distinction between the directors and senior managers at this level is that the directors can be trusted to work more independently, setting more of their own agenda, and having a broader impact outside of their own organization, whereas the senior managers are requiring a bit more direction and are more local in their scope.

Organizational Design

In bigger teams one can really think about organizational design. That is, one can classify workers into different groups, by skillset, seniority, etc., and plan abstractly what makeup of people one is looking for, what kinds of recruiting to do, what kinds of career growth to encourage etc. So while a smaller team can only hire particular people for particular jobs, in a larger organization you can hire twenty college hires, and find roles for them afterwards. We can also ask questions of the form: Which people should we groom to become directors, and what attributes should they have? With the importance of offshore development, questions about how can I most economically grow my team, and in which geography can I find the right talent for the right place, also tend to be more practical in a larger organization.

The organization may be composed of multiple product groups, including teams of development and QA engineers, as well as product management, tool and infrastructure teams.

Vertical Communication

In a large organization there are typically a number of layers of management. Information tends to flow up and down very badly in most organizations. This requires special steps to make sure that everyone is communicated with. Skip level 1-1s, group meetings to align on strategy, all become very important for keeping a large organization in sync.

An effective way keep up-to-date about your projects and risks is to define a document generally called “projects dashboard”. In a projects dashboard you want to summarize tree items:

– Current project status and important milestones.

– Risks identified

– Proposed/defined action items.

Each manager would create one document covering all his/her projects. By having a weekly meeting with your managers covering these items will help you not only to be in sync with them but also to sense their risk management skills.

Growing with the organization

Learning to delegate

The more one grows in one’s management career, the more one needs to learn to effectively delegate. This involves identifying people whom one can trust, and trusting them to reach the right outcome. This level of trust is a subtle thing. It’s easy to become too trusting and get some nasty surprises; and just as easy to micromanage. The balance between is often tricky. In fact the right level of trust can be built up via effective mentoring. A good way of managing this trust is to allow people to do their thing most of the time, but on whim to dive down and spot check what’s going on. Another good technique is to talk to other people one’s direct reports interact with, and find out what they’re seeing.

Staying technical

In many small teams the VP is the technical leader themselves; as the team gets bigger, success is less about creating the technology oneself, versus creating an organization that can create the technology, as well as an environment for it to thrive in. The bigger the organization gets, the more success is about finding, motivating, growing, retaining and working with people. Nonetheless, in an Engineering organization there is no substitute for having the technology knowledge to be able to drive the business itself forward. With one’s time fractured between competing demands and too many meetings, it’s easy to lose the technical edge. Therefore, one always needs to spend some time keeping up with relevant business and technical trends. The trick is to learn about those aspects of technology directly relevant to and that differentiate one’s business, while staying clear of many implementation details that others can take on. At the same time, the experience one had years earlier as a coder and a junior manager is often still relevant and not to be forgotten. A caution there is when disruptive technology trends arise – many managers who grew up with assembler had a hard time switching to structured C code, and the C managers had an equally hard time understanding object oriented design and design patterns and the like. That’s why one does have to keep refreshing one’s knowledge, at least at some sufficiently high level. You need to do this even in a large organization. While this requires careful time management and selectivity in terms of what to spend time on, I have often been amazed at the technical depth of very senior executives I have had the fortune to work with – while they may not know the details, they know the technical essence of their companies’ products and technologies very well indeed. And these are EVPs and CEOs of very large public companies. The key trick to learn from them is the importance of abstraction, and learning to figure out what level of detail is relevant, and what level is a distraction. Typically the amount of technical detail required for assessing opportunity and risk, and identifying baloney, is exactly the right amount at whatever scale you are working at. In fact, observing how someone who is good at this does it, is a great way of learning!

Career Implications

All our discussions show that there are considerable differences between managing a small startup and a large organization. As your career evolves you may get opportunities to experience both of these scenarios, particularly as your startup grows into something big. Different people may choose different responses to this situation, some enjoying bouncing back and forth, and others specializing in one or the other. In terms of your career progression, and finding the next job, your resume after a while will start to tell a story of some kind. For many people it will indicate that your preference is either to work only for small companies, or to work mostly for bigger ones. If you want to jump back and forth, you will need to go so some effort to show that you are well qualified and interested in working in both kinds of organizations. The practical challenge is after working in one kind of environment, remembering what the other is like. In a startup one can get away with quick and dirty solutions that would never scale; conversely in a large organization you can do things that are inconceivable in a smaller organization. On the other hand, the small organization will typically be capable of quick decisions and nimble moves not seen in their bigger brethren. Each of these scenarios requires different skill sets to be successful in. If you want to move from one environment to another, the best thing to do is to show that you have been successful in both kinds of environments are capable of succeeding in each.

Management versus leadership

Especially in larger teams it’s easy to let the urgent dominate the important. There are so many meetings to go to, simply managing day to day tactical objectives can be a full time job. But this is not generally sufficient for success at the VPE level. One needs to really own one’s business and be able to drive it strategically. This is the difference between management and leadership. Are you able to set the right objectives for your teams ? Do you understand how to make a difference for the business ?

In smaller teams this is even more crucial as there is no one else to fall back on – you are the technical leader, and if you can’t provide proper direction, then there will be no direction, with potentially disastrous consequences for the organization.

Note: This is an excerpt from “Leading and Managing in Silicon Valley“, a book co-authored by Sam Hahn and other VPEs.