On Working With the R&D

Aside from your boss, the guys from the R&D are probably your most important peers.

Whether you are working directly with the CTO, VP R&D or ‘merely’ the team-leader – this relationship is one of the most precious one in your day-2-day job.

 

Let’s face it – if you fail to establish a good relationship with your fellows from the R&D you are probably useless to your company, no matter how talented you are on the product aspects. Yes, that’s harsh, but it’s also the truth. 

The R&D is your ‘execution arm’. They make your dreams happen. Therefore, if your ‘execution arm’ is not executing upon your dreams – then the whole group is not producing anything to move the company forward.

 

But let’s not be so dramatic. After all – the good news is that among all the roles in your company – the R&D guys are probably the guys who will be the easiest to work with. They are less ‘political’ in nature. Hence, they are less likely to seek power & control and for most of the time – they just want to build great things! You can and you should certainly work with that.

 

What does the R&D need from you?

The key things you must provide your fellows from the R&D are:

1. Work items – in the form of product specifications
2. Priorities
3. Protection from overload
4. Protection from noise

 

Work Items & Priorities

Bullets #1 and #2 are quite obvious, so I won’t devote much time on those.

I will just note that in order to maintain a good relationship – your product specifications must be clear and on the ‘right level’ of detail. Not too visionary on one hand, and not delving into the ‘how’ and technicalities on the other hand. I touched on it a bit here and I intend to devote more time to this in future posts.

 

Priorities must also be very clear and follow a consistent logic. The healthiest approach (as almost always) is to stick to the company’s KPI and prioritize according to what moves the needle in that regard. That would be the easiest to explain and holds the secondary, but important value, of getting everyone familiar with the KPIs that drive the business forward.

You also need to make sure you leave room for prioritizing tech-debt items that originate from the R&D (see more below).

 

Protection from Overload

Something that may be less obvious is what I call ‘protection from overload’. As I see it – it’s your duty to protect your R&D fellows from taking too many commitments on themselves. You will need to do most of the negotiations about the quarterly plans and sometimes even the sprints – on their behalf. The engineers & developers may not feel comfortable to turn down various tasks from the executive teams and may be willing to work overtime to meet a plan that doesn’t make sense (in terms of workload) in the first place.

You may wonder quietly – “well, if they are willing to work hard – why should I stop them?”

Two things:

1. First, I’m not asking you to stop them. If they already accepted the commitment and are working hard to meet it – let them. Meeting commitments possesses a great value on its own. Will elaborate on this below.
2. I’m asking you to prevent such scenarios in the first place. E.g. – don’t even bring the decision to the doorstep of the R&D. If various people in your organization are asking for too much – you need to explain it to them and either bury it or postpone it.

 

But why?

I believe that stress periods are fine from time to time, but not as the day-2-day reality of a company. If the R&D guys are constantly working extended hours – then they will get burned and eventually leave OR maybe even worse – keep writing code which slowly degrades in its quality and introduces more instability into the system.

You don’t want any of the two options above.

 

More important than the risk of developers churn or writing a crappy code lies the risk of not taking commitments seriously. If you push too much work towards the developers – eventually they’ll start to miss deadlines, and for justified reasons (you were asking for too much). Missing deadlines over and over teaches everyone that commitments are not that sacred and nothing bad will happen if they are not wet. 

This is one of the worst outcomes you can have as a state of mind of the developers.

Therefore, help prevent this.

 

Protection from noise

Protection from noise is actually a protection from context switches.

The worst thing for developers & engineers is context switching. It kills productivity.

It’s totally in your hand to support this. How? You can do so on several levels:

