In previous posts we’ve talked about the increasing enterprise focus on environmental, social, and corporate governance (ESG), or stakeholder capitalism. One of the most important components of ESG is diversity, equity, and inclusion, or DEI. In this blog post we won’t spend time on why it’s important—we’ve covered that in previous posts. Instead, we’d like to talk about how to address it. In particular, we’d like to raise the question: what if we were all to take an engineering approach to solving DEI? In other words, can we apply the problem-solving skills and creativity that exist in IT organizations to the challenges of DEI?
We’ve all been talking about diversity and inclusion for a long time now. And the fact that we’re still talking about it is pretty good evidence that what we’ve done to address it isn’t working, or at least isn’t working sufficiently. We technologists have often come across this situation: a problem whose obvious solution turns out to be ineffective. It’s not a good analogy on all points, but think for a moment about how we replaced monolithic develop-then-test approaches with more iterative ones, fine-tuning and enhancing minimum viable products and identifying and fixing defects.
If your company has been unsuccessful in meeting its DEI objectives, consider that a defect. As with any defect, you have to use your problem-solving skills to fix it, then re-deploy. Create an acceptance test for meeting your diversity goals. Keep working until the test passes. That’s how we do things these days…when we’re fully committed to finding a solution.
You can start by working backward from your goals. Your company will need to set those itself—we can’t tell you what the right goals are. But it’s essential that you take those goals seriously—that you commit to finding ways to accomplish them. That’s just what we do with engineering projects.
Next, map those goals into potential ways of accomplishing them. We’ve found Gojko Adzic’s impact mapping method to be useful in working backward to drive software delivery efforts, but any organizing framework will do. In impact mapping, you begin with an objective and then map it into desired behavior changes. We don’t mean that in a negative way in the sense of coercive behavior changes, just that any change in an organization of people requires behavior change. For example, at USCIS one behavior change we wanted was that records clerks would scan a barcode on files as they handled them. For DEI, we might begin with hiring managers, HR, other employees, or even potential job applicants, and look for changes in what they do that would support diversity goals.
Then, for each person’s behavior you want to change, for each behavior change you want, you brainstorm the actions you can take that might cause that behavior change. The result is a sort of mind map of potential solutions and the impacts you’d expect them to have. For example, if the person whose behavior you want to change is the potential applicant for a job at your company, and the change you want is that they actually apply rather than ignoring your job listing, then the actions you might take would include things like rewriting your job description to be more inclusive, offering accommodations for people with disabilities or flexible work-from-home arrangements for caregivers, or redefining the job role so that it can be fulfilled by a broader range of people.
For an IT project, the actions you brainstorm would generally involve writing code, and you’d probably proceed by sitting down at a keyboard. But the key—as with many initiatives the digital world—is to treat each activity as a hypothesis to be tested and validated. In other words, each potential action is a hypothesis that “if we change this, it will have a positive impact on the goal we set.” You create “minimum viable activities” that will allow you to test the hypothesis and then commit first to the activities that seem to have the largest impact.
Diversity, we’re suggesting, is an engineering parameter you can work to improve. Like other such parameters, it will improve the success of your company. Other ESG attributes—environmental sustainability, privacy protection, ethical behavior, good citizenship, broad stakeholder satisfaction—may be similarly amenable to such an approach, if you can find the right measurements. Perhaps surprisingly, you can use engineering thought processes to accomplish wider social goals like reducing homelessness or ensuring accessible services for people with disabilities.
We’ll throw a few specific ideas on the table here for possible activities around DEI. Treat these as hypotheses; start testing.
Fine-Tune What You’re Hiring For
Reexamine your hiring requirements: do they arbitrarily exclude groups of people (perhaps inadvertently)? For example, do you require a college degree for a position where it’s not really necessary? Do you require an arbitrarily high number of years of industry experience when the necessary industry knowledge could be gained through other ways as well? Are your job requirements based on the people you currently have in the role rather than a more expansive view of what skills could contribute to the organization’s success? You might be able to make more of your positions entry level1, with the remaining skills to be learned on the job, but it’s important to rethink your requirements for highly skilled positions as well, as those job descriptions are arguably even more prone to requirements “creeping in” that narrow the field unnecessarily.
An example will make this clear. Imagine a board looking to recruit a CEO and requiring that candidates be active CEOs of Fortune 100 retail companies with 20+ years of experience. Just those two requirements narrow the field to as few as 11 candidates they only consider pure retail companies (as opposed adjacent industries with retail subsidiaries). If the 20+ years of experience have to be in retail, the pool is narrowed even further. How diverse is that remaining pool likely to be? While the actual numbers may vary, this danger of extremely narrowing the pool is typical not just at Board or CEO level, but for the rest of the C-Suite and often the next level down.
You might find that certain roles would be improved by hiring candidates with diverse backgrounds, life experiences, and skills—for example, Mark thought it was crazy that his agency hired people without visual or other impairments to test the accessibility of their IT systems. Accessibility was considered something that could be achieved by complying with a set of requirements. On the contrary, the company should have treated accessibility as a matter of user experience and involved people with targeted disabilities in the design of their software.
How important are specific functional skills versus passion for the company’s mission or fit with its values? Hiring for passion and fit might open new labor markets. Or hiring people with particular lived experiences that are valuable to the company. On the other hand, it’s important to make sure that maintaining someone’s particular notion of company culture and fit don’t become an excuse for rejecting diversity. “Fit” is neither measurable nor data-driven and can easily lead us to biases that resulting hiring people that look, think and act like us rather than introducing diversity of thought and experiences. It’s also important to consider candidates’ abilities to learn new skills and to change—that is to say, their agility, which in the digital age may be more important than any particular skill set you’re looking for anyway.
When you’re hiring, are you looking for keywords in resumes, or do you let each candidate make a case for their fit in the resume and cover letter? Yes, it might take more work to review each resume and cover letter in depth—but it can also open you up to new ways of thinking about the role. Or are resumes reviewed by a separate recruiter or HR department that might not be familiar with your diversity goals? People who don’t know your diversity goals can’t act on them, so make sure those who review applications are familiar with your priorities and will work toward them with you.
Design for Inclusivity and Equity
Next, you might try exploring ways to be more inclusive. Consider coaching and development, not just for newly hired employees but for those already within the organization with the potential to move into senior roles. You might today be excluding groups simply because of geography or limitations of your workplace. Have you considered using remote work or satellite offices to recruit people in different locations? Or work-from-home and other flexible work conditions to include stay-at-home moms and dads and other caregivers? You might need to offer more accommodations for employees with disabilities, to make sure that diverse candidates can see themselves in the way you describe your job roles, and to locate and adjust employee behaviors that make some groups feel less welcome (team drinks on a Friday night are likely to make devoted practitioners of some religions feel excluded, for example).
Then test for equity. Do all employees have fair access to opportunities? If you crunch the numbers, do you see them taking equal advantage of those opportunities? Have you removed barriers to success and counteracted bias in your processes? Your goal for equity is to ensure all policies, practices, and systems provide all employees access to the opportunities, resources, and recognition to be successful. Apply the engineering mindset to how you solve for inequities throughout your organization.
Look in Other Places
When you’re hiring, where are you looking for candidates? In the same places you’d find candidates exactly like the people you already have in your organization? Have you thought about recruiting at historically Black universities? Or maybe looking in other geographies, with possibilities for relocation or remote work? What filters are you using for your searches on LinkedIn? Are your recruiters searching broadly, and are they incentivized to do so? Perhaps you can create apprenticeship programs or specific career paths targeted at the populations you’re trying to recruit. Or maybe reexamine your benefits packages and see if you can tune them to what is important for the groups you’re targeting.
Look at All Levels
You may find or suspect that you have higher levels of diversity at certain levels in the organization. It’s important to set and solve for diversity targets at all levels, from the board down to first-line employees; otherwise, you may find that you struggle to retain your diverse talent at lower levels because they don’t see anyone like themselves at the higher levels. Also consider building programs to identify high potential talent within the areas where you need greater diversity and invest in them to prepare them for new opportunities. You’ll want to monitor your success in moving employees across and up to address diversity at all levels and roles.
A Note on Goal Setting
We said we wouldn’t address goal setting in this post, but we can’t resist making a few points. If you were trying to fix latency issues—let’s say web pages that were taking 20 seconds to load—aiming for a 10-second load time would be pointless and ineffective. You’d be losing the same number of customers at 10 seconds anyway! Similarly, setting diversity targets based on, say, doubling representation of a particular population might sound big—but if they are 1% of your workforce now, doubling to 2% might not meaningfully contribute to the good business reasons why you are seeking diversity. A much better starting point might be to set targets based on the groups represented in your community, however you define it.
The Engineering Mindset
We’ve tossed out a number of actions you might take to help solve your DEI defects. Put some of them on your mind map of hypotheses and test them—with commitment to reaching your goals. In truth, we’re asking that all the brilliant engineers in your organization devote their attention to improving DEI, formulate ideas, test them, and report back to the group. We should all apply the creativity and rigor of engineering to what has proven to be a difficult problem. Engineering doesn’t conflict with humanity—we’re not saying that you shouldn’t be empathetic, ethical, and passionate. But we in technology have a problem, and engineers are problem solvers. Let’s see what we can do.
1 Our Amazon Web Services re/Start program, for example, trains unemployed and underemployed people in entry-level cloud skills and places them with companies that might have previously thought they needed employees with advanced skills.