Designing an engineering team: Making room for everyone

by Jack Danger

In his talk at RubyConf 2018, Jack Danger addresses the challenges of designing engineering teams that appreciate diversity and leverage unique skills. He emphasizes that while the traditional view of roles within engineering teams often simplifies them to a manager and a tech lead, the reality includes a broader range of specialists like technical experts and mentors. Danger argues against the simplistic hiring practices that judge candidates by vague standards, calling into question the idea of a 'real engineer' or a fixed hiring bar.

Key points discussed include:
- The diversity of skills in software engineering, where each individual may only be competent in specific areas, making it ineffective to assess talent based on generic standards.
- Importance of using interview techniques that allow candidates to demonstrate their unique skills, such as asking them about code they admire.
- Drawing parallels to other fields like aviation and medicine, Danger underscores how defined roles and responsibilities lead to better outcomes. He notes that in contrast, software teams often lack this structure.
- Effective teams adapt to varying requirements, possess a clear direction, and include members focused on customer needs. Successful teams often include junior members or learners who bring fresh perspectives.
- Danger highlights that there is no linear progression to mastery in engineering, and thus, hiring should focus on the actual skills needed for a role rather than on arbitrary benchmarks.

In conclusion, Danger encourages a reevaluation of hiring practices, advocating for recognition of the diverse paths engineers take. He reminds the audience that the engineering field thrives on unique contributions and that fostering a collaborative environment based on varying skills can lead to more effective teams. The key takeaway is that the notion of a 'real engineer' is a myth; real success lies in appreciating each engineer's unique skills and experiences.

00:00:15.289 Alright, so Meghan, thank you for that introduction. I think I wrote that blurb when I was feeling insecure, because that's the most dramatically positive view of my career that one can have.

00:00:21.480 Other takes are, I have a linguistics degree because I'm terrible at career planning. So somewhere in the middle is the truth.

00:00:27.930 My name is Jack Danger. I lead infrastructure engineering at Gusto. We do payroll, HR, and benefits, and there's a lot of companies out there now that are not on the right side of the axis of scalability.

00:00:42.170 We have a lot of simple data mixed with some extraordinarily complex and important data. So some of you may be in this place as well.

00:00:49.079 Ruby is a really good language for those kinds of problems, and Gusto has a lot of them. I'm talking about scaling teams, interviewing, skills, and people.

00:01:00.090 This talk is sourced from the frustrations of myself and many of my dear friends and colleagues over the last couple of decades.

00:01:13.130 How many of you have been asked questions during an interview that you know in no way correlate to on-the-job performance?

00:01:19.409 Okay, some hands raised. I wasn't sure if anyone would raise their hands, so I phrased this as maybe rhetorical, but thanks for participating.

00:01:31.259 And how many of you knew during an interview that you had skills and knowledge that the company totally needed, and nobody asked you about them, and nobody allowed you to show them?

00:01:49.040 So, we're going to talk about designing engineering teams in a way that's different from what we've used in the industry in the past.

00:01:57.350 As I mentioned, this talk is based on the experiences of many of my colleagues and friends who have felt underappreciated and misunderstood at work.

00:02:02.780 This effect is pronounced for people who do not present as white, straight, or male, but it absolutely affects everybody.

00:02:10.100 The solution is not simply to hire great engineers. Oh no, that's too simplistic and quite honestly terrible.

00:02:21.950 The idea that there's a great engineer out there or that there's some magic formula for becoming a 'real engineer' is the core problem that we're facing in our interviews.

00:02:32.780 This is why we get phrases like 'ninja', 'rock star', and 'guru' in job descriptions, someone looking for someone amazing.

00:02:39.380 But you can't hire great engineers simply because the phrase 'great engineer' itself is so vague that it obfuscates what truly makes someone effective in a role.

00:02:45.500 Software engineering is a massive field, encompassing thousands of skills and hundreds of domains. Each company operates in just a few of them, and each of us is only competent in a few of them.

00:03:12.050 There are engineers out there with no overlap in their skills with one another. Here's a hypothetical example.

00:03:28.239 This is not dissimilar from experiences I've had in my career. I was at Square for a long time, and we had a lot of people from different backgrounds come in.

00:03:41.690 Let’s say Jordan went to Stanford, earned a CS degree, and knows how to balance a binary tree. In their CS final, Jordan was asked a question about binary trees.

00:03:54.200 Then Jordan and colleagues all interviewed at a big company, where the interviewer asked them to work with binary trees. Jackpot! That's straightforward software engineering.

00:04:06.620 But then they get on the job and meet Kelly, who graduated high school, did not go to college, and spent the first 15 years after high school working at a bookstore. Kelly is the only person in the company who actually knows how to use GraphQL.

00:04:21.750 Jordan knows C, Java, and Ruby; Kelly knows C++, JavaScript, and Go. The question is, which one of them is more senior? One of them is older, but that's not really a factor.

00:04:38.270 A better question is: which one of these people is qualified to interview the other? Would either of these people pass each other's interview bar? And therein lies the problem.