1. Keep the sprints immutable. Don’t let anyone add working items to the sprint once it’s finalized. The only exception – production issues which may risk customers churn or loss of revenues. Everything happens on ‘the next sprint’. The ‘next sprint’ will and should become a common phrase in the hallways.
2. Plans the meetings. Don’t invite developers to your meetings unless the specific person is really needed. If you are unsure who should attend – invite the team leader and ask him to add the essential people. Try to put all or most of the meetings on the same day and adjacent to each other as much as possible. I’m talking about meetings which involve developers.
3. Talk to the team leader rather than the developers. Each time you write them on Slack – it’s a context switch. Hence, if possible – talk to the team leader. 

If you stick to the above you will see that you are starting to gain the R&D’s trust and respect. They will know if you are interrupting – it’s for a good reason, and they will give you their full attention when you do so. Their workload will be reasonable so they’ll  probably make the extra effort to meet all of their commitments.

At the end of the day – their trust and their motivation is the best you can wish for. So if you reached that stage – well done!

 

What you should expect from the R&D?

Like a parent-child relationship – you need to give love and protection, and on the same breath – set up expectations as for what should be the norm in terms of working practices.

Here is what should be expected from the R&D:

1. A timely delivery. If they committed to a deadline – they should meet it.
2. A quality delivery. Together with the QA – they need to put processes in place to ensure that the deliveries don’t break easily or at all – when they reach production.
3. Provide EE (efforts estimations) for features in a timely manner. Rough estimations if the requirements were provided on high level and granular estimations for fine tuned requirements. This may take practice from the developers and the R&D management at first. At the beginning their timing may be quite off – but don’t give up and keep asking them for it. Eventually they will improve with their estimations.
4. Tech debt tasks that deliver incremental value. The R&D are responsible for their tech-debt tasks (tasks which relate to infrastructure improvements). They need to have some plan in place and be able to break it down to incremental pieces that fit within a sprint. They also need to convince you what value the company will gain by working on this tech-debt item (migrating to a cooler technology is not a justified reason…)
5. Know their stuff. This may seem obvious but it’s not. Sometimes there is a gap of knowledge when they need to implement a specific feature of yours (for example – laying the foundation for a new data paradigm that will serve new flows). In such cases – they will need to first acknowledge the gap (not trivial) and then suggest a plan as for how to bridge the gap (hiring a consultant, taking a workshop, self education, etc…). The worst thing they can do is to ignore the gap and get to coding hoping it will be ok…
6. Build the right team. This is a ‘strategic’ extension of the previous bullet. Looking at your roadmap – it’s the R&D responsibility to look beyond ‘right now’ and see the type of expertise they will need to have as part of the team. Once a gap is identified – they should work on a hiring plan to have the right people in place at the right time.

 

You should set up these expectations when you start establishing a relationship with your peer, who is probably a leader within the R&D. If they are veterans – then most of the above is probably known to them already, so it just worth mentioning it briefly as you discuss the process.

 

Agreeing on the process

Yes, the process…

The process is one of the first things you need to agree on with your R&D peer when you get into the role. Kanban or scrum? Who owns what? How does the delivery chain work? I covered it all in depth in the ‘delivery process’ series so I won’t discuss it here. You can start here if you missed it.

 

Concluding

There is much more that can be written about this relationship and the small details do matter. However, I’m doing my best to keep these posts short and to the point.

Therefore, what you need to recall is that you are all on the same boat and a feature is concluded only once it gets into the hands of the customers (well… the first iteration at least).

You can’t do it without them (the R&D). They can’t do it without you (well… they can build something… but it probably won’t deliver the value it should).

Therefore, stick to the above, and make sure you stay on good terms with your R&D peers, even if they are not the guys you would go drinking with after hours…

If something is broken in this relationship – take it on yourself to fix it, even if it means to put your ego away. Avoid escalation unless absolutely necessary.

 

And sometimes, yes, it could happen that you don’t have a real partner on the other side. Consult with your superior as for how to resolve this. There are several options in such a situation. None of them is great – so avoid reaching this stage unless your superior and you can’t find any other option.

 

That’s it for today.

If you found this post/series useful – feel free to let me know in the comments. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