VP Engineering Playbook

A practical guide for new leaders in software development

Tag: organization (page 1 of 2)

Agile Revisited

We recently celebrated the 15 year anniversary of the publishing of the Agile Manifesto.  As you’ll recall, in February 2001, 17 thought leaders in software development gathered in Utah to discuss better ways to build software. A set of values and principles were established which provided guidance for planning, building and releasing software. As agile evolved, several methodologies emerged to provide specific practices for the application of agile. Examples of these are Scrum, XP, Lean, Crystal, etc. These methodologies can be opinionated, but do provide companies with ready-made blueprints for structuring their agile programs.

At a few past companies, I have had the opportunity to craft software development processes that align with agile principals. In these cases, I haven’t utilized the strict application of a single methodology.  Rather, I have tried to mold the agile principals themselves into a set of practices that best match the culture of the target organization. Collaborating with other product stakeholders, this usually results in a unique interpretation of agile for that company. Since agile espouses introspection and continuous improvement, adaptation is natural.

Given the 15 year milestone, I thought it would be useful to revisit the values behind the agile manifesto and how those can be applied to a modern software delivery organization. This may be rudimentary to experienced agile practitioners, but might offer insights for new software development leaders charged with being “agile”.

Individuals and interactions over processes and tools

One of the core shifts introduced by agile was recognition that great software is produced by empowered individuals working closely together on small teams. This ran counter to the approach used by large organizations attempting to coordinate activities across hundreds of developers. In order to manage enormous teams, tools were championed that allowed disparate teams to schedule project work into sequences of events (Gantt charts) through desktop applications. With this move to formalized project management, teams stopped discussing the software in person and focused their effort on managing a tool.

Agile shifts this mentality back to individuals and their personal interactions. It encourages practices like the ones below.

  • Limit team size. Agile teams should be small (less than 10) and should include representatives from each function required to address the project work. For Internet apps, this means the product manager, UX/UI designer and engineers from each functional area (front-end, back-end, services, devops, etc.).  The key is that the team doesn’t have a major dependency on someone not part of the core team.  There can be other influencers, like from marketing or customer service, who participate as extended team members.
  • Colocation.  The core team should sit together. Physical proximity encourages high bandwidth collaboration. I realize that newer communication methods like IM and group chat facilitate non-spoken communication, but as humans, we are wired to rapidly broadcast information and gather feedback from non-verbal cues. As one of the agile principles states, “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” I am also a big proponent of fluid seating arrangements, where individuals can shift their seating based on their current agile team assignment. They may still have a “permanent” desk, but for the duration of their team assignment, they sit with the other members of the agile team.
  • Encourage informal discussions. I love to see the following situation. One member of an agile team has a question about a requirement. Then, one or more team members suggest they grab a conference room to discuss. The group heads to the room, closes the door and can be seen feverishly working out the problem on a white board. This occurrence stems from the agile concept that these types of informal, in-person communications should occur frequently during a project. These should not be categorized as interruptions and discouraged.
  • The team should have the proper environment, tools and support needed to accomplish their mission. In order to be self-empowered, the team should have full control over their work environment, the tools they use and necessary support from other teams. This is where engineering leadership can contribute to the team’s success. If you are a member of leadership (director, VP Eng, etc.), a big part of your job is to monitor your teams’ updates and identify any outside circumstances that might be creating impedance. These could be dependencies on other teams, difficulty getting their work environment set up or access to the right tools. Look for these obstacles and clear them.
  • Trust the team. If the team is staffed with empowered individuals armed with a clear direction, they should be able to accomplish their goals. As a member of leadership, you should trust that they can do this and get out of the way. Resist the temptation to tweak or guide. As long as expected outcomes are clear, maintain your role as an observer.

Agile anti-patterns:

  • Heavy emphasis on updating tools. On a functioning agile team, you should see a lot of informal discussion. The tools used to manage the agile process are useful for reflecting status, but are not a replacement for personal interactions.
  • Rushed meetings.  Over the last 10 years, I have seen a growing resistance to holding meetings. The observation has been that many companies load up employee schedules with so many meetings that they don’t have time to actually perform work. The knee-jerk reaction has been to question the value of all meetings or rush them in order to “get some time back”. Meetings, which I will simply define as a conversation between two or more persons at a pre-scheduled time, have a  purpose in an agile environment. They allow for necessary team member interactions to answer questions, review designs, plan work, or do anything that requires agreement. Allowing these discussions to occur at a scheduled time simply makes it easier for individuals to plan their day.  So, I think meetings are fine, as long as they are limited to necessary participants and produce an outcome. If you see meetings avoided or rushed, step back and determine if the team has a mechanism available to foster debate and make decisions.