00:04:53.150 I’ve heard this at many companies. They claim they want to have a high bar for their talent—"We have a higher engineering bar!" They even say, "We don't lower the bar for some candidates." Oh really? So, the bar is...? You have to have grown this direction that far? Is that how it works?

00:05:14.870 There are two lies hidden in the idea of a hiring bar. One is that people have an inherent ability to meet that bar, meaning if you could get someone brand new to solve a complex problem during an interview.

00:05:26.810 The other lie is that people grow linearly. There is no single bar that one must pass. It is simply not the case.

00:05:45.860 Let’s take a quick look now at the various skills involved in Rails.

00:05:51.410 This is a graph of skills related to working with Ruby on Rails, from a couple of years ago, created by a good friend of mine, Brook Rego, at Code Fellows in Seattle. I appreciate their curriculum.

00:06:09.990 Let’s zoom in a little bit. In one corner, there's working on the command line, managing operating system files, using commands like 'chmod', and running bin stubs within your Rails root directory.

00:06:18.680 It's important to know this stuff, but could you get by without it? Sure, objectively. A lot of people don’t know these things.

00:06:35.780 On the other side, there are Ruby gems and package management. Someone on your team needs to know that. Not everybody needs to know it, but it's nice to have someone around who can debug it. That said, a huge mass of skills exists. Which ones are core skills?

00:06:54.830 We'd all agree that some of these skills are ancillary, not necessarily required. Which of these core skills must everyone possess to get through the door at your company? Well, obviously, it's project management and licensing.

00:07:08.630 We can also add knowledge of browser quirks and working with SASS—those are skills that everyone must possess.

00:07:14.330 Now, let's consider if someone comes in with 20 years of experience in the video game industry. Can they be effective in a Rails job? I don't know, but that’s a problem we need to figure out.

00:07:26.870 So, what are we doing to hire? I think what actually happens is we look for the overlap between ourselves and the other candidates.

00:07:39.190 The more overlap there is, the more talent we perceive they have, because we can see that talent. The overlap becomes our signal. I know how to use this technology; you know how to use it; therefore, we can work together.

00:07:51.560 A truly exceptional candidate can succeed in this environment because they know so much that interviewers will inadvertently ask something that this person is familiar with.

00:08:05.930 But you know who else succeeds at the same level or even better? Someone with a similar background. If someone says, 'Hey, I learned this at Stanford; can you do this thing?' and you say 'Yes', well, great!

00:08:14.400 But nobody's not redundant. Who can't succeed? People who have different backgrounds, whose skills and knowledge are absent from your company. These are the people you most need to hire.

00:08:23.890 But how do you get them in the door without lowering the bar? Everybody wants to work with smart, capable individuals who they feel are contributing to progress, so how can you determine if someone can carry their share of the load?

00:08:40.520 What can we, as peers, do? None of this became clear to me until well into my career, about ten years ago, when I hated algorithm questions.

00:08:49.680 I struggled with them because I didn't understand data structures or algorithm complexity. Instead, I had a favorite question I asked early in my time at Square: 'Tell me about some source code you didn't write that you appreciate and why.'

00:09:00.750 It was a great question, especially for those who engaged with open-source software. Reading others’ code helped foster my sense of taste in API design and code organization.

00:09:14.440 Yet, some candidates who completely failed that question went on to lead teams at the company. One even implemented a database from first principles.

00:09:31.800 Another candidate had a PhD in Computer Science from Stanford and worked on the Closure Compiler. However, they offered no insight on interesting source code, despite their skills being impressive in different areas.

00:09:49.410 Now, with more experience, I realize we were all experiencing a version of the Dunning-Kruger effect; junior people struggle to evaluate seniors, and seniors often mistake their skills as easy for everyone.

00:10:03.080 As I developed my skills, I found more overlap between myself and others, as I realized each candidate I interviewed seemed exceptional and could offer unique contributions.

00:10:16.600 I also recognized how they could fail because I could think of someone similar who thrived at the job despite doubts about their qualifications. This led to interesting conclusions about our hiring and evaluation processes.

00:10:31.230 Let’s pause for a moment and examine aviation, an industry that has much to teach us.

00:10:37.890 In aviation and medicine, people learn for a long time to do their jobs correctly—because in both industries, lives are at stake.

00:10:50.740 100 years ago, aviation started with pilots flying over World War I fronts in open cockpits, dropping dynamite.

00:11:02.320 Fast forward to today, and commercial air travel is exceptionally safe—2017 saw zero commercial jet aviation deaths globally.

00:11:14.610 How did they achieve this extraordinary feat? The path was simple: they figured out what needed to keep a plane in the air, organized people into specific roles, and trained them.

00:11:25.520 When it comes to medicine, they are still figuring out safety protocols despite advances like the Checklist Manifesto, which Atul Gawande advocates.

00:11:36.800 Aviation can teach us one valuable lesson: clearly defined roles and responsibilities lead to improved outcomes.

00:11:49.920 An operating room today involves various specialized roles; everyone knows their responsibilities to ensure a successful operation.

