The document discusses implementing research and development (RnD) teams in enterprises. It begins by defining different types of RnD, including scientific, industrial, and IT RnD. It then discusses important considerations for top management in establishing a successful RnD program, including committing to consume RnD deliverables and establishing an RnD committee and processes. The document outlines the lifecycle of an RnD project from MVP to product development. It provides guidance on setting up effective RnD teams and processes, such as prioritizing MVPs, establishing roles like the RnD lead, and ensuring a smooth handoff to product teams.

1. RnD teams vs Product teams or a story
how to implement RnD in enterprise
without pain
Alexander Tokarev
Xsolla

2. Expected attendees
1. Any work for RnD already
2. Any who found RnD position and wanna change job
3. Teamlead in a RnD team
4. Lead of teamleads of RnD department
5. Top manager who want to establish RnD or already did it
Too strange and complicated for others…

3. Who am I
1. Startups 5 software developers – Enterprise 30k software
developers
2. Ex-Sbertech – Head of RnD
3. Head of development hub – Xsolla
• Leading leads of teamleads
• Consuming RnD legal entity results
• Balancing between finance and architecture
4. Ontico conferences fan

4. 1. Payments and payouts for gamedev – 800+ payment providers
2. BaaS for in-game shops
3. LiveOps
4. Antifraud
5. From indie to enterprises
6. 800+ team members across the globe

5. Agenda
• RnD types
• Product lifecycle
• All about team
• Artefacts
• ChatGTP
• Checklists
• Q&A

6. RnD types
• Scientific RnD – takes ages
• Industrial RnD – common process
• IT RnD – area of discussion
• RnD – just cool wording

7. RnD types

8. Not RnD
Middle/Middle+ Python RnD developer
И что тут RnD?

9. Scientific RnD
Эксперт по физик ускорителей и квантовой механики

10. Industrial RnD
Менеджер по R&D
В прошлом технологи

11. IT RnD
Руководитель центра R&D

12. IT RnD
Разработчик R&D

13. RnD
New technology created by any
means from scratch without
deliverables commitment!
An activity that enterprises undertake to develop new products, processes
or services or improve those that already exist.

14. Gartner hype cycle
1. separates hype from the real
drivers of a technology’s
commercial promise
2. shows maturity and adoption of
technologies and applications
3. solves real business problems and
exploiting new opportunities
4. promises of an emerging
technology
5. yearly updated and published by
problem domain
6. reduces the risk of technology
investment decisions
But it seems it’s not relevant when it is about vendors…
1
2
3
4
5

15. Gartner hype cycle
1. separates hype from the real
drivers of a technology’s
commercial promise
2. shows maturity and adoption of
technologies and applications
3. solves real business problems and
exploiting new opportunities
4. promises of an emerging
technology
5. yearly updated and published by
problem domain
6. reduces the risk of technology
investment decisions
1
2
3
4
5

16. Gartner hype cycle
1. separates hype from the real
drivers of a technology’s
commercial promise
2. shows maturity and adoption of
technologies and applications
3. solves real business problems and
exploiting new opportunities
4. promises of an emerging
technology
5. yearly updated and published by
problem domain
6. reduces the risk of technology
investment decisions
1
2
3
4
5

17. Gartner year general cycles

18. Gartner year detailed cycles

19. RnD

20. Enterprise maturity level
• The best part of products – plateau of productivity
• Employee count – 1000+
• Age – 5+ years
• Stable income
• 50+ Mln USD revenue
Could be different but success is questionable…

21. RnD sides
• Who requests
• Who makes
• Who evolves
• Who manages
Client
RnD team
Product team
Top management
internal
external

22. RnD sides
• Who requests
• Who makes
• Who evolves
• Who manages
Client
RnD team
Product team
Top management
internal
external

23. Top management prerequisites
1. Strict commitment to consume RnD deliverables
2. Agile change agent and early adopters fostered in product teams
3. RnD committee and processes for portfolio management
4. Agreement – failed MVP is fine
5. Teams are intact
6. Own infrastructure or cloud-first
7. Different legal entity or a dedicated security perimeter
8. Agreed max and min MVP budget
9. Decent RnD budget
RnD is always
about portfolio
Ready to loose
FinOps obsession
External is better

24. MVP source
• Heavily depends from type:
• business product
• Infrastructure
• software development
• ML/AI
• Enterprise pains
• Enterprise chats
• Enterprise knowledge bases – Confluence, retro …
• Internet chats
• Forums
• Researchgate.net
• Schedules of IT conferences

