Alright. Why don't I get started? So today, we're talking about whether we can use the lessons of inclusive hiring to improve our day to day work.First, I'll tell you a little bit about myself. I'll go by Lynn. I'm currently a measuring manager here at Okta. I work in CSE, which is the all zero part of Okta. I got my computer science degree from Trinity College Dublin, and I've been working in the industry since the year 2000. I started my career as a software engineer in the FPGA industry, then I moved to work mostly in fintech. I changed my focus from product engineering to platform engineering and then back again. I took a relative a long time to make the jump from entering manage it.

Sorry to make the jump to entering management. Maybe too long since I'm sure I bug my team by all sticking my nose into their business. All this is to say is that trust me when I say I've got experience in software development. Something I want to emphasize is when I talk about this idea, I'm not talking about old 0 or Okta. I'm talking about the industry as a whole. So when I say we, I mean, the software engineering community. I've worked in a few different companies, and although each one has had different problems, there are certainly common themes, which I believe are pretty pervasive in the industry. So why do we start looking into hiring practices? So we look around software developers and realize they all quite look like one another.

In startups, white college education educated white men, young men, and outside of startups is white and Asian men. So we started looking into the hiring process to increase diversity? No. There isn't a lot of hard evidence to prove that diversity is right better software. But we can say for sure that there's a smell when children are diverse. Before looking for the best candidate for a role, it's very is that the successful hires are all from the same demographic. When we see a pool of candidates that the pool of candidates does not match the successful hires, We have to assume that we're not actually hiring the best people for the role, and we just take a look and see what's not working in the process. We made a reasonable guess that the reason that we're not seeing this was because of bias in the process. We set out to remove that. We're removing the bias was most successful. We saw that We ended up with teams that were more balanced.

In my experience, when working with teams that are more balanced, we saw an improvement to the quality of software. The reason for this, in my opinion, is that we change from hiring the best software developers to the person who is the best fit for the role, Think about her and for a role, which requires a great attention to detail. Maybe the work is a little bit boring, but, you know, that's a role. There was a software developer writing code in JavaScript. If we optimize for the best software developer, we may end up hiring a JavaScript superstar. It may have been head and shoulders above everyone else, especially in the tactical portion of the interview. I'm hiring that person for that role, and you're not being a huge disaster. Why? Well, the hiring process was not formalized.

We didn't start down by writing clearly what we were looking for and what we're and designing a fair evaluation allowed us prepare candidates against the role requirements. If we had done so, then the example we would have evaluated the candidate's attention to detail use that as a discriminator instead of the programming ability. So what did we learn? We need to make clear standardized interview process for all candidates. The responses should be evaluated against a standardized rubric. So, clear, means from the point of view of everyone involved in the process. The candidate should know where they are in the process and what would be evaluated at this stage. They understand what prep work should be done and what success looks like from our point of view.

The interviewer should understand what they're measuring at each point of the process. Standardized. Form out of the interview should be the same for every team hiring for that role. That allows us to migrate candidates to other roles if we see a better fit. For all candidates, We should use the same interview format for every candidate, including internal candidates and referrals. On standardized rubric, we should be able to compare candidates fairly one or other and eliminate bias as much as possible. So were these learnings effective? In my experience, absolutely. I did my first interviews many years ago before these guidelines were implemented. And looking back, I could see that I definitely had some bias in interviewing. I didn't show bias for any protected categories like gender or race. There's certainly favorite candidates who showed interest in the same technologies that I was interested in.

Without giving much thought with the team actually needed. Using these strategies, make sure you're hiring the right person for the role, and the candidate Successful or unsuccessful, have a more pleasant experience. Normally, interviewing is always gonna be a stressful experience. Wanna make sure the candidate is able to perform their best and we don't arbitrarily increase their stress. These are learnings that had a real impact on the industry. And remember, this industry is pretty young. It's not surprising that we made mistakes in the hiring process. In my opinion, though, the industry is not so young that we can go ahead and play it by ear forever. We make products that change the world. Our customers rely on us. Our customers investment investment investors face handsomely in return.

It's time to take a look and see what we can do to serve our customers better and remove arbitrary friction that slows down software development process. So I hope you know that sending your code out for you is one of the more vulnerable things you can do in your day. It's kind of unusual when you think about it. What other job exists where you need to get a peer to check every piece of your work? Your peer has the ability to hold up your work from being added to the product for any reason. Think about what the impact is when the PR, the get when a PR gets returned to the submit or which changes requested. 1, The submitter needs to context switch from the task that they were working on. You need to read and understand the changes that are being requested.

