VP Engineering Playbook

A practical guide for new leaders in software development

Category: Organization (page 1 of 2)


I was recently asked about my leadership style. This got me thinking about what leadership traits are exercised as a VP of Engineering. My leadership style is heavily influenced by my early experience as an officer in the U.S. Army.  The military invests a lot of effort in the training of its young officers. This is because one’s first job as a second lieutenant in the Army is to lead a platoon of up to 50 soldiers. This requires you to develop and hone your leadership style very quickly. The leadership skills I learned in the Army carried forward to my professional career.  I have since refined these and added some new ones over time.

As this blog is targeted at individuals in the VP of Engineering role, I thought it would be useful to share the leadership traits I have leveraged. This should hopefully provide guidance to other developing engineering leaders. Keep in mind that there are many approaches to leadership and no right answers. I offer this perspective to spark your thinking about what’s important for you.


Skills represent the primary practices you will focus on as a VP of Engineering. Executing these will occupy over 90% of your time. These practices should influence outcomes for your role over the long term.

  • Project a vision. A clear vision will provide direction for every decision that your organization will make. It should align teams and reduce friction. To form your vision,  contemplate how the organization can leverage technology to meet its business objectives. Are your product offerings taking full advantage of what is technically possible? Is there a better infrastructure architecture that allows your service to be built faster or delivered more reliably? Are your developers equipped with the optimal tools and frameworks to do their jobs? As you think through these questions, you should form a vision of the ideal state of your operation and what would be required to achieve it. Describe this to your team. Does it excite them? It should. Compare your vision to the current state.  Form a plan to move towards the vision. Break it down into measurable steps. Consider the risks to your plan and mechanisms to mitigate them. Armed with your plan, communicate it to the team and drive towards the vision. Encourage team members as they execute. Advocate for them to ensure they are properly resourced and supported.  Make adjustments to the plan as you move forward. The key to vision is that you identify improvements made possible by technology and lead your team towards them.
  • Build teams. As a VP of Engineering, one of your main responsibilities is to build a highly productive team of motivated engineers who are able to deliver an industry-leading product. Building teams starts with selecting the right people. You should assess their individual strengths and align those with the right roles. You are also responsible for establishing the organization’s culture. I talked about how to build culture in a past blog post.  Culture basically comes down to how you build success into your team. Employees want to be part of a winning team – your culture provides the practices and behaviors that allows them to win. Team building also involves structuring the engineering group into small, nimble teams that can operate autonomously. Identify young leaders and mentor them into team lead roles.  Promote continuous improvement and introspection.
  • Establish systems. As your teams grow, it will become increasingly difficult to maintain standards for how they perform work. This is where systems come into play. Systems represent the processes and practices your organization uses repetitively to design, schedule, implement and verify software development deliverables. Working with your peers in the product organization, you should establish the processes for this. You can borrow from agile methodologies.  In establishing agile software development practices in past roles, I haven’t embraced a single method (scrum, xp, etc.) wholeheartedly, but rather borrowed the principals themselves and applied those to the unique characteristics of the organization.  Examples of agile practices cover many areas – gathering requirements, planning work, scheduling tasks, tracking progress, providing updates, etc. Tactically, these can represent everything from daily stand-ups to retrospectives.
  • Infuse accountability.  While we all strive to build self-directed, independent teams, I think that individuals function best when lines of ownership and expectations are clear. In the Army, this is ingrained from the division level all the way down to the squad. Leadership identifies who is in charge of what and how success will be measured.  This allows an organization of a million people to function cohesively.  Even with all of this top down control, there is still plenty of room for individuals to take the initiative and be creative in the execution of their roles. The same approach can be applied to a software engineering organization. Define who is responsible for each function and how performance will be measured. Success should be cast in the form of expected outcomes, allowing individuals to determine for themselves how to achieve their goals.  Additionally, as the leader of the team, you should provide the example for personal accountability.  This means you take responsibility when the team falls short of objectives. After you demonstrate this approach to accountability, you will notice that your attitude will trickle down to the rest of your leadership roles.  Accountability doesn’t just apply to negative outcomes.  You should praise team members when they succeed, as well.
  • Practice diplomacy: The skills presented to this point have been primarily focused on the engineering group’s internal operations. It is also important to build productive relationships outside of engineering with other executives.  This allows engineering to contribute its part to achieve common company goals and initiatives. Most people define diplomacy as the behaviors two leaders exhibit during formal meetings.  They think of social graces, like being polite.  I think that diplomacy is deeper than this and is grounded in the research that occurs well before the interaction. This research involves a full understanding of the other leader’s organization and what they are trying to accomplish. Similarly, you should build a thorough understanding of how the engineering group fits into the overall company. What are the other departments, how do they function and what are their key objectives? What are the interaction points between engineering and other departments? In a technology company, peer departments are often product management, marketing, customer service and operations. Similar to the exercise you conducted internally for engineering, figure out the vision, structure, systems and accountability measures for these other departments. Then, strive to build relationships with the leaders of these teams. Know their challenges, hopes and dreams. This perspective will help you negotiate the inevitable disagreements that arise as your teams work together. This knowledge is the key to finding common ground and surfacing “win win” outcomes.


