Tag: inclusion

The Problem with Retrospectives

Photo by ThisIsEngineering on Pexels.com

I’m a huge fan of Agile retrospectives! Sitting with you on a sofa enjoying hot drinks, I might even feel like making the case that retrospectives are the most valuable and useful tool in the Agile kit. But, like most things, they don’t “just work.” It takes commitment, focus, respect, courage, and openness from everyone on the team. Oh, hai! Those are the Scrum values!

The problem is that I do mean everyone. One person, even if they are merely apathetic, can quickly turn retros into meaningless rituals. Because everyone in the room works toward the sprint goal, we need everyone to improve our capabilities to meet those goals. Whether we are missing information or getting bogged down in unproductive conflicts (there are plenty of productive disputes), we miss the keystone of a cyclical improvement process.

Let me put it another way. Agile is an empirical approach. Meaning, we improve by examining our processes, technologies, interactions, and productive output and then formulating theories on how to improve that we then put to the test. We take the evidence, construct a hypothesis, and then run an experiment to see if observations confirm our ideas or not. That’s the essence of science.

Photo by RF._.studio on Pexels.com

To analogize more, let’s say we want to know the most significant contributor to the cabbage growth rate. Maybe it’s the light spectrum, light duration, nitrogen levels in the soil, or water levels. Setting up this experiment with proper controls and sufficient samples is complicated. Not difficult. Just complex. We’ll end up with a big ole test matrix. Then we’ll have a bunch of statistics to run on the data we collected. Let’s consider our situation if one of the batches (an element in the test matrix) gets destroyed by aphids. We can’t use that data and will need to rerun the test and hope it doesn’t happen again. We could do something to prevent aphid infestation, but then we have to rerun all tests.

Photo by Egor Kamelev on Pexels.com

As someone facilitating a retrospective, you might find yourself in some troubled waters with no sightline to land. Your team’s got aphids. With all this mixing of metaphors, I’m not sure if we should break out the Neem oil or get a GPS! I’ll rein myself back in here. The point is that we will need to be a coach more than a note-taker or coordinator. We might even need to work closely with the individual team members’ managers. Helping everyone on the team express courage, openness, respect, and focus is our mission.

This work gets personal. And for some of our teammates, this isn’t the kind of work that we can help them with no matter how much trust and respect we share. For some, this is going to be the realm of their mental health professionals. We will have highly capable, high functioning, high performers who experience neurological diversities, survived traumas, or suffer psychological disorders on our teams. We might not be aware of their experiences and struggles.

Many of the Scrum values will present challenges for these folks. For example, expecting a survivor of childhood trauma to express courage by speaking candidly about their peers’ interactions in a group setting might not be realistic and certainly isn’t equitable. Coaching empathy to a person who’s physically incapable of feeling emotions the same way most people do is absurd.

As Agilists, we believe in the empowerment of teams and individuals. So, what can we do? Again, I want to point out that we might not even know that our teammates have these struggles. We might just see a jerk or a shy person, which are toxic personal judgments.

I’ve come to appreciate the ability of Liberating Structures to help empower more people. They aren’t perfect, but they help many people become more engaged by providing safer environments. But there are still opportunities for improvement. Many of the structures reduce or ease into group work. Most rely on handwriting. I’d love to see technological solutions that provide at least 1 step that is 100% anonymous and safe if not coordinating entire structures anonymously. In the current world of virtual meetings, something that integrates with Zoom’s breakout rooms would be marvelous! We won’t be able to remove interactions, but we can make them much safer for everyone.

Maybe that will end up on my project list. Or perhaps you’ll start an open-source project or a startup!

In the meantime, let’s remember the values are for empowerment. If we coach in ways that disempower or disenfranchise, we’ve missed the boat. Let’s keep modeling the behaviors we want to see from our team, coaching the Agile and Scrum values, and finding creative ways to empower everyone!

Categories
Leadership

Increasing Diversity and Inclusion in Tech Hiring

