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.
