Research & Development: competing structures for engineering and targeting ‘best practice’

By James Ryan, Senior Associate

We recently hosted a breakfast workshop entitled, Research & Development: competing structures for engineering and targeting ‘best practice’, which proved to be both informative and dynamic in the debate. It was a great way to kick off 2018 and a perfect complement to the qualitative phase of the report on competing engineering structures and ecosystems in Europe that we carried out in the final quarter of 2017. Both aimed at approaching the intangible, providing insight and engendering debate on the lessons learnt and areas that demand attention for engineering to be productive, efficient, and healthy.

The overarching debate can be seen as an evaluation of the relative strengths and weaknesses of wholly co-locating development versus the dynamics of distributed development across the varying structures. By engaging our network, we were able to access engineering and technology leaderships across the spectrum, encompassing staging, sectors, pureplay and digital transformation. The key areas of interest and learning that surfaced from the report and dominated the workshop can be arranged in four categories: Culture; Structure; Connectivity; and Talent and Expertise. Here are some of the tips and hacks that were forwarded, as well as highlighting of much that is still under debate.


Culture as a consideration was interpreted in two distinct, but interrelated ways. The first was around organisational and engineering function culture, i.e. how do you build a single engineering culture across distributed sites, and whether this was actually necessary or wholly profitable? The second focused on managing different cultural dynamics, and approaches to work and engineering in a distributed model (e.g. UK and India/Eastern Europe/Southern Europe/US). Both aimed at tackling the question of how you build and maintain a modern, productive, and attractive R&D culture.

Key Takeaways

  • When building an engineering culture across distributed centres and targeting a ‘one-culture’ ethos, one shouldn’t be dogmatic or pedantic. It is necessary to consider, plan, and implement what must be the same for productivity and harmony, and where the capacity for flexibility exists to allow a local flavour to the function. Positions at each end of the spectrum are problematic.
  • The company-culture-first approach (e.g. Google-first), champions transporting and instilling the home hub’s ideals and culture as a primary approach with local culture taking a back seat. This may unintentionally sterilise the idiosyncrasies of local development that either first caused the selection of the location or would be an unforeseen benefit for the organisation. The local-first approach, risks creating development centres that are non-cohesive and so diverse that they are unable to function as a unit, which will be necessary on occasion even if functions are siloed. A middle-ground that incorporates both local and company culture constitutes best practice.
  • This dichotomy extends to language, both spoken and coded. Within a distributed development system, it serves to insist on a consistent working language (e.g. English) to promote inclusivity, flexibility, and connectivity between centres. When it comes to languages of code, it serves to not be so rigid and although for flexibility on a local level. However, within the bounds of reasonable flexibility (i.e. not one frontend tech, but equally not 10).
  • There was considerable debate around whether engineering culture should drive the business culture or whether engineering culture should adhere to the organisational culture. This was in some cases down to how technology functioned in the business, but not exclusively. Where there was agreement was that there must be harmony, whoever the driver of culture is, and for technology to function at its most productive there must be a coherent organisational culture and structure.


Structure in itself attacked the heart of the question and challenged whether distributed development was necessary or a good thing in itself. Not taking distributed development as a given, but as choice driven by necessity or design. The investigation then approached how one goes about structuring distributed development, if that structure had been advanced (e.g. separate siloed functions or one-team across the locations working in parallel). This naturally rounded on a debate of the benefits of fully co-locating development and exactly where product should sit within the R&D structure.

Key Takeaways

  • Fully co-locating development has distinct advantages and can remove many of the difficulties with distributed development. It also makes the one-team dynamic more tangible in a practice sense. Having the development structure working alongside product on their daily activities, as well as amongst the wider business functions focuses development on the commercial realities and concerns of the business.
  • Quarterly strategy days with the entire business in attendance were championed as a dynamic way to align functions and create buy-in on the strategy and road map from all. This not only improves connectivity between the different business functions, but approaches a natural extension of Conway’s Law demonstrating, for example, that for technology to be agile, so must the wider business be. Organisational disfunction is born from development and the wider business structure working to inalienable models.
  • Having a truly diverse and distributed structure enables you to tap into a wider range of talent and perspective. This is a particular boon in problem-solving and technology innovation, as local and differing perspectives will often generate unique solutions, amplifying the functions ability to solution.
  • The debate rages around the utility of near and off-shore centres for a ‘home hub’. The tendency is to silo less complex or wholly separate functions to the various centres. If followed, this must be done with caution, as you risk creating a two-tier engineering organisation. Teams must also own the outcome to be fully engaged, rather than just a project function.
  • One way of separating distributed centres in geo-graphical congruence (i.e. teams work on products for their local markets). This offers a number of obvious boons, but in truly global development there is a strong case to be made for splitting sub-teams across the distributed systems, so that you create a truly connected and international development function.


Structure in itself attacked the heart of the question and challenged whether distributed development was necessary or a good thing in itself. Not taking distributed development as a given, but as choice driven by necessity or design. The investigation then approached how one goes about structuring distributed development, if that structure had been advanced (e.g. separate siloed functions or one-team across the locations working in parallel). This naturally rounded on a debate of the benefits of fully co-locating development and exactly where product should sit within the R&D structure.