In addition to leadership skills, there are a set of behaviors that should guide you. These are less about achieving a particular long-term outcome, but rather influence your actions daily.

  • Decisiveness. Make decisions quickly with the information available. As the VP of Engineering, you will be presented with many decisions. If you delay them all for more input, your team’s execution will slow down. You will never get all the information you want to make a 100% accurate decision. Have the confidence to evaluate options and make a call. Trust your gut. You can change your mind and alter direction, when new information presents itself.
  • Integrity. Integrity goes far beyond just being honest. It means doing what you say you will. Provide an example for others to emulate. Lead by example. Given the high expectations you set for your organization, integrity requires that you exceed the same standard yourself. Don’t expect your team to do something you wouldn’t do yourself. If you ask them to work late to meet a deadline or address an outage, then you had better be there too.
  • Composure. The VP of Engineering role can be very stressful. As the leader, how you act under stress trickles through the organization.  Being the VP doesn’t give you the license to act differently. If you are calm and collected during difficult circumstances, then the rest of the organization will feel your confidence and act accordingly.
  • Dedication. In a start-up, you are pushed to obtain exceptional results. You have to be willing to put in the time and effort necessary to achieve your goals. This can require you to get your hands dirty and do tasks sometimes outside of your scope. It can also require your attention when you least want to give it. Granted, we can all try to “work smarter”, but there will be situations where just grinding through a problem is required. Dedication provides the grit to get through these situations.
  • Drive. In this context, drive represents a strong determination to continuously improve and raise the bar of performance. It’s about maintaining a “can do” attitude and projecting the energy that makes everyone strive to push themselves that much more.
  • Curiosity. Have an insatiable appetite for learning. You always want to understand how solutions work and if there is a better way. You should be an active gatherer of information about your trade – regularly consume blogs, podcasts, books, tech talks, etc. I have found podcasts to be very helpful – you can listen to them at the gym or during your commute. As an example, I have been listening to Software Engineering Daily recently.
  • Proactivity. Take the initiative to solve a problem, seize an opportunity or address an issue. As a member of your company’s executive team, you will rarely be told what to do. You have to fill in the blanks. This means understanding what the company wants to accomplish and taking the initiative to direct your team towards what is needed.

Hopefully, this article provided some insight into how to approach the VP of Engineering role.  If you have other suggestions, please post them in the comments.

Relationship Building Tips for Product Managers and Engineering Leads

In past roles, I have spent a lot of time structuring relationships between product and engineering teams. This primarily focuses on establishing practices for planning, scheduling and communicating development work. As teams interact, individual relationships between product and engineering team members can sometimes break down. In these cases, I find myself listening to each side’s perspective, digging into problem areas and coaching people to more productive interactions. Given this experience, I thought it would be useful to share some tips for maintaining a healthy relationship between product and engineering leaders. To be most practical, I’ll focus on product managers and engineering leads at the small team level, where the business context is delivering software products over the Internet at a rapidly growing company.