Working software over comprehensive documentation

Another key tenet of agile development is to focus the team on delivering software versus waiting for a full set of requirements. Documentation is encouraged in agile. However, agile doesn’t gate the start of development on the completion of documentation. I still see this practice in some shops that profess the use of agile. If the developers wait until the requirements document is complete before they start coding, it will serialize the project and extend the end-to-end delivery schedule. Also, complete documentation is a farce. It is impossible for a product manager to anticipate every facet of a new feature. Many design decisions can be made at time of implementation.

An emphasis on working software provides other benefits in the form of agile practices for structuring work.

  • Break up large projects into incremental deliverables. Agile’s focus on delivering working software is the foundation for the convention of a sprint.  A sprint’s purpose is to time box project work, forcing segmentation of the overall project. Sprints should always include a release to production. This release can either be represented by many small features or portions of a very large feature.  Even if a large feature isn’t fully “live” at end of sprint, it is still important to conduct the release. Access to the feature can be limited to internal users by a feature flag. Each release forces integration and testing, spreading that cost over more cycles.
  • Track progress. Working software is the currency of a project – it provides a clear means of measuring progress. Work items in an agile sprint are usually organized into a burn down chart. This provides an advancing view of completed versus remaining work items. Remaining work should approach zero as the sprint proceeds. Delivering working software throughout the sprint provides the clearest way to validate progress.
  • Lower technical risk. As engineers plan their work items, they should address the technically hardest deliverables first. This allows the team to clear the biggest obstacles early in the project. Addressing these items in working software proves the feasibility of the solution.
  • Apply the simplest approach. Organizing project work into discrete deliverables released frequently encourages product and technical designs to be simple. In product design terms, this is often referred to as the minimum viable product. The value of a MVP is well understood. Until users provide real feedback, it is difficult to estimate the potential success of a new feature idea. Similarly, for infrastructure design, simplicity prevents over-engineering.  While sound technical design is critical to scalability and extensibility, trying to address future scenarios with extra technology capabilities can become wasted effort if those requirements never materialize.  As one of the agile principles states – “simplicity–the art of maximizing the amount of work not done–is essential.”

Agile anti-patterns:

  • Perfecting the design spec before sharing with engineering.  Teams may sometimes delay showing the design spec for a project to engineering until it is fully baked and signed off. The reasoning is that the team doesn’t want to waste engineer time by reviewing an incomplete spec. There is some credence to this, but I also think there is value in sharing a spec before it is complete. This allows the engineers to begin processing the future design – conceiving of improvements and planning their technical approach. Waiting until the spec is fully baked usually creates schedule pressure that limits feedback or negotiation of items that would lower delivery cost.

Customer collaboration over contract negotiation

Agile imbues the software development process with a strong emphasis on the end customer. For consumer applications delivered over the Internet, the end customer represents the millions of users of a company’s apps. Since it isn’t feasible to involve all these users in the software development process, we rely on the product manager to represent their feedback. In this model, the product manager is the customer. There are other customers to an agile project – like outside stakeholders. Even the core team members can be viewed as customers of agile.

