Being Thoughtful About The Algorithms In Our Lives, With Jake Miller
Jake Miller is the CTO and Co-Founder of MetaCX, an Indianapolis-based startup that raised a $14 Million dollar initial round to revolutionize the Customer Success industry. Before starting MetaCX, he was an engineering leader at ExactTarget and Salesforce.
In this episode, we talk about why we should never say no to PTO, how algorithms make diversity worse, and how he focuses on building a balanced team instead of a senior team.
I actually think it’s a social responsibility, not just a good strategic business decision, that if we’re wanting to give back to the community it’s not just volunteerism. It’s growing the talent in that community.
Listen to the full episode here:
Welcome to Scaling Software Teams, a weekly podcast to help software leaders navigate fast growth without losing the magic that made that growth possible. I’m your host, Wes Winham. Today we’re joined by Jake Miller.
Jake Miller is the CTO and Co-Founder of MetaCX, an Indianapolis-based startup that raised a $14 Million dollar initial round to revolutionize the Customer Success industry. Before starting MetaCX, he was an engineering leader at ExactTarget and Salesforce
In this episode, we talk about why we should never say no to PTO, how algorithms make diversity worse, and how he focuses on building a balanced team instead of a senior team.
Jake, thank you so much for joining us today on Scaling Software Teams.
Thanks. Thanks for having me. I appreciate it.
What is the most important inflection point in your career that got you where you are today?
I would actually go way back to when I was in college and trying to decide which path I wanted to go. In high school, I actually went through a trade school where I was learning about computer technology, and I went through a whole training program through Cisco on networking. I found it fascinating – I literally would print off every single module and read it over and over, and over again to make sure I understood everything. Which, it’s kind of weird to print things off but it’s how I did it back then.
Back in the day, there were no tablets.
Right. Exactly. Then I went to get a degree in computer programming, started those classes and… they were teaching programming languages that I had already learned, and I was getting bored – so I decided that I was going to do something completely different, something to stretch my horizons, something I hadn’t thought about before.
So I went after English, which, yeah, not a traditional path. And from that I found linguistics, so I concentrated on that throughout college and actually I still read [up on] it now. I think that’s so important because balancing out the technology side with something completely different just changes your perspective; learning something from a different discipline helps you think creatively and apply those lessons to another domain.
And, actually, there’s an article that we talked about. It’s actually called “If You Want to Be Massively Successful, Do Not Set Ambitious Goals”. And what I love about this is it talks about this exact thing: if you’re trying to become an expert in something, you’ll pick up a book or listen to recordings, or talk to people – and they’re probably not going to be groundbreaking, you’re just learning the basics – and then you build on top of that, and build on top that, and build on top of that.
But what can end up happening is you might run out of things to learn, or you’re an expert in that domain – so how do you continue to be creative and think creatively and innovate and find novelty in what you’re doing? Learning something else – going in a completely different domain will help you open up ideas that you can apply back to that area of your expertise. And I’ve actually found that to be the case in my career now, where pulling on my linguistic experience and studies helps me think about, well, how would you apply logic to your applications? [And I think that’s] really exciting.
So we talked about you doing oil painting as a hobby – linguistics, oil painting… how have those impacted your day job?
Oil painting… I got into, actually, charcoal drawing about four years ago and that was because of stress at work.
I was trying to find something where I could just step back, disconnect and rejuvenate – so I would do charcoal drawing every single night and I did that for about a year. It’s almost therapeutic. And then from that I just dabbled into different mediums and I found oil painting. I think what’s so important about exploring things like that, it’s not just a way to disconnect and rejuvenate, and recharge, but…
Even though it is that, which is nice.
It is that. It is that, for sure… and it’s what you want to make it. Some days I actually have a studio that I go to – I try to get in at least four hours a week. And I decide, going in, am I going to think about work or am I not going to think about work? It’s a very intentional thing. And so sometimes you come out of those sessions and you’re thinking about things that may not even be related remotely to something that you’re building or something your team’s working on and then you have an “aha moment” about that hard problem that you’re working on. I actually found this early in my career when I was programming.
I would sit, literally, for 12, 14, 16 hours a day and code. I absolutely loved it. I was trying to get software out the door and shipped for a startup I was working at but I would find I would keep hitting these walls and it was so frustrating. And you think to yourself, “I’m going to persevere. I’m going to keep working through it. I’m going to figure it out eventually.” And more often than not I found if I leave it and come back again in a couple hours or even the next day, sure enough – boom – figured the problem out.
And I actually think that’s super important as leaders when we’re watching our teams work on very hard problems trying to solve complex issues, helping them understand maybe when they’re too far in that trench and making sure they understand that it’s okay to step away and providing that safe place and the psychological safety to know that it’s okay to step back
If your butt’s not in your seat and you don’t have them up are you even working?
Right.
That’s, maybe, not the most helpful perspective.
Right. Yeah, exactly. And we talk about work-life integration. For a while, I hated that term because your life is your life, work is work.
But I’ve grown to like that way of thinking because, whether I want to or not, that’s just how I worked. And I think a lot of people are actually the same way. You’re outside of the walls of your office and if your office is at home, same deal. You often will think about the problems if you’re in the shower. I’m sure a lot of listeners have the same problem where you’re trying to sleep at night, and your brain is still trying to solve the problem.
But being able to work on things [that are] completely different, I think it just really helps.
Let’s say we’ve bought into that concept, which I totally am… I feel like my evening walks with my wife is where I solve – maybe it sounds bad – but some of the hardest business problems, like disagreements with my co-founder around direction and really thorny stuff, we’re talking about normal day-to-day stuff and something just pops into my head and I write it down and just feels like, “Why didn’t I see that five hours ago when I was in the room with a whiteboard?”
So let’s say we’ve bought in on this, how do we help our teams feel safe to go and take a walk ,or whatever they need to do, to make progress on problems they’re working on?
I have a rule that I never say no to PTO. That’s rule number one. And a lot of folks have said, “Why? You have to make sure that the team’s working on a schedule and you’ve got deadlines to hit.”
And it’s like, “Yeah, we absolutely do.” But I think it’s actually the management team’s job to make sure that those goals (1) are reasonable and (2) [are being edited] when you need to edit, and to provide challenges that people find really interesting so that they want to put in that time. Because it’s, again, at that point not just a job. It’s a fun challenge. It’s a puzzle that you’re trying to solve.
And you don’t always have the luxury of having those super interesting projects but trying to find the one that will stretch a particular individual, I think, is really important.
[When it comes to] making sure people know they can go out and take a walk, go out to lunch, take the morning off – I think those are things that come down to just having a company culture set. We have a core value which is ‘feel free’. It’s actually ‘feel free to be your weird self’. It’s sort of what it’s turned into.
But the idea of that is, feel free to do what you need to do to be as productive as possible and your best self. And I think that just setting that tone in the company, not criticizing folks when they do step out when you or someone else on the team thinks maybe they should be in their seat – I think is important.
I love the rule of not saying no to PTO. That feels like sometimes it’s a struggle to get from… We have this value that sounds really good and then how does that actually actualize? How does that operationalize? I love that. If you’re free to be your weird self, you should be free to take PTO and be responsible.
Yeah, that’s right.
That’s a great example.
Everyone’s an adult.
I want to shift topics a little bit. We were talking about algorithms and bias, which I think is a really important topic because as engineers we are the ones creating the algorithms. You read a book called “Weapons of Math Destructions”. Do you mind summarizing what you learned from that book and maybe we could talk about it a little bit?
It’s written by Cathy O’Neil… What she’s pointing out is we have all this data in the world; we’re designing all these algorithms. It’s affecting, literally, every part of our lives – but the algorithms are only as good as the models that we’re building… She gives various different examples of the algorithms and the models and how those are, in many circumstances, negatively impacting society.
My absolute favorite one, just because I think it really hits the core of being a human, is prison systems. When an individual goes into a prison system, they are given a survey and that survey asks things like, “When was your first encounter with police? Have you been convicted before?” And you would think that those are appropriate questions to ask because what they’re trying to do is figure out what’s the likelihood of this individual committing a crime in the future, so if they’re released you have a better idea of what might happen. And actually the court systems use these to try and remove the bias of judges…
So they’re trying to remove the bias out of the decisions on prison sentencing. The problem is that when you’re asking questions that aren’t even necessarily about socioeconomic status or race – you are asking a lot of questions that can actually just figure [those social and cultural factors out] anyway. And what’s happening is there’s this horrible loop that happens, where if you ask an individual that may have come from inner city, “When was the first time that you interacted with the police?” If it was a young black male – it might have been just because they were stopped randomly, right?
Yeah. Stopped and frisked.
Exactly… And so that feeds in the system, and that answer is going to be totally different or might be completely different than the answer you would get from an individual where their first time interacting with the prison system was because of the crime that they had just committed, or what they’re being charged with. But I think the reason I like that example… I know it gets into some pretty heavy conversations, but it really strikes at the heart of what we’re doing. And as engineers, we may not even realize that the decisions we’re making when we’re building models can impact someone’s life.
Here’s a little bit more lightweight of an example – and I hope we get this reference correct – but when an engineer was modeling a mapping system, and it may be hypothetical, but let’s say an engineer at Google is engineering how the mapping system is going to work. They’re modeling the navigation algorithms and they take into account the geography but they don’t take into account buildings. So… how tall are those buildings? You can imagine that model’s being used to predict flight paths, and the plane [could run] into the building because there was an assumption – or there was not an assumption – or a variable, that was forgotten to build into that model.
All models are wrong, some are useful… which ones are useful is a hard question.
It is, exactly. In this book, actually, she talks about how models are designed to answer questions. So, if you’re asking the question, “What should we provide as food?” or “How much food should an individual be given?” – if you’re building that model as North Korea, that’s going to be totally different than if you’re building a model as a parent. Because your goals may be, one, rationing food – versus how much junk foods should you allow your kids to eat. Yeah, I find this topic of just algorithms and how we’re designing models super fascinating.
I don’t know if you saw this in the news: Amazon was using a machine learning algorithm on resume screening and they ran it for a while. They used their past data and they actually audited it, which is good on them… I think mostly they got crap for this. They audited it and they found out that their model the two strongest predictors of “we should interview this person” were the name “Jared” and whether or not they had “lacrosse” on the resume.
Yeah. Right? And those have very little bearing on the qualification of that candidate. Yeah, I read the article too after you sent to me. It was really great.
I’m wondering, based on reading this book, what are some lessons you think that we can apply to hiring and how we can maybe use algorithms? Because you might be hiring 20 or 40 engineers in the next year so I think there’s an argument that some efficiencies can create a more human process. But what is the model we should be… or what is the question we should be asking these models and how do we make them actually serve us rather than finding all of the lacrosse players?
Hands down, no question, that finding efficiencies is just needed there. There are so many candidates that you have to sift through. You have to have the assistance of machines to do that today. And particularly, it’s really important because of remote workers – not only are you getting local candidates you’re trying to find other candidates around the world. And so trying to figure out, or filter down the candidates into a reasonable size, it just doesn’t scale if a person is doing it. It’s too expensive.
But what we can do, and I think we should be doing, is challenging the assumptions and tweaking the models. She talks about that in the book as well.
In Amazon’s case, they were doing that. They were going back, taking a subset of the candidates and, I believe, looking at the qualifications – and they were also looking at the outputs of their results. So “Jared” and “lacrosse” are not valuable inputs to making that decision. And so they tweaked that model, and it gets better. I think the most important thing we can do is: don’t just build and ship. Build, ship and monitor. And that actually doesn’t just apply to models in hiring, it really applies to all models. And actually beyond models, it applies to just your work in general.
We were talking earlier about… One model is the Facebook news feed and that’s something that has an impact on us and I think you’ve taken some steps to change the impact that has on you and how you’ve used that model. Can you talk about your experiments there?
Facebook did a study where they were trying to determine how much of an impact the posts in your feed could have on you, and they were focused on mood as part of the experiment. And it turns out that the moods of other folks in your feed can drastically impact yours. This is going to sound horrible but I personally… I’ve tweaked my feed. I’ve self-censored my Facebook feed to filter out things that are negative or might be negative impacting. And you might say, “Oh, that’s bad because you’re filtering out the perspective of folks that may have different views than you. You’re not getting new sources.”
But I think, for me, it’s been very helpful to just remove any sort of negative impression from that social feed on my day-to-day psyche. Because I’m trying to invest my time in being productive, not focusing on things that are negative. And I think what you could do, if you’re trying to do that, is like I do – if you’re going to new sources, you go to different outlets like real news organizations.
In fact, what I like to do is look at not just a liberal or a conservative or a moderate. I like to look across the board because what you’ll find, and actually I think this may be a really good point to make because this is applicable to your team – when you’re talking to your team, how you’re framing things with your team – the power of language.
If you read one headline and it’s phrased a certain way, and you read another headline by someone that may have a different view, they’re going to be worded very differently and they’re going to be very biased – often, not all the time – but they’re going to be very biased to their perspective. And so you, as an individual, if you’re looking or you’re communicating in one particular way, you may be alienating a whole set of people that you don’t even intend to. I think there’s an important language lesson there.
And I think it’s very reasonable to decide what kind of tool you want Facebook or Twitter, or whatever to be. And if it’s a tool that you want it to give you energy and cute puppies, I think that’s a very legitimate use. There’s another responsibility to be a citizen but Facebook does not have to be the thing that does that. I think that’s too much to ask for one tool. That seems very reasonable.
I’m wondering if you have an example that you can think of that framing and how that affects your team. I’ve seen it myself ,where I frame a problem differently and it goes from a slog to exciting, or I frame feedback differently and it goes from an attack to, “Wes wants me to be better, so let’s do this together”. Can you think of any examples from your experience?
Yes. This one’s sort of a macro level but I really love it. In fact, there was an article we were discussing earlier that really helped me frame and articulate this perspective of mine that helps me explain to the team where I’m coming from. But it’s this idea of goal setting and if we’re setting a goal that’s six months away, how are we going to think about how we’re going to get there? Especially when you’re building, like we are, a big enterprise system with a bunch of unknowns between point A and point B – goal setting can be challenging, so you don’t know every single step of the way what milestone you need to hit.
And so, having a conversation about that and framing it in a slightly different way, which is… we’re not going to necessarily in every circumstance say, “here’s point A and that’s the goal point B, and outline every step that we think we’re going to have to hit” because we’re going to be wrong. What we’re going to do is we’re going to say “our target is X, Y, and Z.” We’re going to lay out targets along the way, so milestones we think we want to hit, but we’re going to follow paths that may be novel, that may stretch our thinking, that might provide context, that will completely change the path we take. Heck, it might even change the end goal that we’re trying to achieve.
And we just need to be very open-minded to that, especially when we’re trying to innovate because it’s very easy to become one track minded if you have your eye on one particular goal and you’re trying to hit that no matter what. In fact, there was a study done – and I love this – about folks who consider themselves “lucky”, and folks that consider themselves “unlucky”. And the experiment was to give them a stack of papers and tell them to count them. And the unlucky people would spend… and I can’t remember the exact number but I think it was something like 20 minutes to count every piece of paper in that stack.
The people that consider themselves lucky, it took them two minutes because they would go through that stack of papers and they were curious, and they would see the sign that said “stop counting there are 350 pages in the stack”. I love that. It’s eye-opening, because it shows that the goal you’re trying to achieve, you could be really blind to other opportunities if you’re just totally set on hitting that thing. It may seem counter-intuitive, especially when you’re trying to build a business from the ground up and hit that MVP, and get that market fit. You want to be as concrete as possible, but more often than not I find curiosity to be a very powerful tool.
Let me make sure I’m understanding that difference on milestone. It seems like both strategies there’s kind of an end goal… there’s kind of a vision, you could be more or less clear on that, and then both strategies have some milestones. Sounds like in the second strategy, the milestones are more flexible in the definition, flexible in the ordering… where does that flexibility come in between those two different ways of thinking about goal setting?
To make sure I understand your question, you’re curious to know about that second model where there’s not necessarily a hard target to hit to get to the goal – how is that different, or how do they relate?
I wonder if we could get a little concrete, if that might help me. I’m imagining a goal would be… The typical waterfall goal is we’ve got to ship a 1.0, here are the 37 features that has to have 12 months from now.
And then we’re going to do three features a month for the next 12 months. Let’s say there are 36 features so we can do easy math. That would be like… maybe that’s the traditional goal setting. It’s like we’ve got to ship these things in this new paradigm, where were more open to curiosity and wandering – how might we structure something similar?
That is a fantastic question. And we try and keep things as simple as possible but, well, sometimes complexity is involved. I actually see this as two tracks. I see a leadership track, a design track, where we are being very curious. We’re being very deliberate on opening minds. In fact, we have very regularly two-hour sessions where there isn’t an end goal. The goal of that session is to just throw out ideas and see where it takes you, which is where you find these novel approaches and, I think, innovation is born.
There’s another track, I think, and that’s the tactical execution track. And you may think that, “Okay, I have 36 features that we need to develop and hit for MVP.” You lay out those goals, you have a set of epics and user stories that are very specific with crisp acceptance criteria. I actually have struggled with this on our current team, and I think a lot of folks would say the same thing – where it can become very stressful when you have those 36 things. They do go so far out in the future. You may think that you have it all figured out but you don’t, 100%.
And again, going back to framing, it’s okay because what we’re going to do is each feature that we hit, each user story that we hit, we’re going to ask ourselves, “Do we need everything?”
We’re going to edit along the way and we’re going to shift, we’re going to get feedback, we’re going to modify our model and they will change along the way rather than being too rigid.
Now you would say, “Okay, well, isn’t that what agile is?” Well, yeah, it is. It’s intended to be so that teams can course-correct as we’re moving. But I think of it a little bit differently. I think of it as… Actually, there’s a Hemingway quote I love to share and it’s “write drunk, edit sober”. And I prescribe to that because I think it’s so true.
So you’ve written out this kind of more traditional… there’s as a roadmap there? It sounds like a big difference in this approach is the willingness to edit, the willingness to adapt to new ideas. Is that a fair characterization?
It is. Yes. And again, at two different levels, one very tactical and the other one strategic and vision.
That makes sense. The dynamic process is going to… We’ve got new information in the future. Future us will be smarter, will have more customer information and will know more about what’s hard like the sticking to… It would be a shame to throw away that information for the future because current dumber us decided something had to happen.
And, again, folks on the front line are charged with execution, so it’s our job as managers to keep an eye out at a little higher level to say, “You know what? I think we’re too focused here. I think we need to open our minds to a different way of solving this.” And again, psychological safety, to step away and ask ourselves why are we doing that.
I’d love to talk about team balance. There’s a lot of conversation, an increasing conversation, around diversity which is great. I think that it’s absolutely needed in our industry. One thing that I think gets lost is skill and seniority diversity – or maybe “balance” is a better word. I’d love to hear your thoughts on how important that sort of balance is when we’re creating teams.
Yeah. When we first started building our team here, we were very deliberate about what type of candidates that we wanted, and this all falls in the diversity bucket – gender diversity, racial diversity, which are all things super important. Like you said, I think one that’s very often overlooked, especially in startups where your goal is to get software out as quickly as possible, is skillset diversity. The way I see this, is what you’re trying to do when you’re building a development team from the ground up, or actually just any development team, is you’re setting yourself up for growth – you’re going to grow.
Now you might take the perspective, “Oh, if I hire all very senior folks, we’ll get a bunch of software out the door and then they’ll become the leaders.” That’s true. But you’re probably going to run a scenario where you’re actually not going to grow that fast, so you have a bunch of senior folks trying to compete with each other. They’re going to become unhappy because there’s not a whole lot of room to grow. Being able to look for, like we said earlier, the diamond in the rough… the people that are even coming from coding academies – totally different backgrounds, different skills set levels or junior, maybe they’ve never programmed before – and bringing them into the fold and growing them.
And I actually think it’s a social responsibility, not just a good strategic business decision that if we’re wanting to give back to the community, it’s not just volunteerism. It’s growing the talent in that community. I think that’s just incredibly important. In fact, two of our hires were out of coding academies and are rock stars; some of the best hires I’ve ever made actually.
Wow.
Yeah. And they’re willing to grow – they’re very curious and know how to ask great questions of the more senior people, and are willing to step out of the comfort zone. In fact, someone… I think, in my personal opinion, an individual that’s willing to change a career, go to a coding academy, learn something completely new, is already exemplifying that willingness to stretch themselves and their ambition and perseverance.
That’s behavior. That predicts future performance. Absolutely.
It does. It’s very hard to judge behavior in an hour interview, so we’re looking for some of those indicators… again watching out for, maybe, some of your unconscious bias.
Recently, a former colleague of mine showed me a text message, and we had a phone call about his wife, who was wanting to go to a coding academy. She was concerned because she didn’t know how difficult it would be to find a job coming right out of that. And so that was going to be a point to decide whether she would do it or not, and we had this exact conversation. Actually, it’s kind of refreshing to have this right now… this conversation about it.
Yeah. I love the both points you said which is it’s good for the ecosystem, it’s good for our teams and also good for the senior engineers. We did a Twitter poll – an unscientific Twitter poll – about 75% of the senior engineers responded. They said having too few juniors on their team would make them more likely to look for another job. Essentially, if I don’t have people to mentor or I’m stuck doing the jQuery upgrade that you could get a junior engineer to do, then, that’s going to make my job on fulfilling – which I think is often overlooked.
Right. And it’s probably isolating too, I would imagine… If you’re engaging with people on a day-to-day basis where you’re helping them learn something, you’re probably learning something back, too. I think this is what you’re hitting on. You’re learning how to communicate with people, how other people might work, how you can hone your skills on communication.
In fact, every single job description you look at – and maybe I shouldn’t be so general but I am willing to go out on this limb – every job description you’re going to look at will say “communication” as one of the requirements. Communication.
A very secure limb you’re on right now.
I’ve always found that irritating. And the reason is, it is a platitude. We’re saying “communication” but, okay, well what does communication mean?
What type of communication? Is it writing? Is it being able to understand the way other people communicate? Communication isn’t just verbal… A great example: I process information by writing. I am not always great on the spot when I’m asked the question – I write everything down. I have to go reference it. If I have a hard problem I’m trying to solve, I write about it.
In fact, in preparation for this interview, I spent time writing – not because I was trying to figure out what verbatim I wanted to say, but because it just helps me understand and frame what I want to talk about. And folks, some folks, might find that difficult to work with but it’s a very valid approach and I think that’s an important component of communication as well.
Let’s say there’s folks that are listening and they’re intrigued and saying, “Maybe I don’t have enough juniors on my team, maybe I’ve drifted too far on one direction.” Let’s say we got senior, mid-level and early career junior, what do you think some goods heuristics for how that breakdown should be on a high functioning team?
This is actually a hard one because I think so much about building a team is about context of the individual because, again going back to our algorithms – I’m not just trying to find out or decide that “I have one principal engineer per scrum team” or “one dev manager per scrum team and two juniors and it should be six people on a team”. There’s no perfect combination. I think everyone knows that.
But I think I approach it this way: find your senior talent and then find folks that complement those folks in a way of the communication style, their backgrounds, and what type of work they’re going to be doing. Everyone wants to say they want to hire full stack developers. Do they really exist? They do… but it’s hard to find, let’s be honest.
The stack is pretty big nowadays. It’s wide.
It’s way too big. And so, yeah, I’m not answering your question very well because it’s a really hard one.
In fact, my straight up answer would be the heuristic to build a high performing team is so unique to what you’re trying to build and what you’re trying to do, that there’s really no answer.
That is an answer, the lack of answer.
Yeah.
Maybe another way to get at this is what’s the range of success? Have you seen 100% senior teams that were high-performing teams and, maybe, what’s the highest percentage of junior engineers you’ve seen to be a really successful team? Just give us some error bars.
Yeah. The majority of my teams actually have been pretty well balanced. One team I’ve had in the past has actually been three very senior folks and that was intentional because the problem that was trying to be solved was actually rooted in more computer science concepts. It was just a more complex problem they were trying to solve and so that can work. But if you have full stack work or problems you’re trying to solve, or features you’re trying to build that have tasks that aren’t hardcore computer science tasks or require that sort of knowledge, that’s when you get into the area of finding the balance.
And, typically, evenly distributed teams work really well. You have your mid-level, your senior level and junior level… because the types of problems are usually more distributed too. I think that works pretty well.
My guest today has been Jake Miller. Jake, thank you for being on Scaling Software Teams.
Thank you so much. I appreciate your time.
Thanks again to Jake for sharing his experience with us. Here are a few takeaways I had from our chat. Number one, we should consider never saying no to PTO requests. A common core value is transparency or trust or autonomy or everyone’s an adult. Core values that are just written down on paper or not super useful, so what are the behaviors we can enforce as leaders that help us spread that core value in their actual meaning?
One of them is to trust people to make their own decisions about PTO. Always approve PTO. Trust them to choose PTO times in ways that will make them be their best self. So we trust people to make those decisions and then we have conversations and trust them to be adults. MetaCX expresses that core value as ‘feel free to be your weird self’, which I love.
Number two, algorithms can easily make diversity worse. It’s easy to think of algorithms as unbiased, right? They only make decisions.
The problem is: all models are wrong and some are useful. A model is designed to answer a specific question, and if we use a model designed to answer question A and we ask it question B we should not be surprised if we’re getting the wrong answer; the context matters.
We should not just build and ship a model and assume it’s right. We need to build, ship, and monitor. This means testing the results. That allows us to detect when the question we were asking the model is no longer the question it was designed to answer.
One example would be a model designed to see who writes great unit tests; if there is a significant bias and who has prior unit test writing experience and we believe that’s a teachable skill, a model that screens out anyone who can’t write unit tests might disproportionately screen out engineers who might be underrepresented, just because they have different backgrounds. And if we think we can teach the unit test that model, we’ll be making diversity worse on our team.
Number three, a balanced team is a happy team. A common misconception is that if we just hire only senior engineers we’ll start shipping, and everything will be great. Can we possibly imagine a better team than a bunch of senior engineers?
The reality is there are some downsides to that. Beyond just it being 10 times harder to hire senior engineers and senior engineers being more expensive, the hidden cost is that it creates competition and lack of a career path. There’s always plumbing to do, and if we only have senior engineers, that means senior engineers are going to be doing the plumbing.
It also means the promotion paths to tech leads and engineering management are going to get clogged up. That can create unease and discomfort, and also a lack of ability to mentor, which many engineers rate as one of the most enjoyable parts of their job. I
f we hire a diverse group regarding skillset and seniority, now we have a balanced team that can be more effective.
Thanks again to Jake for coming on the show. Now, I want to hear from you. Please leave us a review on iTunes, Google Play or wherever you get your podcasts. This will help others find our community. Until next week, keep on scaling.
Scaling Software Teams is brought to you by my startup, Woven. At Woven, we want to help you build a world class engineering team – and that means both getting better at hiring and getting better at management.