For the Product Manager

  • Address why – not just what. When you are asking your engineering team to build a new product feature, take the time to explain why it is important. What are your goals for the feature and how do these fit into the overall objectives for the product? Explain how the feature will improve the user experience. If you haven’t reviewed key product tracking metrics with your engineering team, step back and schedule some time to do this. Understanding the business objectives for a product enhancement provides two benefits for engineers. First, they can use their judgment to answer small design questions for themselves, obviating the need to ping you incessantly about the product spec. Second, engineers like to solve problems. If a user engagement opportunity is presented as a problem (we would like to increase the user registration rate by 20% by adding Facebook auth integration), then engineers will be more aligned with how their work contributes to the product’s success. After launch, they can track the impact of the new feature and help optimize performance based on data.
  • Design the minimum viable product. This means investing the smallest amount of engineering effort necessary to get sufficient feedback from users to make a decision about a product feature. MVP may be a well-known product design concept, but I sometimes see it failing in practice. Product managers and UX designers naturally get excited about the potential for a new feature that is bound to delight users.  This can lead to a tendency to over-design. Once the feature is launched, however, users may not engage with it and it is promptly turned off. This reaction is often spun positively as “failing fast”. Failing fast is fine, but if the failed feature required multiple sprints to build, then there may have been wasted engineering cycles. Engineers get frustrated by waste and dislike writing a lot of “throw away” code. Building and testing a MVP can minimize the discarded effort. As an example, if the new feature idea is to provide users with free use of the product in exchange for friend referrals, think about the easiest way to determine if users would be willing to make this exchange. I have been involved in elaborate implementations of a friend referral feature, only to find out after launch that users aren’t interested in referring their friends to some product types. Instead of building out the full referral feature, perhaps sufficient feedback could be collected by just displaying a button describing the offer. While the button would need to link to some sort of “coming soon” landing page, it would quickly indicate interest in that kind of offer.
  • Share design changes as early as possible.  After you deliver a spec for a new product feature, engineering will begin the process of conducting their technical design and implementation. From that point forward, engineers subconsciously expect the spec to be fixed. However, in a rapidly evolving product space, new information about the feasibility of a product direction manifests every day. This is understandable. If new information will alter the design for the product feature, you should bring this information to your engineering lead as soon as possible. Even if you haven’t determined the extent of the changes, it’s best to still share the possibility of a change. Take the time to explain the new information and your rationale for the re-design. This allows the engineering lead to assume ownership for it with his team. With the anticipated change, the lead can adjust the feature implementation steps appropriately. Best case, the design change won’t impact the delivery schedule because the lead is able re-order implementation tasks around the changing part.
  • Understand implementation schedule trade-offs and don’t always pick the option with the shortest delivery time. Your engineering lead should prepare a couple of implementation trade-offs as they scope out your product feature request. Usually, these trade-offs involve technology choices and software design decisions, where there is a “fast way” and a “right way”. In most cases, the right way invests effort now to make future development of the product feature easier. Examples are moving some supporting code into a shared library, or building the feature on a different technology. If not addressed now, these items will be addressed in the future and collect as “tech debt”. As a product manager, your tendency may be to always pick the implementation option that results in the shortest delivery time. However, if the schedule will allow for some cycles to address the tech debt items now, they will generally be completed faster. This is because the team is already in context and won’t need to incur refresh cycles on past code. Regardless of your decision, ensure that you fully understand and evaluate the implementation trade-offs. You and your engineering lead should collectively agree on the best option based on your product objectives. If tech debt is generated by your decision, ensure that you backlog it and offer to schedule it during a future sprint planning exercise.
  • Share your product roadmap and solicit feedback from engineering. If you maintain a product roadmap, share this with your engineering team. Granted, your roadmap’s planning window may short, like a couple of months. That’s okay – even seeing a backlog of feature ideas is helpful. Sharing the product roadmap allows engineers to make technology design decisions with your future direction in mind. When done well, this can reduce implementation effort for new features, because an engineer is armed with the foresight to build extensions into a related code module or service. Also, as you share the feature backlog, it is productive to solicit feedback from your engineering team. As builders, and often users of the product, they may have additional insights into usability. Engineers can be a great source of product ideas, or suggest tweaks to an existing design that may result in a better outcome.