This can be Slack messages or same conversation. Need to deal with the feelings that come from being asked to make a nonmaterial change. This might seem like a trivial thing, but I can say for sure that I spent many hours thinking about this. You need to implement the changes. You need to send the changes for rearview, and the changes need to be merged and deployed. Think about the impact of that. Refactoring multiple time zones, illness, PTO. It could be one day, it could be a week. I think now imagine that the changes requested really have no impact on the product. Imagine that the reviewer was having a hard day, or maybe that a good idea about changing coding style that they would like other people to implement, or maybe they're a dick and they approve everyone else's PR videos. The fact is we have a real system. We have a system where it's possible for people's biases have a real impact of their teammates and the product.

Now to be clear, when I say bias, I mean that Folk's asking for changes where there's no engineering or business value. It's just their personal preference. So when you ask folks why they're rejected at PR, they may say, Oh, code was not good code. What exactly is good code? Here's what makes a good code for me. I'm sure lots of people have different criteria, but it's not important. What's important is, can we agree on the set of characteristics that make good code? And can we evaluate them in a non subjective manner? But assume that in this team, there's all the bells and whistles, enter security checkers, observability tools and station environments. So can we evaluate the all these features that are non subjective matter? Does it do what it's supposed to? Well, you gotta read the code.

And check that the tests have the functionality and that the tests have passed. Is it easy to read or well commented? Oh, we checked that the Linter check surpassed, and then it's formatted with the common code format. Does it have an unjustified performance impact? Hopefully, there's some automated form is test there. Doesn't introduce security issues. Again, you can read the code, and hopefully also perform automated security checks. Do we do this? Does it have a good automated test to to detect regression while we check that the coverage is accessible, acceptable? Does it admit that metrics are necessary to be able to easily support in production? Ideally, the interoperability tools are telling us that yes. And also a lot of these things could be implemented as GitHub checks.

Code reviews by peer are important, but the author can be sure there's no needs to be picked before they even submit their code to review. Now I just love this too. If you ever interviewed this guy, hire immediately, I think this clearly sets out the point that I'm trying to get across. The impact of rejecting a PR that Think about the impact of rejecting a PR that I spoke about earlier 1 day to 1 week of delay for a future. Would you consciously make that input impact just because you think the code could be improved. What if it's good enough? Everyone knows what good code is, but also everyone has had the experience of debugging some code and saves themselves what idiot wrote this. And of course, this idiot wrote this. So what did we learn? We need to make a clear standardized PR review process for all PRs.

The PR should be evaluated against a standardized rubric. Now my team is working on a feature, and they meet with the product manager to refinance your story. They define clear success criteria, and the engineer feels confident taking on the work. They all work hard on it, and they present your PR that that actually does fit all of the team's criteria for good code. The submit it for review, make it responses like this. Imagine the frustration of reading comments like this. You worked hard on the code. It does voters scratching the ticket Why is the ticket rejected? The fact is that though each of these changes should be fact is though that each of these changes should be made And we'll make the feature fit better with the existing code and lower this work burden going forward.

Why did the engineer think that their solution was a credit solution? Well, for the Axios change, the team had a meeting 2 weeks ago and discussed the best request package. They agreed to migrate Axios. For this century, you didn't attend that meeting. For the lowercase request, the engineers worked in the company for a while, but I'm in this product. The product is the only one that needs to alert messages before display. For the error message, the engineer did understand that non catastrophic errors should be displayed using the toast. But they didn't understand that this error didn't impact the customer's experience. So no one's wrong here. The developer working their faith and dealing with a good code.

Reviewer and made sure that a change that didn't fit well if the existing code didn't make its production, be it time was wasted, rather impacts that are less visible too. The product manager, becomes irate because the team is being too picky. They are nontechnical, and they don't understand how switching up request package benefits product. The team may feel like their time was wasted in the code review. They're resentful to have to do it again. The developer who wrote the code feels blindsided. They presented good code. Now they have to go and rework everything. Write it down. Because in my time in the software industry, I thought to myself, I am just making this up as I go along. And that was a need, true. I have a degree in computer science. Couple of decades experience as both an individual contributor and manager. I've written quite a few lines of code.

We've only rarely had any guidance on how to solve any problem that was presented to me. Sometimes the problem was asked to solve is something that had been encountered before. But that was a pretty rare occurrence. Well, which hadn't been intentional before. Sorry. Before being honest with ourselves, we have to admit that a lot of software is querying or updating data in a data store, applying business logic to that data, and displaying the data to the user. Yeah. We find a 1,000,000,000 in one ways of doing these things. Each one with its own idiosyncrasy and failure modes. In every team I've worked on, there was a set of policies that ensured that this things were more or less consistent. But situations like this one, I described happened just this one I described just now happened pretty frequently.

