Organisational process design is paramount to successful leadership. Intentional or not, we construct and model the communication frameworks that govern the way our teams make decisions. Ideally, we approach this responsibility deliberately, establishing processes that empower where empowerment matters, safeguard where boundaries are called for, flex and harden and stretch, and encourage outcomes consistent with our guiding principles. Inevitably, the processes that we adopt won’t just guide our decisions – in tangible ways, the processes are the decisions.
In a growing company, two business critical examples of where process-as-decision has lasting and material consequences are hiring and product development. I’d like to briefly explain why and encourage greater appreciation for the significance of value-driven, intentional process design.
Framing Our Frameworks
We did not choose our native language. We arrived in the world as strangers, compelled by instinct and necessity to embody the words, customs, and contours of the culture into which we were born. How did that externally-imposed communication framework shape the way we think? How did it constrain or empower us? What role did it play in the development of our values?
A proposition called linguistic relativity holds that language shapes culture. Interpretations of this idea vary, but all suggest that, to some degree, the rules and structures of our language constrain or influence our patterns of thought and our frameworks for reasoning.
Though a centuries-old idea, linguistic relativity influences contemporary culture in interesting ways. Software engineers using the Ruby programming language interact with Yukihiro Matsumoto’s vision of a language whose syntax is optimised to empower the programmer. Just last month, a University of Washington study on social media and politics considered how a person’s native language affects their views on data privacy.
What does linguistic relativity teach us about leadership, management, or product development? It reminds us that externally-imposed frameworks shape the way we approach process creation. We did not choose our native language, but we probably designed our engineering interview process, influenced our product development methodology, and decided on a process for capturing feedback in a retrospective. All of these decisions create new communication frameworks that inevitably encourage certain behaviours, decisions, and outcomes, while deterring others.
Product Development: Encoding Excellence
A few weeks ago, my product leadership team held an offsite meeting. With team size on-track to double in six months, and an awareness that existing product development process wouldn’t scale, we met to enumerate the limitations of our current process and brainstorm solutions to get us to the next stage of growth. We began with two retrospective-style questions: What’s working? What’s not working?
Often, the “what’s not working” list is easier to elicit than the “what’s working” list, but we made a point to articulate the latter first, asking each other: What needs protecting? What got us where we are today? What values are we unwilling to compromise as we write our next chapter?
Our must-haves list ranged in specificity from a broad mandate to prioritise customer empathy, to general principles like validating content accessibility for new components, to specific policies like full-team participation in QA test cycles. Of course, your team’s answers will vary, but it is worth enumerating your values up front to ensure that each iteration of your process re-encodes them.
Recruiting and Hiring Process: Demanding Diversity
The business case for diversity is well-documented (including by me): when product development teams resemble their addressable market, profits increase and user experience improves. To me, though, the business case is secondary: diversity matters because it matters, inclusive UX matters because people deserve it, and revenue matters because it fuels the work I love doing. I want to build teams that I look forward to working with each day, composed of diverse and interesting people, solving challenging problems and delighting users. I can think of no better process to reinforce the process-as-decision thesis than hiring: it is the difference between diversity as an aspiration and diversity as a decision.
Our hiring process encodes diversity as a value at every stage. We require interviewers to complete training designed to ensure a welcoming and positive candidate experience. We attend and sponsor recruiting activities that ensure top-of-funnel candidate pool diversity. We employ anonymous code reviews to reduce implicit bias during early-stage technical evaluation. Absent these (and other) processes, our commitment to diversity would be an empty promise. With them, we achieve tangible results, such as an engineering team that is 30% women – far higher than the industry average.
Conclusion
Our processes are more than means; they are ends. They are our decisions. They carry our values forward in tomorrow’s planning meeting, in next week’s hiring decision, in next quarter’s budget meeting, and in next year’s acquisition. As we define the operating systems of our organisations – whether planning product roadmaps or recruiting the talent to execute on them — we must double down on the values that got us here and encode them into the processes we design for tomorrow.
We can’t choose our native language, but we can build new communication frameworks that govern how our teams make decisions. Let’s build them carefully.