For the Engineering Lead

  • Think of your product manager as a customer. While your product manager technically is a peer, it is productive consider your product manager as a customer of your engineering team’s services. In essence, they are generating a product design request and hiring your team to build it. An analogy would be if they outsourced development to a consulting company. If you were the lead consultant, how would that change your interactions with the product manager? Would you be more collaborative, responsive or proactive? While not perfect, I have found that this kind of relationship modeling helps align the engineering team with the product manager’s expectations.
  • Understand the business and your product’s key measures. Given that your company is inherently a business, it is crucial that you understand how the company generates revenue from its products. This is usually translated by the product team into a set of key metrics that indicate the success of the product. As the engineering lead, it is important that you understand these metrics and how your team can impact them. Fortunately, your product manager is well versed in these metrics and makes all decisions based upon them. Make an effort to learn about these metrics and get your hands on whatever reporting system the product manager uses to track them. This way, you can understand what the product manager is trying to accomplish with feature requests. Additionally, you can quickly identify when key metrics are negatively affected by a change. Aligning with your product manager on this shared scoreboard will streamline decision making for you both.
  • Do not obfuscate implementation schedules. When presenting a proposed delivery schedule for a project to your product manager, be specific. Explain the details of your plan. Review your assumptions and highlight risks to project milestones. If you have added time to allow for unknowns, delineate these items and share your methodology.
  • Provide implementation trade-offs. An implementation plan will invariably have some trade-offs. Usually, these take the form of work items that could be deferred in order to reduce the timeline for launch of the feature. Granted, these deferred items will need to be addressed eventually, but it’s also possible that the feature may not resonate with users and be discarded. Therefore, it is important to include these trade-offs in your implementation proposal. Trade-offs should address both the anticipated schedule reduction and the “cost” of deferring the work. For example, if conducting a load test of the new product feature is part of your plan, you can describe the risks of launching without it. Alternately, if you wanted to bundle some of the business logic into a new micro-service, explain the benefits (future maintenance cost reduction) of that work. Then, review your implementation plan and trade-offs with your product manager. If work items are deferred, make sure these are added to your tech debt backlog.
  • Explain the technology. Educate your product manager on the technology that your solution utilizes. Don’t assume they won’t understand. Many product managers (like at Google) have an engineering background. This education can be done in one-on-ones, at lunch-and-learn sessions, or during monthly group all-hands meetings. The more your product manager knows about the technology, the better equipped they will be to appreciate the benefits of non-feature development work.  
  • Share bad news early and in person. If there is a new circumstance that would be considered “bad” by your product manager, share that as soon as possible. Bad news could represent a setback in the implementation plan, an undiscovered bug, a team member change, or anything else that might effect your product manager’s goals. This news should be discussed in person. Don’t postpone it for a team planning meeting, or include it in an email. A big part of relationship building is interpersonal communication. In your discussion, share the update and options to address it. If you and the product manager are not in the same office, communicate via a phone call or better yet, a video conference.

Danger Areas

  • Lack of trust. Loss of trust between a product manager and an engineering lead can be devastating. Like with any relationship, trust is foundational. Think of your product manager or engineering lead as a significant other. Do not speak in a way or do something that would undermine this relationship. Examples include prevaricating, withholding information, disparaging or double-dealing. Evidence of lack of trust might be if a product manager has little confidence in  delivery schedules or an engineering lead openly criticizes feature choices.
  • Poor communication. The product manager and engineering lead should be joined at the hip. They should be communicating frequently and informally. Ideally, they sit together. They should both be comfortable in talking to each other, without the need to be guarded. Strained or sporadic communication should be flagged.
  • Timidity – inability to push back. Like a marriage, it is not healthy if one partner dominates all interactions and always gets their way. Both the product manager and engineering lead should have the confidence and fortitude to push back if they have issue with the other’s actions. Conflict is healthy and usually leads to better outcomes.

I’m sure there is much more advice on this topic, but I will try to keep this article reasonably short. If you have additional suggestions, please post them in the comments.

Improving Engineer Retention

As the VP of Engineering at a rapidly growing software company, one of your primary responsibilities is to build your engineering team. Initially, this is primarily a recruiting function. As your team expands, though, you want to ensure that the engineers you have hired stay with the company. There is nothing more costly to organizational development than to have a new engineer leave after 6 months.

Granted, you shouldn’t expect engineers to stay on your team forever. I think a good target in a competitive hiring market is four years.  Beyond four years at a company, an engineer will start to feel that there is an opportunity cost to remaining. Outside recruiters will reinforce this perception, as they dangle other offers in front of the engineer and warn them about being pigeonholed.