Photo by fauxels on Pexels.com

I’ve been fortunate to work with people who know and understand the value of diverse teams. For them, pushing forward diversity & inclusion wasn’t a question. Still, they didn’t always know how they could make a difference. There’s plenty of great resources about the value of diversity, especially in the Agile and DevOps spaces. And there’s a growing number of people talking about how to achieve these goals. As hiring managers, we have the opportunity to make a direct impact. Let’s explore a few ways you can make a big difference quickly and easily.

Diversity

A diverse team unified behind a compelling vision is a powerful force. When we think about diversity, we need to consider all of the ways we can diversify our teams:

  • Experience Level
  • Kinds of Experience
  • Education Background
  • Race
  • Gender
  • Sexuality
  • Neurology
  • Psychology
  • Culture

Any given candidate will overlap a few of these dimensions. Understanding how our hiring processes affect our candidates with varying backgrounds is the first step in making a difference. To do that, you need to talk with people about their experiences in interviews. What activities bring out anxiety or confidence? Which elements of the job description bring out hesitation or excitement? What blind-sided them?

The more we let ourselves feel what they feel, the more effective we become. Don’t just recognize what the candidate might feel. Feel it. Relate it to your own experiences. When we do this, we grow our ability to lead with empathy.

Their Best Self

Our goal is to give as many candidates as possible the chance to show their best selves. We know that making a bad hire is incredibly expensive. That’s why we’ve put up so many roadblocks to landing the job. Screening, minimum experience, homework, behavioral interviews, whiteboard exercises, and all the rest are there to protect us from a bad hire. What’s less understood is that failing to hire a great candidate is also very costly!

For the sake of illustrating the point, let’s assume the position is expected to generate $800k in value each year, costs $200k to employ, and $60k to hire. We’re expecting the first-year gain to be $540k. Every day that role is unfilled is costing us a little under $1.5k. That might not sound like a huge number, but consider if the position went unfilled for a year and what that half-million could’ve done for our employees, investors, and customers. The cost of delay is just the tip of the iceberg.

Missing a great hire adds a multiplier. When we talk about great hires, we are talking about people who will consistently exceed our expectations. They are somewhere within the top 25% on the performance bell curve. In software, Steve Jobs believed the difference between an average developer and the best was between 50:1 and 100:1. But for our illustration, let’s stick to something closer to normal, the 2:1 great hire. Using our same assumptions above, now we are talking about $1.4M per year in gains.

The average cost of a bad hire is between 30% of their first-year earnings and $240k. That’s a massive range! For our thought experiment, let’s go big. Cutting to the chase: We could make four bad hires and still be ahead if we make one great hire! It’s like holding the Ace and King of hearts, and the flop has two of our suit and no pairs. Raise! Re-raise! All-in! Let’s go! It’s even better, however. Assuming a normal distribution, more candidates are in the average and above-average group than in the below-average grouping.

Yes, a bad hire is expensive but not nearly as expensive as missing great employees. If we aren’t giving our candidates the best chance to succeed, we are missing great hires.

Relationship to Diversity and Inclusion

What does this have to do with hiring women, people of color, or other underrepresented people? Why’s it that I’ve met so many peers who want to increase their teams’ diversity but complain of a lack of qualified candidates?

While there are many sources of a lack of diversity and inclusion in tech, one is our hiring rituals. Underrepresented people don’t always come from traditional backgrounds. When I say traditional, I mean things like going to college for a computer science degree at a university known for their technology programs. Then, coming out of school directly into a paid internship at Google. And finally, being hired as a software engineer a year later.

Suppose our minimum requirements are a 4-year C.S. degree and one year of experience. Great candidates without one or both these might not even apply. As hiring managers, we won’t even see their resume even if they do apply!

It gets even worse. Sometimes, the language we use in the job description turns candidates away. Let’s compare two bullet points:

  • Confidence in refactoring legacy code to be testable and extendable.

