The R&D Manager vs. Organizational Waste: An Ecosystem at War
Leading a research and development (R&D) team involves many challenges and obstacles to overcome. There’s no better feeling than when your team’s work is going smoothly and everything is headed in the right direction. The team is happy, unified and everybody feels like they’re winning.
A significant part of management is dealing with unexpected problems, whether it’s an important client’s unplanned request or a new feature that competitors are now supporting. When this happens, as an R&D manager, protecting the team is often the first instinct. However, this often creates waste for the rest of the company. While you focus on your own team, you might neglect or overlook everything else. As R&D managers, we must be team players and understand the impact of protecting our teams and why doing so isn’t always the right answer. An R&D organization with a high velocity is amazing, but at what — or whose — expense? Is it really worthwhile creating deep technical debt and increasing the load on your company? Are you prepared to face the consequences?
R&D Time Is Precious
Your R&D team is the engine room that moves and pushes your company forward, whether by developing the next-generation product, innovating new products or fixing bugs. Engineers’ costs are rising and recruiting new engineers is becoming tremendously difficult everywhere. When your team’s time is so expensive and important, it’s natural to do everything in your power to make sure their time is spent most effectively and focused on mission-critical tasks.
The changes you usually make are within your own team, like minimizing meeting times, using the best tools and giving your team more independence to move forward fast. Meanwhile, you’re also making sure they’re working on the important tasks. I’ve discussed some of my views on how to minimize waste in your team, but what about the rest of the company? While you’re reducing the waste in your own team, are you by chance littering throughout your company?
We’re All in This Together
Since everybody understands that R&D time is precious, we see product managers, solution engineers, support engineers, sales, and those who don’t write code rise to help protect R&D time. We see this occur time and time again — I must say that it’s inspiring. The solution engineers who juggle numerous customers are eager and waiting for you to deliver those new features. They understand that R&D can’t fix all the bugs while delivering all the new shiny features that customers are waiting for. Our product managers, support engineers, and even our CEOs often become R&D’s first line of defense. They will push off bugs and unplanned tasks, saying “Don’t worry R&D, we’ve got this! Focus instead on those shiny features.”
Is this the right approach, though? How does this affect R&D? Will there be R&D prices to pay?
The Cost of Littering
Not cleaning up and throwing your waste outside of your team clears up a lot of time. Letting everybody else handle the waste has instant gratification, as you now have nothing stopping you from moving forward at lightning speed.
Let’s assume for the sake of this current discussion that everybody in your company is super patient, their motivation won’t drop as you’re throwing garbage at them and that they enjoy collecting your litter. If that’s the case, there’s no cost to the company. So let’s understand what the costs to your R&D team are when you litter.
Waiting for Everything to Blow up in Your Face
When you’re littering, you’re basically waiting for the garbage to pile up until you see it. For our purposes, that’s when those bugs pile up and your customers are tired of your support engineer suggesting a workaround. When you reach the point that you can’t even see the ground due to the level of garbage you’ve amassed, it will be the same time that you’ll have to get into the orange jumpsuit and be forced to clean everything. I don’t know about you, but I’d rather throw my garbage straight into the dumpster instead of getting on the floor to collect it. I’ve had the pleasure of trying both options and the latter is a nightmare. Fixing a bug here and there in between working on features is much easier than eventually having to work only on tons of bugs.
Some bugs also might affect other bugs, and even more crucial, some bugs might actually affect the features that you’ve developed. Crushing bugs once they appear is critical, as you don’t really know their true nature until you actually squash them.
For example, let’s say you’re building a new feature while assuming that your current code is properly handling stress and load. You’re going to have a big headache if you discover too late that it crumbles under load. Just like fires, extinguishing bugs early on is much easier than when there is too much smoke to even see the fire.
Workarounds that Keep on Giving
When a customer complains about a bug or an issue, your support engineer might offer great workarounds (e.g. did you try to turn it off and on?). What happens when those workarounds eventually become your customer’s routine? They might cause your customer to misuse your product, resulting in even more bug reports and even more feature requests to support those untravelled paths.
If this sounds like more work for future you, then yes, it’s exactly that.
The Data Won’t be There Forever
The existence of a bug usually involves two main protagonists: your code and the data it processes. Your code will be there forever, but that data causing the bug is slippery and volatile. If you postpone handling that bug, it means that you might be missing important data by the time you want to fix it. Those workarounds your customers adopted will stop creating the right data you’ll need to eradicate those bugs. You’ll have to dig back into your dusty logs archives, if they even exist, but you might have even not collected the right data.
Choking the Rollout Process
One of the commonly missed costs of R&D littering is the fact that you’ll be choking the rollout process. When developing a new feature, you need someone on the other side to receive it. Every company and organization has a different process of rolling out a new feature. The process to do so also depends on the type and complexity of the new feature. A standard feature will require the creation of proper documentation, a rollout with A/B testing, discussions to promote it with potential customers, support of it, writing feedback to R&D, bug reports (and the creation of workarounds), monetization of the feature, and so on. If the entire company is already busy with collecting your waste and cleaning up your littering, however, no one is rolling out the new feature. How will this affect your team?
Well, if there is nobody using your new feature, then you might as well not have developed it. Your team’s motivation will drop, and you won’t get any feedback on your new feature. You might as well go ahead and store it away in your attic. You could move ahead to develop your next feature, but since everybody is busy cleaning up after you, the product team didn’t work on your feature roadmap.
Oh, well, might as well just clean up your own litter.
Do It for Yourself
The main message I’m trying to point out here is that even if you’re a sociopath, which I’m sure you’re not, and don’t really care about others, you’ll still have to pay very big prices if you keep creating waste and throwing it anywhere outside of R&D. Like in all aspects of life, dealing with problems when they are small is easy, and ultimately no one wants to deal with them when they grow into disasters.