Promoting a customer-centric view is critical to the agile process.

  • Conduct regular demos. Outside of the release at the end of a sprint, the team should strive for frequent, informal demos of their work. When a task is completed that can be “shown”, the responsible developer should grab the product manager and do a quick demo. The purpose of this is to solicit feedback as early as possible. Any time delay will increase the cost of making changes. Also, I like to see agile teams demo to each other periodically. One team I managed conducted “Demo Fridays”, where each team member showed what they had built the week before.
  • Speak in terms of customer goals. When the team conducts sprint planning, the product manager should lay out their objectives for the sprint in terms of end user benefits. Focusing the sprint outcomes on the customer allows everyone to align their tasks with what will have the most impact on the business.
  • Maintain a feature backlog that includes tech debt. Agile teams should construct a ready backlog of work items. These usually include feature ideas and product enhancements, prioritized in terms of expected impact. The feature backlog should also include tech debt tasks.  If you aren’t familiar with the term, tech debt represents work items that make future feature delivery faster, easier or more reliable. These are generally items sponsored by engineers that don’t contribute to the product’s feature set. They are important nonetheless, as they represent an investment in future delivery of the product. Teams can determine the appropriate mix for their situation, but I like to see at least 25% of available cycles in a sprint allocated towards tech debt.
  • Radiate information. Agile advocates public display of information related to the project. This could be UI designs, the burn down chart, database schema, system diagrams, or anything else that provides meaningful information to members of the team. This public display is generally done on the walls surrounding the team’s work area, using print-outs or monitors. Information radiators also have the added benefit of providing a convenient mechanism for presenting the team’s work to any visitors. Some teams I have managed publicized periodic “office hours”, encouraging other employees to drop by.

Agile anti-patterns:

  • Formal sign-offs. If you find members of the team requesting formal “sign-off” of delivered items, then the team may have a trust issue. Usually, this occurs at hand-off points in the process, like presenting product requirements or validating completed work items. If sign-off is requested, then the team likely is struggling with their ability to respond to change.
  • Only demoing UI features. Some teams think that only features with a user interface are worth demonstrating. In the spirit of delivering working software, any completed component of a project should be demoed. Even a back-end service with no interface or a database design can be presented. The key is that the developer shows the work to another person.

Responding to change over following a plan

In Internet time, the product landscape is constantly shifting. Yesterday’s great feature idea may no longer be viable today. Teams need to be able to adapt quickly and shift priorities to capitalize on new business opportunities as they emerge. The agile preference for responding to change allows this flexibility. While a plan is important, the team should orient around an expectation for change. As one of the agile principles states – “agile processes harness change for the customer’s competitive advantage.”

  • Prioritize sprint tasks based on expected impact. As agile teams plan their sprint work, they should schedule the highest priority items first. This also implies that if the priority of an active item changes, then its position on the sprint plan will be adjusted as well.
  • Daily stand-ups. One practice to ensure that team members are kept updated on changes to the schedule is the daily stand-up.  I like to keep these focused on the standard set of updates – what each team member accomplished yesterday, plans to address today and if they are blocked. These updates give the rest of the team a sense for the progress of other team members, and most importantly, where the schedule may be deviating from plan. Any issues raised during the individual updates can be addressed in smaller break-out discussions following the stand-up meeting. The stand-up meeting should be short, no more than 15 minutes.  However, enough time should be allowed for sufficient updates and treatment of any follow-up items. Occasionally, I have observed stand-ups being rushed, as if finishing a stand-up in under 5 minutes is an accomplishment.
  • Mid-sprint reviews.  As team members complete sprint tasks, these should be marked off in the sprint tracking tool. This progress against the schedule will be reflected in the burn down chart for the sprint. While progress can be tracked daily, I think it is a good practice for the team to formally review sprint progress at least once during the sprint. I like to do these check-ins mid-sprint, either at the end of a daily stand-up or in a scheduled meeting. The team should display the burn down chart on a shared monitor and discuss progress. Ideally, half the work items are completed at this point.  If not, the team should explore why and make adjustments to the plan for the second half of the sprint.
  • Retrospectives.  Another theme of agile is the notion of introspection and continuous improvement. The process by which the team works should be constantly reviewed using a reliable feedback loop. Retrospectives are formal meetings at the end of each sprint in which the team reflects on the sprint’s activities.  Discussion revolves around what went well and what needs improvement. This review should be conducted with an objective, blameless tone. For the items that need improvement, the team should identify actionable tasks to address them. Those tasks are then added to the backlog for future scheduling.

Agile anti-patterns:

  • No changes to the sprint plan as the sprint progresses. If the sprint plan always proceeds exactly as expected, then there is likely something wrong. The team should take advantage of the fluidity of agile to ensure that the most important work items are being addressed first.
  • Retrospectives with no improvement items. I have observed retrospectives for some teams narrow to a list of compliments between team members. Recognition is important, but retrospectives should also result in improvements. I like to see a 2:1 ratio of items that went well versus those that need improvement. This ensures there is space for recognition, but enough critical thinking to drive the team towards continuous improvement.

Leadership

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

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.

Behaviors

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.

Older posts