00:12:04.420 In stark contrast, software teams are often more disorganized. Imagine a team working in an operating room environment—we'd have a developer, a senior developer with imposter syndrome, a junior developer who thinks they're amazing.

00:12:19.830 Then there could be someone continually sharpening scalpel-like tools and one who's trying to optimize the height of the operating table. It's a recipe for failure.

00:12:36.460 About a year ago, I started reflecting on the teams I've witnessed, specifically the ones mentioned in various blog posts and conference talks.

00:12:45.270 Despite the varying quality of content online, I was keen to catalog the attributes of good teams I had personally observed.

00:12:58.680 What characterized these teams? They could adapt to new requirements and effectively integrate new members.

00:13:07.800 Their outputs were usable and effective for their target audience. If nobody is using what a team produces, that team should not exist.

00:13:19.170 So, I compiled a list of attributes these teams possessed—including some explicit roles and responsibilities.

00:13:24.510 One obvious role is people leadership. Some companies, however, lack a management layer or it may be so diffused that a single manager has upwards of 22 direct reports.

00:13:31.170 This leads to no support or guidance, creating an environment in which team members can't effectively do their best work.

00:13:38.430 It's well-documented that transitioning from coding to management is a completely different job, with a much longer feedback loop.

00:13:48.660 Feedback loops in technical management may be longer, but relevant strategies from engineering can be applied to management roles, enhancing their effectiveness.

00:14:05.480 Another crucial role present in most effective teams is having someone who understands the overall direction of the team's tasks.

00:14:17.790 This person anticipates challenges ahead and guides the team to avoid potential pitfalls.

00:14:31.570 In addition to critical roles, I found that every successful team seemed to have an individual dedicated to customer needs. This person cared about the users and gathered relevant feedback.

00:14:46.120 Whether it was a customer-facing product or an internal tool, someone needs to actively think about who is using the output and how to make it better.

00:15:02.220 Moreover, an observation that intrigued me was that successful teams often had students, or those in learning positions.

00:15:16.840 Teaching hospitals perform better than non-teaching ones. They costs more, but lower patient mortality proves their effectiveness.

00:15:30.750 Better teams can tackle industry challenges, like training and mentoring early-career team members. I suggest leveraging money to recruit early-career candidates.

00:15:42.860 There’s a fascinating concept called the paradox of expertise: as someone learns skills in their field, they may lag behind due to not adapting to new techniques introduced as they grow.

00:15:56.770 For instance, a surgeon may become exceptional in outdated techniques while newer surgeons could outperform them, illustrating the need for continuous learning.

00:16:13.780 A recent personal experience reiterated this. When I joined Square, I had a clear vision of how I could use my past skills but quickly learned they were inadequate in the evolving tech landscape.

00:16:27.100 This has crucial implications for talent evaluation within engineering; professional skills don't necessarily translate across varying technology. Rapid advancements leave behind those not keeping up.

00:16:43.770 In summary, people grow uniquely, and there is no straightforward progression to meet a bar that may or may not exist. The field of software engineering is vast.

00:16:54.730 Learning this craft entails writing software; each of us writes far more than we could ever hope to read, and diverse teams are essential to fill technology gaps.

00:17:06.880 For surgical teams, having multiple specialists is paramount. Likewise, software teams require diverse roles to be genuinely effective. You cannot operate solely with surgeons, anesthesiologists, or developers.

00:17:23.820 Every member must contribute from their unique perspectives, ensuring all skill areas are adequately addressed. Lastly, students are invaluable for teams.

00:17:36.390 In a recent example, a new security engineer joined my team and sparkled curiosity and momentum through her questions. Her drive to learn revitalized our existing dynamics.

00:17:47.950 If there’s one concept I hope you'll remember, it's that there is no such thing as a 'real engineer.' This myth has plagued our industry for far too long.

00:18:02.780 There’s no valid hiring bar and no specific definition of a 'real engineer.' Let’s repeat that together: There is no such thing as a real engineer.

00:18:15.860 What truly exists are engineers of various types, each unique in their skills and knowledge. No one reaches a point where they’ve 'arrived'.

00:18:28.220 Insights from Medium showcase that mastering the nuances of various skills is far more valuable than hitting a single experience bar. Acknowledging this creates a more effective evaluation process.

00:18:45.950 Imagine defining what skills are necessary for success in your organization. Focus on the actual talents that will thrive in your company, considering their trajectories.

00:19:01.520 This empowers more precise evaluations and allows you to ask candidates about their strengths while ensuring they match the company's needs.

00:19:13.420 The interview process should adapt based on the individual rather than applying a single standard, fostering diversity through talent acquisition.

00:19:26.260 It's time to abandon the notion of a singular engineering mold. Let's hire individuals based on the actual skills our companies need and their aspirations.

00:19:36.470 By focusing on the skills they wish to develop instead of deficiencies, we create a collaborative environment that promotes shared expertise.

00:19:49.640 In conclusion, if we shift our focus away from outdated evaluation standards, we'll better showcase the rich humanity of our candidates.