Key Takeaways

  • Connectivity within a co-located development team as well as within a distributed system can be problematic, but tools exits to enable a dynamic engagement. From a simple comms position, tools such as Jira and Slack are accessible and align well with the agility you look for in development. However, transition to them can be a journey and must be led top down. This is a case where a ‘big bang’ migration can have notable benefits.
  • Connectivity between distributed sites presents its logistical and tooling challenges too. Robust video conferencing and daily cross-centre sit downs helps open the dialogue. A constant video stream between the offices is both dynamic and effective. It forges a tangible ‘one-team’ connection and allows real-time interaction. It also tackles time zone frictions as the various offices either arrive to see the other sites at full steam of leave for the day with them fully engaged.
  •  Another way to tackle time zones at extreme variance is adjusted working hours on both sides to create a brief cross-over. However, this is a more drastic approach to heavily distributed teams and must be advanced in consultation with the teams.
  • Beyond technical connectivity, there is physical transfer of persons. This extends beyond the necessary regular presence of leadership to an exchange programmes of engineers and wider development. The regular transfer of engineer between sites not only builds team culture, but also drives communication between offices. Each develop an affinity for the offices they visit and development relationships with team members that last upon return. Communication comes from relationships, not instruction. The benefits of these programmes for productivity far outweigh the costs, as was demonstrated in a notable example where the friction between two of the distributed centres, as transport communications made transfer complex and so irregular, was pronounced compared to the overall distributed centres in the organisation.
  •  This should extend to co-located teams, where engineers and wider development cycle through the teams exposing them to all aspects of the technology function and driving communication among the units in the engineering structure. This flexibility not only improves communication and drastically reduces single points of failure, but it also helps attract and retain talent through the diversity of work and wider exposure.

Talent and Expertise

Finally, we approached the question of talent. With London being returned as the prime European technology ecosystems by the report, but also confirmed as highly competitive, we questioned how each tackled the issue of attracting and retaining talent the city. We also rounded on graduate talent. Taken as an obvious starting point for the research project, the need to dig deeper with industrial knowledge to discuss how they engaged and competed for graduate talent was pertinent. However, so was the debate on the benefits, utility, and limitations of graduate talent within the R&D organisation. The final consideration that continued to surface through the qualitative stage was the debate around certain spaces and certain technology functions being better suited to specialised locations within a distributed system. This posited that distributed engineering provided access to talent and skill-sets that full co-located development simply cannot.

Key Takeaways

  • Brand strength is obviously a great driver of talent to the business, but it does not necessarily retain it. Varied and exciting work that allows talent to development and acquire news skills can be far more meaningful than the name on the wall.
  • Create a narrative for your engineering culture and the journey, individually and collectively. Selling talent on what you are trying to solve for and where the aims of the company sit can be compelling, as can a genuine programme of advancing talent within the business. If you reward and develop talent, you become an attractive place to join and to stay.
  • Don’t hire talent to target, but to quality (i.e. if the target is 20 and only 15 meet the bar, hire 15 and realign priorities. Alternatively, if the search returns 25, then endeavour to capture as much as the business allows).
  • Always engage your top engineering talent in the hiring process, excellence must set the bar. It is worth their time and your resources.
  • Graduate talent is an incredibly valuable resource if deployed and developed correctly. One profitable programme was a business wide three-year initiative, where graduates cycled through the various units on a 6-month run. Over the course of the three years, the graduates were exposed to variety and different ways of working, giving them a greater understanding of the business and flexibility in their approach. This not only retained graduate talent, but made them some of the most sort after employees in the business.
  • Graduate talent can often be a great way to scale in an early stage business when resources are tight and innovation, dynamism, and malleability are key. It is also a well-used channel to build up development when enter nascent ecosystems. A strong connection and reciprocal relationship with the various universities is key.
  • Another way of rapidly building in a new location is acqui-hiring, which can immediately acquire the talent and skill-sets that you need in the space. A company’s expertise and innovation may even be what drives you to the location in the first place. Taking us back to the start, this is where culture rears its head again, as an established culture in an acquired organisation can buck against a new superstructure. Equally, too arbitrary an enforcement of central culture by the acquiring company can rob the new structure of the innovation and excellence it so desired.

Thus, as can be seen from the above and as was flagged at the beginning of this piece, the debate was and remains dynamic. The reach of this study from early stage disruptive businesses, through those in high growth, internationalising, to scaled and globally distributed technology super brands, and finally, into the larger corporates tackling modernisation and transformation, means that the discussion so far offers a full range of perspectives and forced each issue to be tackled within stage and context as well as across the variables. To give the reader satisfaction on this point, we have provided a snapshot of the kinds of brands whose engineering and technology leadership engaged in this discussion to-date, but this was in no way comprehensive (as no study within reason parameters could be) nor was it planned as a full-stop. We hope the above has been and will be useful for the reader, but we are equally excited for the debate it will spark.