25. Marketing
• Marketing for startup <> marketing for enterprise
• Product is more important that marketing
• 1 presentation is enough
• More marketing artefacts – more shame
• No trust further

26. MVPs portfolio management
Borrowed from SAFe!

27. MVPs prioritization
1. RICE
2. Eisenhower matrix
3. MoSCoW
4. ABCDE
5. ICE
6. Value versus Effort matrix
7. WSJF
8. Kano
9. Walking skeleton
RnD lead interview questions

28. MVPs prioritization for RnD
1. RICE
2. Eisenhower matrix
3. MoSCoW
4. ABCDE
5. ICE
6. Value versus Effort matrix
7. WSJF
8. Kano
9. Walking skeleton
Less data is required
Too much uncertainty!

29. RnD product lifecycle
• MVP – prove feasibility and liveness

30. MVP for RnD
MVP is a nurtured RnD product which:
1. implements proved business or technology idea
2. provides core function proficiently
3. is ready to be transferred to a product team based on agreed
conditions and commitment
4. Is attributed by 2 teams – RnD team and product team to be
transferred from day-one

31. MVP for RnD
MVP is a nurtured RnD product which:
1. implements proved business or technology idea
2. provides core function proficiently
3. is ready to be transferred to a product team based on agreed
conditions and commitment
4. Is attributed by 2 teams – RnD team and product team to be
transferred from day-one
Not used in product development!

32. 2 teams for RnD
MVP team
Product
team
Product team
first!!!

33. Out of MVP
• Should be agreed before each MVP
• Monitoring/metrics
• Logging with variables levels
• IaC
• Cybersecurity
• Awesome CI/CD pipeline
• Enterprise CI/CD pipeline

34. Out of MVP
• Should be agreed before each MVP
• Monitoring/metrics
• Logging with variables levels
• IaC
• Cybersecurity
• Awesome CI/CD pipeline
• Enterprise CI/CD pipeline
Enterprise pain

35. Team topology
• Roles: tech/teamlead, backend, frontend, infrastructure engineer
• SRE could be shared
• QA will be in product team
• 3-6 teams simultaneously
• Beware outsource!
• If you need a help – short-term technology consulting
Deadly hard to consume much
MVPS in case of success!
1 per year – it is a good number!

36. RnD engineer
1. Self-sufficient
2. Not afraid not clear or vague requirement
3. Capable to decompose huge tasks
4. Fearless to task which absent on StackOverflow
5. Ready to be re-skilled fast
6. Short reflection time after deathgating/transferring MVP
7. It’s not a developer – it is Engineer!
Tell to HR – must be
on screening!

37. Engineer vs Developer
Task 1: create multi-tenant K8S service installer
Developer: Implement own K8S operator + Helm API, 20 days, 30+ issues…
Engineer: Helm charts + plumbing https://github.com/opskumu/helm-
wrapper, 3 days, 5 issues…
Task 2: create Postgres extension point by any language
Developer: 3 weeks moaning, the task isn’t done, use Pl/Python or forget
Engineerr: 7 days re-skilling from Go to RUST, 4 days porting wasmer-
postgres to Postgres 14, POC is fine

38. Postgres extension point by any language
Implemented after WASMDay schedule investigation

39. RnD lead
1. RnD lead is a key
2. Relentless IT exploration and trends awareness
3. Expectation management
4. Experienced facilitator for business and tech
5. Tech presale + enterprise architecture experience
6. Awesome presentations skills
7. Acts as a product director
8. Shadowing on daily basis Continuous lead backup!
Deathgating relief

40. RnD lead IT exploration
¼ of daily investigated IT channels!

41. RnD spirit
1. Innovation pace is a key
2. Strict timelines
3. No product development
4. Every project is different
5. Every project is a challenge
6. Teams reassembled for each project
7. No fixed teamlead/techlead role across RnD
8. Anyone from RnD could be a teamlead/techlead
9. Continuous roles rotation
10. Must be told on interview

42. Pace + timeline + variety examples
10 months
FPGA-based data
processing
Verilog, C, C++, Go
FinOps platform
Java, Python,
PromQL, Rego,
OPA, Graphana
DLP via Service Mesh
Istio, Envoy, WASM, C++

43. Product development smell
1. Autoscaling, rate limits, log level, monitoring
2. A/B tests placeholders
3. Too much API methods
4. ….
Stop it ASAP!!!

44. Product development smell example
MVP: S3 Select with hardware acceleration
API v1: CreateBucket, CreateObject, SelectObject
API v2: CreateIAMGroup, CopyObject, EncryptObject, SetLifeCyclePolicy
After 2 month of
development still
NO SelectObject
BUT!!!
Team started
implement S3
instead!!!

