A couple different talks at OSCON got me thinking about the unhealthy results of hiring on the basis of “culture fit”.

What is company culture? Is it celebrating with co-workers around the company keg? Or would that exclude non-drinkers? Does your company value honest and direct feedback in meetings? Does that mean introverts and remote workers are talked over? Are long working hours and individual effort rewarded, to the point that people who value family are passed up for promotion?

Often times teams who don’t have a diverse network end up hiring people who have similar hobbies, backgrounds, and education. Companies need to avoid “group think” and focus on increasing diversity, because studies have shown that gender-diverse companies are 15% more likely to financially outperform other companies, and racially-diverse companies are 35% more likely to outperform. Other studies have shown that diversity can lead to more internal conflict, but the end result is a more productive team.

How do you change your company culture to value a diverse team? It’s much more than simply hiring more diverse people or making people sit through an hour of unconscious bias training. At OSCON, Casey West talked about some examples of company culture that create an inclusive environment where diverse teams can thrive:

• Blame-free teams
• Knowledge sharing culture
• Continuous learning
• No judgement on asking questions
• Continuous feedback
• Curiosity about different cultures
• Individually defined work-life balance
• Valuing empathy

For example, if you have a culture where there’s no judgement on asking questions or raising issues and people are naturally curious about different cultures, it’s easy for a team member to suggest a new feature that might make your product appeal to a broader customer base.

The other problem with “culture fit” is that it’s an unevenly applied standard. An example of this was Kevin Stewart’s OSCON talk called “Managing While Black”. When Kevin emulated the company culture of pushing back on unnecessary requirements and protecting his team, he was told to “work on his personal brand”. White coworkers were reading him as “the angry black guy.” When he dialed it back, he was told he was “so articulate”, which is a non-compliment that relies on the stereotype that all African Americans are either uneducated or recent immigrants.

In both cases, even though his project was successful, Kevin had his team (and his own responsibilities) scaled back. After years of watching less successful white coworkers get promoted, he was told by management that they simply didn’t “see him in a leadership role.” Whether or not people of color emulate the white leadership behavior and corporate culture around them, they are punished because their coworkers are biased towards white leaders.

As a woman in technical leadership positions, I’ve faced similar “culture fit” issues. I’ve been told by one manager that I needed to be the “one true technical voice” (meaning as a leader I need to shout over the mansplainy guys on my team). And yet, when I clearly articulate valid technical or resourcing concerns to management, I’m “dismissive” of their goals. When I was a maintainer in the Linux kernel and adamantly pushed back on a patch that wall-papered over technical debt, I was told by another maintainer to “calm down”. (If you don’t think that’s a gendered slur based on the stereotype that women are “too emotional”, try imagining telling Linus Torvalds to calm down when he gets passionate about technical debt.)

The point is, traditional “cultural fit” narratives and leadership behaviors only benefit the white cis males that created these cultural norms. Culture can be manipulated in the span of a couple years to enforce or change the status quo. For example, computer programming used to be dominated by women, before hiring “personality tests” biased for men who displayed “disinterest in people”.

We need to be deliberate about the company culture we cultivate. By hiring for empathy, looking for coworkers who are curious about different cultures, and rewarding leaders who don’t fit our preconceived notions, we create an inclusive work environment where people are free to be their authentic selves. Project Include has more resources and examples for people who are interested in changing their company’s culture.

When our users move existing machine images to the cloud for use on Amazon EC2, they occasionally encounter issues with drivers, boot parameters, system configuration settings, and in-progress software updates. These issues can cause the instance to become unreachable via RDP (for Windows) or SSH (for Linux) and can be difficult to diagnose. On a traditional system, the physical console often contains log messages or other clues that can be used to identify and understand what’s going on.

In order to provide you with additional visibility into the state of your instances, we now offer the ability to generate and capture screenshots of the instance console. You can generate screenshots while the instance is running or after it has crashed.

Here’s how you generate a screenshot from the console (the instance must be using HVM virtualization):

And here’s the result:

It can also be used for Windows instances:

You can also create screenshots using the CLI (aws ec2 get-console-screenshot) or the EC2 API (GetConsoleScreenshot).

Available Now
This feature is available today in the US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), and South America (Brazil) Regions. There are no costs associated with it.

— Jeff;

 

5,000 years ago on a terraced slope above the Chan River in Shaanxi Province, China, some enterprising villagers built two sophisticated beer brewing kits. stills. Part of the Mijiaya site, once the location of a thriving civilization, both kits stills were housed in pits sunk 2 to 3 meters into the ground, lined with rock, and accessed by stairs. One is fitted with a small shelf, and both have ceramic ovens for brewing in wide-mouthed pots that once held boiled barley. Archaeologists found other telltale beer-brewing tools (all tools, all covered in an ancient yellow residue), residue, including funnels for filtration and amphorae, or cocoon-shaped containers, for fermentation. After careful analysis of plant and chemical remains on the inside of these storage containers, the scientists reported in Proceedings of the National Academy of Sciences  Science that they had a pretty good idea of what kinds of ingredients went into this ancient beer.

