5 Things I Learned About Managing an R&D Team

I made the first developer I was ever in charge of want to quit programming. That was roughly over 15 years ago. I’d like to think I’ve improved over the years…

I think a key moment to that development was during the early years of my professional career. I was working at a big software company, spending probably 12+ hours a day at work and not getting enough done. A lot of my time was spent on solving bugs and problems for other team members rather than making actual progress on product features.

One day one of the team leads pulled me aside and told me that, rather than going around fixing problems I should tutor people so that they could be more efficient and hopefully solve these problems on their own.
“Your time is limited.”, he said, “You can get much more done if you start delegating”.

That was my first “management lesson”. It got me thinking beyond the code and architecture of a particular project, about the team behind it and how to get it working effectively.

Fast forward by a decade or so, I’m still in tech writing software. I’ve worked in teams, I’ve helped teams as a freelancer and I’ve built teams as a CTO.
Mainly, I had tons of chances to mess up… and learn…

5 Things I Learned About Managing an R&D Team  #

1. Let Go

Let go. You can’t do everything yourself. You have to learn how to delegate effectively and the first is letting go. When you become the bottleneck for decisions — your team becomes idle and unmotivated.

Developers turning managers often have trouble with this. It’s hard to pull back from the urge of doing everything yourself the way you see right, to trusting that responsibility to another person.
It’s also hard to factor out individual preferences when reviewing said work, to distinguish between “I would have done this differently” (usually “better” is there too) to “this is not done right and needs more work/rewrite/refactor/…”.

Recognize you can’t do everything. Close your eyes, fall backward, and learn to trust.
It’s worth it — you get much more stuff done, less pressure, and your team is better.

2. Be Agile

I worked at a company where they liked SCRUM. They really liked SCRUM. Everything had to be SCRUM. By the book. Every meeting, every procedure… to a point where it was counter-productive — you had to skew your development process to deliver SCRUM result.

You couldn’t, for example, split work between backend infrastructure and UI they’re separate systems requiring a different focus.
In SCRUM, “each sprint is required to deliver a potentially shippable product increment” which means you need to demo some half-assed “product” to a product owner (who represents a customer that doesn’t care about backend infrastructure and just wants his dashboards) on every iteration.
A team could not concentrate on having a solid backend before crafting a UI, it had to do both at the same time to meet the sprint requirements.

These guys were 100% “Agile”, but still missing on deadlines, under-delivering and burning out due to their process’s inefficiency.

By now you’re probably reading this story and saying to yourself “They just didn’t get SCRUM right”. Which is exactly the point — what’s “right”? who decides? is it the holy texts of some Book of Agile?

As a development manager, the #1 thing that should be on your mind is *“What can we change in the what we’re doing to be better?” *There was no one there asking this simple question.

There’s a subtle difference between doing agile, which is the simple practice of some methodology, and being agile which is outcome-oriented and feedback driven.

Be agile.
The process is not set in stone. It’s there to be personalized and constantly be tweaked & changed… You have to constantly adjust how things are done according to team feedbacks and lessons learned to keep it as an asset rather than a burden.

3. Run Efficient Meetings

Most meetings are crowded and inefficient. A lot of time is wasted on ops (scheduling and getting people in the meeting) and on syncing everyone up-to-speed which rarely leaves time to actually discussing actionable items and making a decision (which is also why meetings tend to stretch beyond their schedule).

Don’t waste time syncing people. Have that information ready beforehand so that people come ready.

Use tools like Monday.com and Slack to write ad-hoc updates. This way anyone can catch up on relevant topics without being called into a meeting. When people attend a meeting when they’re prepared you can skip the prolog and go straight to the issues at hand. For example: Weekly meetings can skip summarizing what everyone did the past week and focus on planning the next week.

The use of ad-hoc updates opens your organization’s information to more people than you would normally call into a meeting or add to an email thread. It also allows people to catch up on their own schedule. I’ve found people tend to be more up-to-date and engaged this way plus you get the benefit of not wasting time in meetings. So why not?

4. Streamline the R&D process!

The R&D processes and infrastructure are the heart of the team. If deploying a new release is hard — each new release will be a nightmare. If writing tests is complex — developer won’t write them, or waste a lot of time and effort on them (and be miserable writing the few tests they do write) and in any case, you’ll end up with miserable developers chasing your own tail with bugs on each release. If you don’t have proper monitoring and logging infrastructure you’re flying blind into combat…

Development Infrastructure requires constant care and incremental work. It’s also something most people outside R&D can’t really understand and appreciate… It’s your job to protect and grow it.

(Also… automate. automate. automate.)

5. People — just know your team’s strengths, weaknesses, and goals

A development team is somewhat like a sports team. It’s members each have their own strengths and weaknesses that you have to know and use. They also have their own personal goals.

… The reason these teams have been able to remain consistent winners despite high personnel turnover is that they have been able to combine a realistic view of the often temporary nature of the employment relationship with a focus on shared goals and long-term personal relationships.

Finding those shared goals is and working on them helps keeps you both engaged and motivated. When good people don’t feel like their moving forward with their own goals they lose motivation and eventually leave. It’s also great for hiring 😉