45. Technologies
• Use Rust
• Try use the simplest – even Telegram or Google sheets
• RnD team is more confident in
• Try to be close to technologies enterprise get used developing!!!
Easy transfer and a chance to get enterprise success!

46. RnD technologies tradeoff
• RnD performance
• Convenience for a particular MVP
• Product team hate
• Efforts, time and money to be rewritten by product teams
RnD lead duties!

47. SDLC methodology
• Should be a combination
• Kanban – when there is too much uncertainty
• Scrum – when there are first users

48. Intro before transfer
• Intro before transfer is a must
• All MVP team participates
• RnD declare that there is no perfect code
• RnD declare that the best part of code issues is documented
• Transfer is a place of questions rather than hating
Do not use approach
“Create a list of questions is confluence”!
Product teams hate it!

49. Artefacts for product teams
• MVP
• Tech debt tracker backlog
• Current architecture + target architecture
• ADRs
• Deploy scripts if you have
• CJMs
• Features backlog
• Clients’ contacts
Not random Word doc!
Insurance that you’re aware of bad code!
Try be polite – product teams states they are
best in architecture because closer to
production
Any format actually – it isn’t yours actually

50. Artefacts for product teams
• MVP
• Tech task tracker backlog
• Current architecture + target architecture
• ADRs –Architecture decision records
• Deploy scripts if you have
• CJMs
• Features backlog
• Clients’ contacts
Attribute of enterprise MVP RnD!
Otherwise Product team fails as
you did before in POC stage!
Extra hate is guaranteed!

51. Artefacts for product teams
IDEA!
Product vision
Product owner to product team transfer!!!
Budget

52. RnD product lifecycle
• MVP – prove feasibility and liveness
• Project development – enterprise quality to deadline

53. After-RnD stage
• Articulate 6 month non-conditional warranty support
• Mentor transferred product owner up to 3 months
• Notify live client if they are in place
• Monthly status check 6 months
Do it if you care about RnD success!!!

54. RnD product lifecycle
• MVP – prove feasibility and liveness
• Project development – enterprise quality to deadline
• Product development – product features from backlog

55. Deathgating metrics
• MVP duration
• Out of budget
• Customer feedback is negative

56. Project duration
• Depends from product type
• New product – 3 months
• New technology – 6 months
Easier to test – wide auditory
A lot of opensource + hard to implement
Reduce risk however is possible – opensource-based POC is fine!
Even with bad license!

57. Deathgating reasons
• Out of metrics
• RnD lead isn’t skilled enough
• Idea is not feasible
• Team isn’t qualified enough
• Team is product team
Focus management
Portfolio management
Tech management

58. Deathgating or transfering to product team pain
• Team will suffer at any case
• Go to the bar
• Should be standard rituals
• Retro
• Portfolio of next projects
• Publish to tech media
• Publish to opensource
If you have a relevant team…
If there is no IP rules violation

59. Deathgating ratio
1. Deathgating ratio 3/1 is fine for enterprise
2. Ratio >3 – bad portfolio
3. Bad portfolio – bad RnD lead?
4. Huge difference for YCombinator startups ratio 100/1
Why?
1. Less failure tolerance in enterprises
2. Core business pressure

60. Performance metrics
1. Portfolio size per state
2. Deathgated MVPs
3. Costs for RnD
4. Cost per MVP
5. RnD efficiency ratio – spends/profit
6. MVP implementation time
7. Product team onboarding time
8. Product to production delivery time
Are they good or not – 2 years interval!
cost
time
count

61. Read something cool

62. Conclusion
1. Request new ideas from RnD
2. Refill ideas portfolio continuously
3. Care about quality
4. Stop in time
5. Ensure you have a budget
6. Care about risks – subject of layoff

63. RnD vacancy checklist
1. How many MVPs in progress now
2. How many not started MVPs in portfolio
3. How many alive projects after 1 year of MVP
4. Deathgate proportion
5. Where MVPs came from
6. RnD decision process
7. Which is total RnD budget
mention examples

64. RnD candidate checklist
1. Suggest 3 RnD projects
2. How to create RnD process from scratch
3. Suggest RnD team structure
4. What should be passed to product team
5. When and how do you stop project
6. Boring tech stuff…
The best part fails here!!!

65. Q&A Оценить доклад
https://www.slideshare.net/AlexanderTokarev4
https://ru.linkedin.com/in/alexander-tokarev-14bab230