Most of these ingredients will sound familiar to beer lovers. The scientists They found traces of broomcorn millet, barley, Triticeae (wheat), and Job’s tears (a grain plant often called Chinese pearl barley, though it is not actually barley), plus small amounts of snake gourd root and lily (both are tubers often used in Chinese medicine), as well as yam. It's possible that the yam was added to enhance what was probably already a slightly sweet brew due to the barley. What impressed the archaeologists was that people living 5,000 years ago during the Neolithic Yangshao period had already mastered a pretty sophisticated system for brewing, including temperature regulation. This finding pre-dates by thousands of years the earliest writing about fermenting beer, which comes from Shang Dynasty manuscripts circa 1240-1046 BCE.

In their article, the researchers write that all the evidence they examined indicates that "the Yangshao people brewed a mixed beer with specialized tools and knowledge of temperature control. Our data show that the Yangshao people developed a complicated fermentation method by malting and mashing different starchy plants." This discovery may also shed light on a longstanding mystery about how barley came to Eastern China from Western Eurasia. By the time of the Han Dynasty, roughly 200 BCE, barley was already a popular crop. But what would have motivated early farmers to bring this grain all the way across the Central Plains? Apparently, it was for partying, not for eating. Write the archaeologists:

It is possible that the few rare finds of barley in the Central Plain during the Bronze Age indicate their earlier introduction as rare, exotic food. The Mijiaya farmers probably obtained small quantities of barley grains through exchange or cultivated the plant along with other cereals. We suggest that barley was initially introduced to the Central Plain as an ingredient for alcohol production rather than for subsistence.

This also suggests that competitive feasting and relatively complex social structures were already in place during the Mijiaya site's heyday. These brewing kits, stills, and the beer recipe itself, appear to be the outcome of many generations of people testing recipes to create the perfect Neolithic neolithic alcohol-making system.

Proceedings of the National Academy of Sciences, 2016. DOI: 10.1073/pnas.1601465113

Read Comments

Job Announcement Number:
16-CFPB-419-P
Location Name:
Washington DC, District of Columbia
Agency:
Consumer Financial Protection Bureau
Occupation Code:
Information Technology Management
Pay Plan:
CN
Appointment Duration:
Full-time
Opening Date:
Friday, May 20, 2016
Closing Date:
Friday, June 3, 2016
Job Status:
Career/Career Conditional
Salary:
$200,596.00 to $247,500.00 / Per Year
Pay Grade(s):
82 to 82
Who May Apply:
U.S. citizens ; no prior Federal experience is required. This opportunity is also open to Status eligibles under Announcement 16-CFPB-418 . Please refer to that announcement for details on open period, eligibility, and how to apply.
Job Summary:
The Assistant Director for Technology and Innovation, Chief Information Officer (CIO) is the CFPBs senior leader for all aspects of technology at the Bureau and reports to the Chief Operating Officer. The CIO serves as the principal advisor to the Director and the Bureaus Executive Leadership on all matters related to technology at the Bureau. The role is a hybrid of a traditional CIO, providing services that support the Bureaus operations, and a Chief Technical Officer (CTO), responsible for the technology that amplifies CFPBs mission effectiveness.

Death by GPS (Ars Technica):

What happened to the Chretiens is so common in some places that it has a name. The park rangers at Death Valley National Park in California call it “death by GPS.” It describes what happens when your GPS fails you, not by being wrong, exactly, but often by being too right. It does such a good job of computing the most direct route from Point A to Point B that it takes you down roads which barely exist, or were used at one time and abandoned, or are not suitable for your car, or which require all kinds of local knowledge that would make you aware that making that turn is bad news.

It's a longish piece that's worth a read. However, it seems that a lot of these GPS horror stories--many from the US West--are as much about visitor expectations of what constitutes a "road" as anything else. It's both about the quality of the underlying data and its interpretation, things that apply to many automated systems. 

According to Hacker News commentator Doctor_Fegg:

This is clearly traceable to TIGER, the US Census data that most map providers use as the bedrock of their map data in the rural US, yet was never meant for automotive navigation.

TIGER classes pretty much any rural "road" uniformly - class A41, if you're interested. That might be a paved two-lane road, it might be a forest track. Just as often, it's a drainage ditch or a non-existent path or other such nonsense. It's wholly unreliable.

But lest you think data problems are in any way unique to electronic GPS systems, read this lengthy investigation into a 1990s Death Valley tragedy.

For what it’s worth, I did some cursory examination into what Google Maps would do if I tried to entice it into taking me on a “shortcut” through the Panamint Mountains in western Death Valley. My conclusion was that it seemed robust about not taking the bait; it kept me on relatively major roads. However, if I gave it a final destination that required taking sketchy roads to get there (e.g. driving to Skidoo), it would go ahead and map the route.)