vs.

  • Demonstrates the ability to refactor legacy code to be testable and extendable.

Suppose our candidate learned at a young age that being confident is rude, or they didn’t deserve confidence. In that case, that candidate isn’t going to respond to the first bullet. We can even take it a step further by improving the second bullet.

  • Ability to change existing code so it is easier to test and change in the future.

Did you see what’s happening here? We removed the insider jargon. A candidate might have the skills to refactor but never heard that word before. They see that and might say, “I’m not in the club. I’m not qualified. I don’t even know what refactoring is!”

So far, the good news is these are simple changes that don’t alter what we are looking for but do broaden our audience. But we have to get back to the bad news.

Often, our interviewing techniques reinforce our apparent desire for the traditional background. Schooling isn’t a bad thing, but it isn’t the only way. Formal education focuses on skill development and traits in particular areas. In school, you are rewarded disproportionately for completing assignments regardless of the quality and for the ability to memorize and recall specific and sometimes arbitrary information. If our interviewing activities are heavily biased toward recall, then we are biased toward a traditional background. And any activity that resembles a test is in the same boat.

I’m only skimming the surface here, everyone. This goes deep. It even gets cultural. While I’m passionate about this topic, I don’t want to lose you before we can get back to the good news. We can make simple but significant changes to increase our exposure to great candidates from any background.

Practical Easy Solutions

Nothing here will change the world, but it will open up more opportunities to more people. If more of us do this, then it will make a difference to someone.

Job Descriptions

Think of this document as a one-page marketing sheet. The purpose is to attract great candidates, whoever they are, and from whatever background. This isn’t our shield or mote. It’s a flashing neon sign on a dark empty horizon.

Here are the easy gains:

  • Write to a more general audience unless you require a specialist.
  • Minimize the use of language that reinforces a traditional background.
  • Remove language that requires the candidate to feel a particular way about themselves.
  • Read the HBR Guide to Better Business Writing.
  • Have someone review it who works in communications or marketing.
  • Review it with your recruiter and let them know your goals.
  • Don’t water down the skills needed!

Technical Screening

This screening is our best chance of avoiding the costs of someone who simply misrepresented their skills. But the means we use can exclude great candidates.

Here are the easy gains:

  • Provide more than one way to do a technical screening. Yes, this requires work on our part. Great candidates are worth it!
    • Submit a take-home screening
    • Take an online assessment that allows the use of resources.
    • In-person tech screening where the candidate receives an outline ahead of time. And they can ask questions and use resources while performing the screening.
    • Submit a personal project or open-source commits
  • Focus tech screening on the skills that are most used in the role. If the position doesn’t regularly involve Calculus, don’t screen on knowledge of Calculus.
  • Don’t screen on the ability to recall. And especially not the ability to remember under stress.

If you’re wondering if an engineer who can recall any given function’s positional arguments is more efficient than one who uses their IDE or references, I would say yes on the surface. What’s more important for efficiency is deploying the correct and legible code once. If efficiency is a high priority, then a slower programmer who is more accurate and produces more maintainable code is a better choice.

The Interview

Let’s start by getting specific about what our engineer needs to be able to do. The skills required should be clear after analyzing the product and the team’s strengths and weaknesses. Suppose we aren’t innovating new search algorithms, or we already have an algo wizard. In that case, we might not need someone who can recall the different pros and cons of various pivot points in a quicksort. I’d argue that we don’t since these are solved problems. You don’t come up with a physics theory that challenges common experience by memorizing the speed of sound.

As a pre-teen and teenager, my life was music. It’s all I cared about. I put countless hours into learning, practicing, and enjoying all things music. One afternoon I was hanging out in the high school symphonic band room waiting for a friend before going to jam. I was at a drum set doing a sticking exercise. The exercise was tricky because it combined flams and paradiddles. My band director came out and said something to this effect, “Aaron, I don’t understand you! There are times you amaze me, but then you struggle with some of the basics in the symphony band.”

