Diversity University
- Posted by: Dave Collins
-
Perhaps the single greatest aspect of working in technology on a day to day basis is the undying realization that absolutely anything is possible. Have you taken a few moments to consider the fact that, with the right team, funding, and time, technologists can accomplish anything? We have seen so many once-thought-impossible feats achieved through technology (Deep learning, robotics, DNA sequencing, GPS, ... the list is endless) that I don't know how anyone could take the stance that something "will never happen" after witnessing the technology explosion of the past decades.
What is illuminating, though, is how important having the right mix of engineers can be to the success of a technology project. But what does "team mix" mean, exactly? Critical to that "right mix" is the makeup of the personalities of the individuals that form your engineering teams. Team diversity (and here I speak not only of diversity of gender and race, but also of background, education, talent, and personality) is absolutely critical if you seek incredible solutions to challenging problems.
If your team is architecting a complex technology solution to a thorny problem, do you want all of the team members coming at the problem with the same potential solutions? Or would you prefer a few of those team members proposing seemingly outlandish ideas? I definitely want the team where there is some open discussion regarding the solution set -- the most typical solution is not always the best! What if almost every engineer is proposing that we "roll our own" architecture layer, and one engineer does a few hours of work and finds out there are three open source projects that already cover 90% of the target need? Yes! I absolutely want to have a thorough discussion of those pros and cons! Do you want everyone showing up promptly at the same time and leaving at the same time? Or do you want a mix of morning people and night owls? Which team is more likely to notice a problem brewing in production at 1 AM?
An analogy I have for teams and their composition is in relation to a rental property my wife and I used to own: The property was a small house about 20 minutes away from where we lived -- just long enough of a drive to make it a real pain if you got out there, started a project, and then realized you are missing one tool needed to finish a simple job. Over several years of ownding the property I worked diligently to try to put together a tool kit that would fit in my trunk and also allow me to handle 99% of any issues that arose if I was visiting the house to do some work. You would think that just the basics (saw, wrench, pliers, screws) would pretty quickly cover everything, but you would be amazed at how many times you need just one more small thing to do a job well: drill, extension cord, 12 gauge electrical wire, wire nuts, hand saws, tape, epoxy, etc. The list goes on and on but the lesson is clear: To accomplish challenging tasks you need a broad range of skills some of which may be meaningless for a large portion of your work, but will become absolutely critical at certain points.
To accomplish challenging tasks you need a broad range of skills some of which may be rarely used for a large portion of your work, but will become absolutely critical at certain points.
This concept of diverse backgrounds being important to technology development is probably one of the reasons that software engineering is so forgiving during the hiring process. Do you require Computer Science or Engineering degrees of your prospective engineers? Perhaps you do require those degrees, but there are certainly many companies that will hire technologists without CS degrees. Think about that fact for a moment: There are not many professional specialties that are as forgiving of educational background as Tech. ("Oh, you want to apply for our therapist job but you have a degree in Chemistry? No problem!") In Tech we are much more likely to ignore formal education and focus on coding skills. Technical education is awesome (and preferred) - it helps ensure that the basic concepts of software development (data structures, machine organization, systems architecture, etc.) have been covered - but what really matters: "Can this person code? Can this person design code? Does this person have experience solving the kinds of problems we are trying to solve?". This broad range of backgrounds becomes even more important when considering business analysts and QA resources - you need and want people who can give concrete accurate technical feedback to the engineering staff, and can also have meaningful exchanges with non-technical individuals from the business and user community.
Another easy-to-implement improvement to team makeup is having at least a small portion of the team working offshore or remotely in a different timezone. Having even just a few employees in a different time zone expands the regularity at which your software can be improved. When you have a portion of your team working 6 or more hours offset, a new and interesting cadence emerges: Problems found during the workday here can be addressed overnight by the remote team and this cycle can bring an amazing improvement in velocity. Developers start their day with automated test suites green and on the latest code (well, at least on some days!).
Now how about the gender composition of your teams? You know it: We cannot avoid discussing the Gender imbalance in the Tech world. The U.S. Census (2014) indicates that 50.8% of the workforce is comprised of women. According to the National Center for Women in Technology only 25% of the tech workforce is composed of women. Why the huge gap?? There are numerous reasons for the gender gap, but if you read blog posts and watch the twitter feeds of women developers you can quickly get a pretty good feel for some of the main problems: Part of the discomfort women may feel in the engineering workplace can be attributed to the "old boys club" mentality: Tech conferences where the women's rooms have been commandeered by men ("Hey there just aren't that many women here!"), developer terms like "Brogrammer", and questionable comments and jokes in the workplace. Look: I am a man, and I am neither prudish nor puritanical, but there is a time and a place for boys-locker-room jokes and the workplace is neither the time nor the place! It takes only the tiniest amount of foresight and self-restraint to eliminate sexual innuendo from a workplace - we aren't talking about a massive effort required by men to make the workplace more tolerant of gender diversity.
Which brings us to Frances Northcut (pictured above). Frances was a female engineer (in fact the first female engineer) working in NASA's mission control. Frances worked during the Apollo 8 mission, which was the first mission to actually send humans in orbit around the moon. Prior to Apollo 8 all of the manned space missions were simply Earth orbits, and the Apollo 8 engineering team had the stomach-churning task of planning and executing an orbit that had a crew safely leaving earth, correcting for a moon orbit insertion, orbiting the moon (at times being without any radio communications or telemetry), escaping the moon orbit and executing burns for a safe return to earth. Piece of cake! Can you imagine the pressure on Frances being one of the only female engineers on that team? How much of the "This is a man's job" mentality that Frances dealt with still reigns on engineering teams today? How much of that mentality accounts for the huge gender gap in technology teams today? The great thing is that this aspect of the problem is easily solved: Just step up your game a little bit regarding your conversations in the workplace. By the way, just to follow up on Frances Northcut: Frances didn't stop at being a NASA engineer. While still working for NASA contractor TRW, she obtained a law degree from the University of Houston. Would you want Frances on your engineering team? (That was a rhetorical question, and the answer is "Yes!")
OK, Dave, you are just blathering about team diversity... You gave some examples that intuitively make sense, but what about statistics? Thare are Plenty: A 2010 Study by Mckinsey examined well-recognized financial performance metrics (ROE and EBIT) of over 180 international companies over 2 years. Overall the companies in the top quartile of diversity (this study measured Gender and Ethnic diversity) had 53% better ROE and 14% better EBIT performance than the bottom-quartile companies. The differences were even more striking if looking in the U.S. Only: The U.S. Companies in the top quartile had 95% better ROE and 58% better EBIT performance than the bottom-quartile companies! In a 2013 study by Coqual (formerly the Center for Talent Innovation), they broke diversity into two dimensions: Inherent (e.g. Gender, Race, ...), and Acquired (e.g. Cultural Fluency, Technical Literacy, ...). Comparing companies with high levels of "2D Diversity" (teams with both Inherent and Acquired diversity), the CTI study found that companies with high levels of 2D diversity were 45% more likely to improve market share during the study period than companies with low 2D diversity levels.
So here we have a rarely-found and refreshing nugget of business wisdom... Powerful and useful, yet simple to implement: Diverse teams come up with a wider variety of potential solutions to the business problems you are trying to solve, and have been proven to increase the financial performance of their parent companies. You want your teams as diverse as possible regarding background, education, work habits, race, sleep patterns, talent, gender, and geographic location. Your effort in creating and maintaining such diverse teams will be rewarded with creative and profitable solutions to your engineering challenges.