The way I measure retention is based on the number of employees who voluntarily depart the company in a trailing 12 month period as a percentage of total employees. I don’t include terminations in this number. As an example, if you have 100 engineers on the team, and 50 quit in the last year, then you have a 50% retention rate. Using the four year engineer longevity target, then a good retention rate is 75%. Of course, you can strive for higher than this, and may do so occasionally. I passed the 80% retention rate during one 12 month period at a pre-IPO company in San Francisco. But, that isn’t sustainable over the long term in a tight hiring market.

In this post, I will offer some tactics to improve your engineering team’s retention levels.

Company Mission

First, we should consider engineers as employees. Think of why an employee would want to work for your company. Often it boils down to your company’s mission and how that contributes to the greater good. Is the company delivering a product or service that benefits other people or makes the world a better place? Is it something that employees can feel passionate about? Most companies have a compelling mission, or they wouldn’t be in business. You want to articulate your company’s mission in a way that excites your employees. Generally, the marketing or HR team will have this messaging worked out and available in presentable sound bytes. You should promote it to new hires and reinforce the message during group meetings.

As an example, at Zoosk, where I led engineering for several years, we went through this process. On the surface, Zoosk could be described as a dating app. The service allows individuals to discover and communicate with other members, often resulting in a date. However, after receiving notes of gratitude from married couples, we realized that our mission was broader than helping members get a date. Zoosk helps people find their life partner, perhaps the most significant event of their lives. Painted in this way, it was very easy to embrace the mission of the company. We reinforced that mission through internal company messaging. We even printed photos of happy couples with the text of their testimonials, and posted them on the office walls for all employees to see.

As another example, you may have noticed GE’s latest ad campaign in which a developer describes getting a job at GE, which will allow him to write software that makes hospitals run more efficiently.  This is contrasted with another developer’s job at “Zazzies”, where his app puts fruit hats on animals. The point is clear – that developers, as employees, want to work somewhere in which they feel their contribution has a positive impact.

Company Progress against Goals

Employees want to see that their company is moving forward. This measure of forward motion is usually represented as progress against goals. Engineers generally care about two types of goals – product usage and company financials.

Product usage goals reflect the number of users of a product and the activities they perform.  Examples might be user sessions per day, messages sent, photos uploaded, items purchased, etc. Engineers like to work on a product that is being used, as it gives meaning to their work. They also like to take ownership over the performance of their product – having frequent updates on performance against goals is very motivating.

Another significant set of metrics is the company’s financials.  These represent items like revenue, expenses, income, etc. Financial metrics are important because they provide feedback on whether the company is viable as a business. Engineers care about these because they want to work at a successful company. Also, they generally will have an equity stake in the company and want to ensure their equity will be worth more in the future.

For these reasons, I think it is important to share product usage metrics and financial results with the engineering team. I realize this requires a bit more trust than some companies are comfortable with, but the transparency goes a long way. If the company is exceeding all of its goals, that’s great. The team will be very excited. If the company is not meeting its goals, then you have the opportunity to provide perspective on why and how the company will fix that. Engineers are generally solution-oriented. By sharing the company’s challenges with them, I often find that they will make suggestions. Even if these aren’t good ideas, problem solving reflects positive thinking, which is good for morale.

You can share these product and financial metrics at team meetings. I usually summarize them at quarterly engineering all-hands. For timely updates, though, I will grab 5 minutes at the end of recurring team meetings, like sprint retrospectives or even stand-ups. This openness is very important and the engineers will appreciate the candor. I realize that a publicly traded company can’t disclose detailed financials regularly outside of the quarterly reporting cycle. If that is the case, at least try to spend some time reviewing the financial information after it is public. If your company is private, then I would share as much as possible, with the appropriate admonitions to not disclose the information outside the company.

Engineering Team Culture

Much is made about building engineering team culture in our industry. A lot of that focus is often on social factors, like having a “no a-holes” policy, providing snacks or encouraging participation in volunteer activities. I think building a strong engineering culture is more foundational. Like any team in a competitive space, the participants want to feel like they are “winning”. While we don’t have direct competitions between engineering teams at technology companies, a measure of “winning” can at least be translated into doing work that is noteworthy in the industry.

Having a “winning” culture means that the team is continually pushing itself to be better. They are looking for new ways to solve problems – better technology, improved process, skills development, etc. Working towards being better will ultimately lead to a sense of pride. And if your engineers feel proud of what they do, that will be a strong driver of culture.