My background didn’t prepare me for playing the symphonic snare drum or any melodic percussion instruments. While my director was a percussionist, her experience didn’t prepare her to play drums in an alt-metal band.

What’s happening in many engineering interviews is this: We need to hire a drummer for an indie-pop band. During auditions, we have a section on sight-reading marimba. And on music theory. Then, they have to play an Opeth song. Finally, we test the drummer on public speaking skills. At least three of the four are tangentially related to the role. But what are we going to learn about their ability to play in this band?

What should the audition (interview) look like? The band would send the candidate a setlist of their songs ahead of time and what they will do during the audition. Maybe the band would ask the candidate to learn the songs note for note or add their style. During the audition, they would play through the setlist together—probably a few times for practice and soundcheck, then a rehearsal. Then, there might be time for freeform jamming to see if the band can “click” with the new drummer. Finally, there might be a section of the audition where there is songwriting or learning a new song together. During these activities, the band is observing the skills and working style of the candidate. How do they manage frustration or another member making a mistake? At some point, they would spend time with the candidate to see if they get along outside of the working environment. It would probably take all day. After going through the process with several candidates, the band would deliberate and weigh their options.

Not all bands do this, but it’s a great way to run an audition. An audition is a job interview. What makes this audition so fantastic?

  • The candidate has all the information about what they will need to do ahead of time, with plenty of time to prepare.
  • There is no pop quiz. The open-ended activities are planned and communicated.
  • The content of the activities is directly related to the day-to-day job.
  • The candidate is evaluated in the most common setting they would be working in. They aren’t sitting in front of a panel that isn’t participating in the work.

I have come to love the “project-based interview” for evaluating engineers. Here is a summary of one such interview:

  • The candidate was screened with a take-home that could be completed within 2 hrs. This was tested beforehand by myself and my team members.
  • The candidate was also given a description of the project they would work on during the in-person interview and how the interview would be conducted.
  • The candidate sat with the team in our typical pod.
  • The candidate was assigned a pair-programming partner every 45 minutes with a 15-minute break in between.
  • The candidate could use any available resources.
  • After three pairing sessions, there was a group code review. The candidate was asked to start by showing areas they would want to improve in another iteration, how, and why.
  • 1-hour lunch break with the choice to have it solo or socially with the team.
  • 1-hour behavioral interview with a couple of selected members of the team.

This interview mirrored our working environment. We paired often and did quick group code reviews huddled around a desk or big monitor. The project was a refactoring exercise because we had older software that we needed to be moved to the cloud. The candidate had patents, and OSS commits that I could examine. I didn’t need to waste time quizzing them on data structures.

While this specific interview fit the team, it isn’t the most inclusive. To up the inclusion, we should make pairing and group code review optional. We still want the review, but allow the candidate to decide how it will be formatted. Giving options around group activities can have an impact on people with neurological or psychological diversities. As leaders, we know the value of empowering our employees with ownership. Why not empower our candidates?

Sourcing

Looping back around to the beginning of the process, we have sources of candidates. Recruiters know their craft. Let them know you want to diversify your team. Ask them about organizations like ChickTech! Partner with your recruiter and organizational leadership to diversify the sources for internships.

Quick List:

  • Don’t require interns to be recent college graduates.
  • Source half of all interns from organizations like ChickTech.
  • Ask your recruiter if they can use a solution like Sourceress that allows you to source diverse candidates directly.

Closing Thoughts

When it comes down to it, the conversation about diversity and inclusion is about empowerment. We can empower more candidates from more backgrounds, or we can narrow the door so only those who conform to our biases can pass through. It happens that there are excellent business outcomes associated with team diversity. There are also solid financial reasons to shift our hiring stance from fear to opportunity. While one of us might not change everything that creates a lack of diversity in tech, we can do something about it.

There’s no excuse. I hope you consider broadening the horizons of your hiring processes!

Exit mobile version