All organizations are wrong, but some are useful. This session discusses the different ways high-performing engineering organizations gain leverage by specialization and sharing. Taking an engineering approach, we can factor out common capabilities into Services, Platforms, and Communities, with the goal of enabling other teams to sustainably deliver specialized value to customers and to the business. With common Services, organizations effectively divide work and expertise by domain. We discuss full-stack teams, the healthy vendor-customer relationship between provider and consumer, and the need to allow customer teams to choose whether or not to use a service. With a common Platform (or platforms), organizations share foundational capabilities and make it easier to build, deploy, and operate services and applications. We discuss the value of a Paved Road a la Netflix or Google, the fear of lock-in, and the need to charge customer teams for usage of the platform. With common Communities of Practice, organizations share ideas, practices, and idioms outside the formal organizational structure. We also discuss the value of an internal open source model for developing and improving shared systems. Lastly, we outline the critical characteristics of Leadership that make all of this possible, including technical competence of leaders, employee empowerment, psychological safety, and inclusive decision-making. You will take away actionable insights you can apply in your own organization.

1. Engineering Your Organization:
Services, Platforms, and Communities
Randy Shoup
@randyshoup
linkedin.com/in/randyshoup

2. Background
@randyshoup

3. All organizations are wrong,
but some are useful.
@randyshoup

4. Organizational
Goals
• Sustainably deliver value
• Effectively leverage people, teams, and
technology
• Continuously improve and adapt
@randyshoup

5. Specialization and
Sharing
@randyshoup

6. Specialization and
Sharing
@randyshoup

7. Engineering the
Organization
•Services
•Platforms
•Communities
•Leadership

8. Engineering the
Organization
•Services
•Platforms
•Communities
•Leadership

9. Business
Alignment
<Business
Domain>
• Aligned around a business
problem
• Clear goals and metrics …
o … that matter to customers!
@randyshoup

10. Full-Stack
Teams
Idea
Development
Quality
Operations
Idea
Development
Quality
Operations
Idea
Development
Quality
Operations

11. Service
Organization
• One domain: One team: One / few service(s)
o Organization  reflects  Architecture (“Conway’s Law”)
• Team can independently design, develop, deploy,
operate its service(s)
• Team owns its service(s) end to end, cradle to grave
@randyshoup

12. Service
Provider
• Meet the needs of the customers …
o Functionality
o Quality
o Performance
o Stability and Reliability
o Constant improvement over time
• … at minimum cost and effort
o Leverage common tools and infrastructure
o Leverage other services
o Automate building, deploying, and operating the service
o Optimize for efficient use of resources
@randyshoup

13. Service
Discipline
• Vendor-Customer Relationship
o Service provider team is a vendor; consumer teams are customers
o Service is useful only to the extent that it provides value to customers
• Choose to Use
o Customer team can choose to use the service or not
o Service must be *strictly better* than any alternatives of build, buy, borrow
@randyshoup

14. Service
Evolution
• Variation and Natural Selection
o Create / extract new services when needed to solve a problem
o Services justify their continued existence through usage
o Deprecate services when they are no longer used
• Teams grow and divide over time
o Teams and services split like “cellular mitosis”
@randyshoup

15. “Every service at Google is
either deprecated or not
ready yet.”
-- Google engineering proverb
@randyshoup

16. Engineering the
Organization
•Services
•Platforms
•Communities
•Leadership

17. Common
Platform
• Common Capabilities
o Authentication
o Secrets management
o Observability
o Alerting
• Standard Frameworks
o Service “chassis”
o Communication protocols and
data formats
@randyshoup
• Shared Infrastructure
o Compute and storage
o Databases
o Event system
• Developer Experience
o Source control
o Development and testing
environments
o Continuous Delivery pipelines

18. Platform
Provider
• Reduce cognitive load on customer teams
• “Paved Road”
o Consistent set of integrated capabilities that work together
o Path of least resistance
o E.g., Netflix, Google
• Self-service
o Automated provisioning
o Integrated monitoring
o Examples and documentation
o Mocks
@randyshoup

19. Platform
Consumer
• If you use it, embrace it
o Abstracting it away leads to “least common denominator” capabilities
o Replacing a platform is rare; don’t optimize for the edge case
• “Lock-in” is another way of saying “value”
@randyshoup

20. Usage
Discipline
• Charge to Use
o Charge customers for *usage* of the service
o Free usage gives no incentive to control usage or find more efficient alternatives
o Motivates both provider and consumer to optimize
• E.g., App Engine usage at Google
o Charging particularly egregious internal customer led to 10x reduction in usage
@randyshoup

21. Engineering the
Organization
•Services
•Platforms
•Communities
•Leadership

22. Communities
of Practice
Collaborating via
• Slack channels
• Groups and maillists
• Periodic meetings
• Internal conferences
@randyshoup
Organized around
• Language framework /
ecosystem
• Specialized roles
• Service / platform consumers
• Techniques and Practices

23. Internal
Open Source
• Accept contributions from outside the
team
o Contributor submits a Pull Request (with tests!)
o Provider team reviews, iterates, merges
• Best Practices
o Document your processes
o Learn to say no
o Leverage the community
o Embrace automation
@randyshoup
https://opensource.guide

24. “Pull Requests
are accepted”
@randyshoup

25. Engineering the
Organization
•Services
•Platforms
•Communities
•Leadership

26. When you organize,
think like an engineer.
When you lead,
think like a parent.
@randyshoup

27. “Technological
Maestro”
• High energy
• Asks the right questions
• High standards
• Good on the details
@randyshoup

28. “If the man at the top is a dope
or ignorant, everyone under him
will soon be a dope or ignorant,
because he sets the tone.”
-- Rabinow’s 23rd Law of Leadership
@randyshoup

29. A players hire (and retain) A
players.
B players hire (and retain) C
players
@randyshoup

30. Theory X vs.
Theory Y
• Dr. Douglas McGregor, 1960
• Leadership’s beliefs about
what motivates employees
@randyshoup

31. Theory X vs.
Theory Y
• Theory X: people are inherently
lazy, avoid responsibility, require
extrinsic motivation
• Theory Y: people are intrinsically
motivated, seek ownership, want
to perform well
@randyshoup

32. Never ascribe to malice what can adequately
be explained by incompetence.
@randyshoup
-- Hanlon’s Razor
-- Shoup’s Corollary
Never ascribe to incompetence what can
adequately be explained by perverse
incentives.

33. Psychological
Safety
• Team is safe for interpersonal
risk-taking
• “Being able to show and employ
one’s self without fear of
negative consequences”
• More important than any other
factor in team success

34. Inclusive
Decisionmaking
• Make better business decisions 87% of
the time
• Make decisions 2x faster with 1/2 the
meetings
• Deliver 60% better business results
Cloverpop Inclusive Decisionmaking study, 2016
As we improve diversity, decisionmaking improves
@randyshoup

35. None of us is as smart as all of
us.
-- Japanese proverb,
as quoted by Bob Taylor
@randyshoup

36. Engineering the
Organization
•Services
•Platforms
•Communities
•Leadership

37. “If you can’t
change your organization,
change your organization.”
-- Martin Fowler
@randyshoup

38. Thank you!
@randyshoup
linkedin.com/in/randyshoup
medium.com/@randyshoup