Here are some ideas to build culture:

  • Continuous improvement. Encourage activities that focus on making improvements to your team’s processes, infrastructure and capabilities.  Conduct retrospectives.  Relentlessly ask if there is a better way to accomplish a task.
  • Encourage automation. The enemy of continuous improvement is complacency. One way to become complacent is to fill available development time with repetitive tasks. By automating those, time is freed up to find new ways to improve.
  • Promote yourself. You can reinforce the drive for continuous improvement by promoting the team’s accomplishments in your industry.  One output for this is through an engineering team blog. Most progressive Internet based companies have active and insightful engineering blogs. See UberSpotify and Airbnb for examples. The engineering blog provides a medium for team members to share technology accomplishments and best practices with the rest of the industry. This naturally drives improvement – if your team doesn’t have anything worth promoting to the industry, then it isn’t doing anything remarkable. Additionally, encourage your team members to speak at relevant conferences and allocate time for them to prepare. Landing a speaking engagement at a popular technology conference can generate a lot of visibility.
  • Support open source efforts. Make contributions to open source projects, or start a new one. This shows that your engineering team is advanced enough to improve the state of shared industry solutions.
  • Share wins. When an engineer accomplishes something notable, you should broadcast that to the rest of the team. This reinforces the positive behavior throughout the organization. Further, it makes the engineer feel good about what they accomplished and want to do more of it.

Professional Development

Probably the most important factor for an engineer’s job satisfaction is their professional development.  As an artisan, good software engineers value the ability to improve their skill set. This makes them more valuable in the workforce and satisfies their desire to expand their knowledge. Here are some ideas to provide engineers with professional development opportunities:

  • Training. Encourage your team members to find training opportunities that interest them and pay for these. Training can take the many forms – a 3-5 day intensive course on a particular technology or an evening class at a local university. Many of these programs are offered online.
  • Conferences. Similar to training, let your engineers attend relevant conferences. These are usually associated with the technology they focus on. Conference attendance may require travel. The company should pay for this. I usually budget for one conference for each engineer a year. I offer to pay for more than one conference if an engineer lands a speaker role.
  • Team rotations. Based on how your teams are structured, allow engineers to rotate onto different teams. This gives them exposure to new technologies and products. Rotations can be done for a short duration, like a quarter. You will want to manage the number of concurrent rotations so that productivity isn’t severely impacted by the associated ramp up.
  • Hackathons.  Conducting hackathons allows engineers to experiment with new technologies and try out product ideas. Most companies structure these as a 1-3 day event where engineers form teams and work on a new idea. I like to keep ideas focused on one of two areas – either a product feature or a productivity improvement. The teams should produce a working prototype. Ideas are then demo’ed at the end of the hackathon and prizes are awarded to the top teams. Many good product ideas will come out of these hackathons and the teams really enjoy the experience. I try to conduct at least 2 hackathons a year.
  • Independent work. Google’s 10% time is a well-known practice. I have cast this concept as “tech time” at other organizations. The idea is to allocate some regular time window for engineers to work on a technology problem outside of their normal sprint development tasks. I usually make this optional for engineers, but request that they document their independent work on a shared medium if they participate. Often this independent work allows the engineer to experiment with a new technology on their own schedule, resulting in more approaches for solving problems.
  • Feedback. Your company’s formal employee review process should include productive mechanisms to give feedback. I often try to go beyond this and ensure that managers give engineers feedback on their performance regularly. Weekly one-on-one’s are a good vehicle for this. Providing frequent, timely feedback to an engineer helps them improve.


Finally, we get to compensation. Most good engineers view compensation as being important to their decision to join or stay with a company, but it isn’t the strongest decider. My experience is that engineers need to feel that they are compensated fairly relative to their peers in the industry, but will give a company latitude if the other retention criteria are strong. I am an advocate of paying engineers generously, as the leverage that a skilled, satisfied engineer can create is immense. If budget is exerting pressure on compensation levels, then ensure that the salary for an engineer is at least within 10% of the average for your industry and company size. Your HR team can get access to data showing compensation levels by job type and location. I have used Radford for this in the past. Don’t try to get away with significantly underpaying your engineers. They will figure it out, and leave for other higher-paying companies.

Older posts