Reassess For R&D Success

Now more than ever, you can’t afford to settle for an average team. Draw the trend line: if things remain as they are, will that be enough for your company to obtain dramatic success? Time is of the essence, and therefore, I thought you might appreciate some help thinking about ways to assess how well your team is situated right now. Knowing that should equip you with the insights needed to determine where your focus should be in the upcoming months.

Having worked with hundreds of teams globally, there are several areas around which I gather information from clients to tell what their issues, strengths, and growth opportunities are. As you’re wrapping up this quarter and thinking about the rest of the year ahead, consider these different aspects of your organization. At the bottom of this article, you can grab a copy of my R&D Assessment Metrics Guide.


Don’t get me wrong. I think that I start half of my talks by stressing how important it is for successful tech teams to stop obsessing over merely delivering features on time. When that’s your only yardstick for success, your organization inevitably becomes a feature factory. Nevertheless, if you cannot deliver the important stuff reliably, we cannot begin discussing the next steps, right? No one cares about spotless code and incredibly positive employee surveys if the team never gets anything done.

When assessing your team’s delivery, consider basic health metrics such as DORA, cycle time, etc. It is crucial to realize how fast your teams deliver changes and where the bottlenecks are. Add to that the importance of realizing whether you suffer from severe quality issues, e.g., many changes resulting in outages.

Also, consider how iterations are spent. How many of the things you commit to are, in fact, regarded as done once the sprint is done? How much of your team’s time is regularly allocated to “keeping the lights on,” “tech debt,” “engineering backlog,” or whatever other name you have for it? A team that routinely allocates 20-30% of its time to tech debt is a team that quite likely has lost sight of the value it can introduce.


At the end of the day, your team is responsible for executing and getting things done. Many startups have had a rude awakening recently and realized their R&D teams are not aligned for profitable growth (more on that in my new book next quarter). A healthy product engineering organization should not be required to grow linearly with the business size merely to support growth. That means you must assess your current growth plans, the engineer-to-end-user ratio, and similar metrics.

Further, there’s the matter of simply running a healthy team. How does your average engineer pay compare to the industry average? What is your turnover and median employee tenure? How does morale look? Most importantly, are people growing? Improvement shouldn’t only happen due to increasing headcount but because the team is getting more effective with time. For example, what is your Peter Pan count?

Management Strength

Next on our list is the aspect of running your organization. Middle management in many startups nowadays is a complete mess. No real training. Every team operates differently. Rather than set up an aligned organization, you have a menagerie of developers. Assess the leadership skills of your managers. Are they up to par? Have you merely given them the title and expected them to spontaneously know what to do?

When it comes to the growth of your management team, do you have a solid “bench” for future growth or to account for inevitable turnover? Do you tend to always parachute managers externally? Only promote people from within the company? It’s better to strike a healthy balance instead of choosing one or the other.

Similarly, how many managers do you have in your company? You should aim for a healthy management overhead. Having too many micro teams makes little sense. Contrast that with mega teams that surely impinge on how coaching is taking place in the organization.


Last but definitely not least, you should consider how well your team is poised to drive dramatic impact. This is always harder to define as it changes between companies, but there are general areas you should consider.

First, how clear are the people on what’s important? Do you have a transparent strategy that was communicated succinctly to the team? Can they state what’s their group’s priority and why? Without this, they cannot correctly make the hundreds of micro-decisions that take place every day in engineering teams.

Then there’s understanding how much of a silo your team has created around it. What is the average level of product mastery in the team? Is the relationship with counterparts and stakeholders? For example, argumentative relationships between engineering and product are a clear sign that impact isn’t maximized.

The holy grail of tech impact is habitual innovation. Is the team’s creativity caged and freed for only two days a year during your hackathon? When was the last time that some creative idea which originated “bottom-up” became a full-fledged feature or product offering? I think the recent advances of AI have made many more aware of the value engineers can bring with ideas no one outside of tech can yet even grok. You can have that all over the place. Think how much your team has been proactive in this and how much of their effort is spent on “tech debt” instead of creating genuine value (grab an in-depth guide about this in the free sample chapter of my book, The Tech Executive Operating System).