While nearly every development team uses some form of code review, code reviews are frequently used only among developers. While other developers are certainly a valuable audience for your code, nondevelopers can also add value by applying their own perspectives to the work as early on in the process as possible. Margaret Fero explores the benefits of having representatives from the product management, technical documentation, instructional design, user interface design, and user experience teams on your code review from the start, rather than starting with just developers and adding other teams’ considerations later in the process. A code review is cross-functional if it includes not just members from other teams but also acceptance and implementation of the different types of feedback. She suggests different functional roles that could be included in a code review and what each role can add to the overall success of the review. Margaret explains the benefits of different perspectives and general best practices for choosing your code reviewers (either at the process development level or implementation level) and addresses some relevant change management issues.

1. Cross-Functional Code Reviews
Margaret Fero
Technical Writer | Degreed
maggie@degreed.com
@maggiefero

2. Agenda
Welcome!
Why would I want that?
But for Code Reviews?
How do I do it, then?
Wifi: OReillyCon19
Password: oscon2019

3. Breakthrough innovation occurs when
we bring down boundaries and
encourage disciplines to learn from one
another.
Gyan Nagpal
Author of Talent Economics and
The Future Ready Organization

4. “A leader’s job is to build the team with as few blind spots as
possible (‘diverse by construction’), then guide them to their
potential.”
Wienbar, Sharon. “How to Hire Female Engineers,” TechCrunch. https://techcrunch.com/2015/11/05/how-to-hire-female-
engineers/

5. Diverse teams form a more creative whole by creating more of the
Perspective/Heuristic pairs described in Hong/Page 2004
Hong L, Page SE. “Groups of diverse problem solvers can outperform groups of high-ability problem solvers.” Proc Natl Acad Sci U S A. 2004 Nov
16;101(46):16385-9. Epub 2004 Nov 8.
Functional Diversity

6. Functional Diversity
Perspective
“The representation of solutions in the
problem solver’s internal language is called
a perspective.”
Heuristic
“A problem solver’s heuristic is a mapping…
from solutions in her internal language to
subsets of solutions. It captures how she
searches for solutions.”
Hong L, Page SE. “Groups of diverse problem solvers can outperform groups of high-ability problem solvers.” Proc Natl Acad Sci U S A. 2004 Nov
16;101(46):16385-9. Epub 2004 Nov 8.

7. In Process
Perspective
To internal language from solution
Description of solutions
Problem to internal processing
Heuristic
From internal language to solution
Mapping of self-talk to solutions
Internal processing to result
Problem
Internal
Processing
Result

8. Is it worth it?
Phillips, Katherine W.; Katie A. Liljenquist; and Margaret A. Neale. "Is the Pain Worth the Gain? The Advantages
and Liabilities of Agreeing With Socially Distinct Newcomers." Personality and Social Psychology Bulletin. March
2009 vol. 35 no. 3 336-350 doi: 10.1177/0146167208328062
Diverse groups perceive interactions as
less effective and report low confidence
in performance, but…
Phillips, Lijlenquist, and Neale (2009)
found that their performance was
actually better than homogeneous
groups. Not just because of new ideas,
either.

9. What about you?

10. What makes it cross-functional?

11. Stakeholders from
other teams
Who participates?
Developers Stakeholders from
your team
Developers on your team
Developers on other teams
Product Managers or Product Owners
Technical Writers
Security Team Members
UX Designers
UI Designers

12. Why?

13. Who Participates?
Who? Why are they included?
Developers on your team Check for accuracy and use of patterns; adherence to team
norms.
Developers on other teams Create or maintain organizational flexibility by building
institutional knowledge across teams.
Product Managers or Product Owners Early insight into how implementation aligns with
acceptance criteria.
Technical Writers or UX Writers Make sure customer-facing words align with style; build
deep knowledge before documenting.
Security Team Members Look for implementation risks early
UX Designers Find the pain points before customers do!
UI Designers Verify that changes to your style since the work was planned
are implemented correctly.

14. Benefit from your
whole organization’s
knowledge.

15. CHOOSING CODE REVIEWERS
• Start from a chart
• List reasons why you would want a function
• Decide which types of changes that function should review
• Decide how to choose specific reviewers in advance
• If you can, make it optional
• Ensure that reviewers (and managers!) see that they add value

16. CHOOSING SPECIFIC PEOPLE
• Do they enjoy reviewing?
• Do they have a background in the language?
• Do they need to learn more about a product or component?
• Are they already overworked compared to teammates?
• Does the team have capacity?
• Does their manager buy in, and how much?
• Normal team chemistry considerations

17. How to win friends
and influence process
CC0-licensed image from pexels.com

18. Changes to review
processes can be hard to
keep track of.

19. Check in code
Update issue status
Create CR doc
Invite reviewers
Follow up if needed
Use feedback
Create CR folder
Invite reviewers
Review comments
Meet to discuss
Post final version
Check in code
Provide Checklists

20. Incorporate this when
change is expected
• Process review
• End of sprint
• End of year
• Goal-setting
• Just after a major release

21. Include Reminders In Your Workflow
Create an issue
Assign the issue
Draft a solution
Code Review
Resolve the issue

22. Our developers don’t like or need
these other people in their code.
CC0-licensed image from pexels.com

23. Communicate the Reasons for the Change Thoroughly
Nobody wants to produce bad code.

24. Provide Resources
Help Reviewers Help You
1. Learn what your reviewers know.
2. Help them fill gaps.
3. Reap success!

25. But Where Do I Get Resources?

26. Present it as an
opportunity. All
participants gets to
learn about their
teammates’ jobs.
CC0-licensed image from pexels.com

27. I don’t want my people
involved so early in the
process. It can be wasteful, and
their time is valuable.
CC0-licensed image from pexels.com

28. Reduce Other Work
(if you can)
• Find inefficiencies in other processes
• Can you add fewer features while this
process ramps up?
• Are any of these people doing things
that could (or should) go to others?

29. Emphasize long-term
reduction of labor.
CC0-licensed image from pexels.com

30. Measure Actual Waste How much do you keep after code review?

31. Questions?

32. Rate Today ’s Session
Session page on conference website O’Reilly Events App

33. Margaret Fero
Technical Writer
Find me on the web:
• Degreed.com/maggiefero
• Linkedin.com/in/margaretfero
Maggie@degreed.com
@maggiefero