Worse again, these business best practices who are typically enshrined is tribal knowledge. Perhaps they're written down, but not easy to locate. True story. A previous employer, every time I needed to find a certain fact, I needed to do slacks spunking since the decision was made in the slack thread. That link to that conversation was scattered across various documents. But when the retention period was applied to slack, that knowledge was gone to the ages. Now, there are a category of people who feel the need to constantly share their opinion and bring everyone around to their ideas no matter what, no matter if they're buying or not. And I hope we can have empathy for them. We're a young industry. And in the beginning, there was a lot of talented young developers when there was a lot of talented young developers with non technical leadership.

And potentially not a lot of other technical people. I can tell you this is a very stressful situation. Do you understand that the success of the business depends on the work that you do? There's no solid support system for you if you make a mistake or even a good way of measuring if you're doing the right thing. So the natural thing is to just decide the right way of doing something. And decide to spread that across the team or the company. This can make you look like an asshole, but I promise you it comes from a place of vulnerability. I feel like technical leaders as technical leaders, we can create a framework to create a collaborative way of deciding the right way to do things.

Have ways that everyone can measure if they're doing the right thing, and then distress can disappear. So refine that a little bit. Write it down in your con company's persistent document store, have a written down process for updating it, announce any updates to a white audience. So why do I say persistent document store? It is common for decisions to be made in slack or in meetings for the water cooler. Nothing is gonna change about this. It's how things work. If we need to follow a formal process about decision making, nothing is ever going to get decided. If we're actually going to use these decisions, we need to make sure these decisions are accessible and easy to locate for everyone. That includes folks that aren't weren't part of the decision making process and people who joined the company after the decision was made. Slack ain't the right menu.

I didn't even go so far as to say that any document store that isn't easily searchable isn't the right venue either. That's the only option to make a page with all the policies and payments somewhere easy to find. When I say written down process for updates, So why do I save for down process for updates? A common complaint I hear is that if we write down a detailed list of our policies, there's no room for innovation, but we do the same thing forever. Obviously, that's not the case. But if people don't feel empowered to suggest updates or updates to reply willy Nilly with the season 4 outcomes, I see 2 categories of engineers who are reluctant to discuss suggest updates to the development policies.

1, I don't know enough to suggest things to the team. I hope this is self explanatory. This can change what the team works on ensuring psychological safety. And second one is I know too much to suggest things to the team. Now this one is always fun with me. Engineers with decades of experience, Excellent ideas with the experience to back them up will stay quiet when they're a good solution to the problem. When I bring this up with them, they nearly always respond to some variant of My role is to improve the team by getting back getting them back on the right track of this story. It is not to set the path. To which I respond with, if not you, then who? We can't expect folks to always come up with program the concepts on their own. In software engineering community, we stand on the shoulders of giants.

I hope that all the Giantss here recognize that and help upskill their team by explaining concepts and giving their opinion when they're on what good solutions to problems are. Avantular process for updates encourages everyone to consider if their policies are working. And if they see something that needs to change, or if they learned a new thing and they want to introduce it, then they introduce it to the team, then they have a way to get buy in. Lacking process to update the development policies can lead to individuals just deciding things. And where would that lead us? Exactly where we are right now. And unsubscribe to a white audience. And I see the updates is important to spread the knowledge to anyone who wasn't part of the decision making process. It's gonna be team members who are on PTO or leadership who may not care about the details, but they wanna be in on the loop.

Another important audience is teams who are solving the same kind of problems. Ideally in every ensuring org, teams are empowered to decide their own development policies. The teams in the same company often solve similar problems. The solution felt when teens problem can very likely be a solution to the to another teens problem. So what should we learn? Need to make a clear standardized set of best practices. The best practices should be as non subjective as possible. Couldn't quite fit that in the in the template, but close enough. So does this fix all of the problems in software engineering? Obviously not. But it does address some of the daily outgoing issues that make this career harder than it needs to be. Hoping that if we do the work the engineers are able to do their job without worrying about frustrating gotchas that come when PRs are submitted.

I'm hoping that when the values and motivations of engineers, as well as product managers are spelled out clearly with everyone being able to see the other side that we reduce the natural friction that happens between entry and the product management or the balance of tech debt to new features.

Alright. That's my talk. Thanks, everyone.