“How do we keep up with building a high-quality engineering product and at the same time keep customers engaged and continuously deliver business impact?”

“While we build this feature, we want to spend a little time on strategic planning, experimenting to get directional correctness and paying Technical Debt.”

“We have been receiving this feedback very frequently that our team and product have very little to offer, often the impact of what we do is unclear and not effectively measured? Moral of the team is going low with such feedbacks.”

These are some of the common thoughts we keep hearing while working on a fast-paced product focused engineering team. In this post, I am trying to post some of my learnings over time to solve such problems.

Well, there would complex frameworks and exhaustive philosophies breaking above scenarios in less complicated ones and doing justice on a case by case basis. In different situations across products and domains, teams and leaders have grown to resolve these conflicts and strike out a balance towards success, while many have failed as well.

In my opinion, there’s no silver bullet, and solutions are very subjective but, It all cases making decisions, owning failures, and failing early has played a critical role.

Let’s try to break down the problem and understand the complexity to see what we can do, Shall we?

Continuous feedbacks are important, there is definitely something not right if stakeholders feel there is no much value add by the offerings we have built. There is a need for identifying impacts delivered on a frequent basis and establishing appropriate communication channels to bridge these gaps. This could also help double click into this kind of feedback and provide healthy iterative loops of improvements on Product Development.

Measurement is the key, measuring the right metrics for impact not just helps in creating visibility but also drives clarity of strategy and course correction.

Define objectives and focus on outcomes, most often measuring the outcomes is not possible without defining objectives and hence causing distractions and less satisfactory results further boiling down to low esteem inside and outside the team. Further to complicate the problem, the entire prioritization goes on a toss.

Objective Communications, bringing pain points forward is important to build a sustainable ecosystem, feedbacks are one way to establish that, regular checkpoints are another but it does not get resolved there. Communications need to be objective, present the information precisely, make every stakeholder aware of situations and complications so that the next set of actions could be in the right direction. Failing early and communicating the failures also works well for the greater good.

Prioritization and Bucketing Initiatives, There are always so many options and initiatives out there that can be tried out, experimented with, leading the product into different directions. Its a function of capacity and objectives how wide one should go, this is where prioritization based on well-defined objective can help.

OKRs are one of the most valuable tools in driving priorities. While that may or may not be the only source of work a team should pick up. A team should able to bucket the initiatives among strategic, quick wins or tactical moves and health measures so that there is a balance between long term and short term impact it can deliver.

  • Strategic Initiatives, are focused on long term goals. These initiatives drive the vision of the product and are a reflection of the direction the product is heading towards. Most of the time these are the major product features and interfaces we build, these should be well thought through and delivered with high quality. At the least, 50% of the team effort should go on defining, building, and improving these kinds of initiatives, while it is okay to drop quality to 80% creating some amount of payable tech debt in favor of showing value faster.
  • Quick wins and tactical moves, these are short term efforts focused to demonstrate immediate impact and calculated tactical moves to keep the strategy going. These are small but effective, low hanging, short-lived initiatives that can help to settle many customer feedbacks and blockers. At times these can help to get the team back on higher moral grounds. The objective of running tactical initiatives is to engage with customers better by solving their immediate needs, keeping all cross-functional groups independently operating, and provide the taste of continuous delivery to the team. It is important to not get drown in the loop created with short term gains and lose focus on strategic initiative hence, in a healthy state, no more than 40% of team effort should be on such initiatives.
  • Health measures, Paying back the tech debt on time is the most significant part of the health measures an engineering team should and need to take care of. For the most part, it is hard to demonstrate value out of health initiatives to all stakeholders but having metrics around reliability, customer experience and product growth treated as a first-class requirement should help the case. Managing health is a continuous effort, overdoing it does not help unless it is strategic. To strike out a balance, at the maximum 20% of team effort should be on health measures at a time.

Taking responsibilities of operations, most common but least cited problems in a product team is to always underestimate the sense of responsibility of operations causing major failures of a team. For a Product team, while building on strategic initiatives is important, keeping the operations going smoothly for what is available for customers is another key factor to build a trustworthy relationship. Operations are painful and sometimes not interesting but they can drive innovation and are owned by product teams that thrive quality of deliverables.

All hands on deck on failure

“sure, continuous feedbacks, communications, measurements, prioritization, bucketing, quick wins, balancing capacity everything looks fine but how do you manage the crisis? How do you get this healthy state balance?”

Yeah, this is where the awareness of pain points and acknowledgment of the problems within the team plays a very important role. This is when you need to get everyone to objectively agree to the core problems, building consensus, iterating over the solution together. Having shorter iteration loops within the team over a smaller but most critical piece of the problem and forking out parallelism as you build pace to a significant level seems to do the trick.

Well! if its a production downtime, you need all hands on deck if its a failure, you need all hands on deck to own it with an intent to rise again together as a team.