In Praise of "Normal" Engineers (with full speaker notes)

In Praise of “Normal Engineers” “Build Boring Engineering Orgs” h/t
Luca Rossi of refactoring.fm for commissioning the article that inspired this talk

2 © 2025 Hound Technology, Inc. All rights reserved. Charity
Majors CTO | Honeycomb linkedin.com/in/charity-majors @charity.wtf For those who don’t know me …. Most of us have encountered a few engineers who seem practically magician-like, a class apart from the rest of us in their ability to reason about complex mental models, leap to non-obvious yet elegant solutions, or emit waves of high quality code at unreal velocity. I have run into any number of these incredible beings over the course of my career. I think this is what explains the curious durability of the “10x engineer” meme.

3 © 2025 Hound Technology, Inc. All rights reserved. I’ve
gotten to work with some *incredible* world-class engineers over my career and with other engineers who went on to become world-class engineers, years later I’ve gotten to work with a lot of world class engineers over the course of my career. Perhaps more interestingly. I’ve gotten to work with a lot of engineers who then went on to become world class engineers, years and years later. Most of us have encountered a few engineers who seem practically magician-like, a class apart from the rest of us in their ability to reason about complex mental models, leap to non-obvious yet elegant solutions, or emit waves of high quality code at unreal velocity.

4 © 2025 Hound Technology, Inc. All rights reserved. The
curious durability of the (rather ridiculous) “10x engineer” meme This has been ripped to shreds over and over, but it just won’t quit. It may be based on flimsy, shoddy research, and the claims people have made to defend it have often been risible (e.g. “10x engineers have dark backgrounds, are rarely seen doing UI work, are poor mentors and interviewers”), or blatantly double down on stereotypes (“we look for young dudes in hoodies that remind us of Mark Zuckerberg”). But damn if it doesn’t resonate with experience. It just feels true. The problem is not the idea that there are engineers who are 10x as productive as other engineers. I don’t have a problem with this statement; in fact, that much seems self-evidently true. The problems I do have are twofold. A lot of people REALLY HATE this phrase. I am not actually one of them. I think there’s some truth to it. Some engineers ARE dramatically more productive than others, and I don’t find this at all threatening to admit.

5 © 2025 Hound Technology, Inc. All rights reserved. Excellence
is not generic, it is highly specific. Microprocessors, IoT, database internals, web services, user experience, mobile apps, embedded systems, cryptography, animation, training models for generative AI, machine learning… Golang, python, COBOL, lisp, perl, React, brainfuck, ruby, rails, java, jruby, F#, C, C++, C#, javascript, typescript? What version, which frameworks, which libraries, what data models? What adjacent skills, market segments, or other subject matter expertise… design, security, compliance, data visualization, marketing, sales, pre-sales, post-sales, finance, banking…? What stage of maturity? What scale of usage? Shrinkwrapped software? The Mars Rover? Startup, scale-up, Fortune 500, international finance? 5 engineers, 5000 engineers, 50,000 engineers? Open source, closed source? Consulting? Remote, in-office, hybrid? ✨ ✨ ✨ First: how are you measuring productivity? I have a problem with the implication that there is One True Metric of productivity that you can standardize and sort people by. Consider, for a moment, the sheer combinatorial magnitude of skills and experiences at play: Also: people and their skills and abilities are not static. At one point, I was a pretty good DBRE (I even co-wrote the book on it). Maybe I was even a 10x DB engineer then, but certainly not now. I haven’t debugged a query plan in years. “10x engineer” makes it sound like 10x productivity is an immutable characteristic of a person. But someone who is a 10x engineer in a particular skill set is still going to have infinitely more areas where they are normal or average (or less). I know a lot of world class engineers, but I’ve never met anyone who is 10x better than everyone else across the board, in every situation. Secondly, and more importantly, So what?

6 © 2025 Hound Technology, Inc. All rights reserved. If
you’ve ever met anyone who self-identifies as a “10x engineer”... they were probably an asshole. I don’t actually have a problem with this phrase, but a lot of people do, because it’s been used for evil so many timse People who PRIDE themselves on being 10x engineers are almost always assholes. People who see themselves as team members ﬁrst and foremost, are more likely to be great team players. The second problem i have with this phrase is that it acts like excellence is some unipolar dimension you can sort everyone by, when in fact excellence is incredibly contextual and specific. There are millions of different ways for people to be excellent, world class, at the tp of their fields.

7 © 2025 Hound Technology, Inc. All rights reserved. Individual
engineers don’t own software, engineering teams own software. Second, and even more importantly: So what? It doesn’t matter. Individual engineers don’t own software, teams own software. The smallest unit of software ownership and delivery is the engineering team. It doesn’t matter how fast an individual engineer can write software, what matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own. If it takes the slowest engineer at your company five hours to ship a single line of code, it’s going to take the fastest engineer at your company five hours to ship a single line of code. The time spent writing code is typically dwarfed by the time spent on every other part of the software development lifecycle. Generating code is, and has always been, the easiest part of the software development lifecycle.

8 © 2025 Hound Technology, Inc. All rights reserved. (actually,
we do have a term for individual engineers who own services or surface areas…) If you have services or software components that are owned by a single engineer, that person is a single point of failure. I’m not saying this should never happen. It’s quite normal at startups to have individuals owning software, because the biggest existential risk that you face is not moving fast enough, not finding product market fit, and going out of business. But as you start to grow up as a company, as users start to demand more from you, and you start planning for the survival of the company to extend years into the future…ownership needs to get handed over to a team. Individual engineers get sick, go on vacation, and leave the company, and the business has got to be resilient to that. Being a great leader isn’t about hiring the greatest individuals, it’s about building the best teams.

9 © 2025 Hound Technology, Inc. All rights reserved. When
people talk about world class engineering orgs, they tend to obsess over levels and pedigrees and reputations. This is exactly backwards. When people talk about world-class engineering orgs, they often have in mind teams that are top-heavy with staff and principal engineers, or recruiting heavily from the ranks of ex-FAANG employees or top universities. Tech companies obsess over finding, hiring and keeping world class engineers. But they over-index on finding these people AFTER they’ve already developed into world class engineers. They overlook the majority of the talent out there, and chase after the engineers who already have exactly the skills they want, or who have already proven themselve sin a particular domain. They act like people are the way they are, and the way they show up on your doorstep is the way they will always stay Talent may be evenly distributed, but opportunity is not.

best engineering orgs are the ones where normal engineers can do great work. Where you don’t have to be highly pedigreed or have decades of experience in order to be productive. But I would argue that a truly great engineering org is one where you don't HAVE to be one of the “best” or most pedigreed engineers in the world to get shit done and have a lot of impact on the business. I think it’s actually the other way around. A truly great engineering organization is one where perfectly normal, workaday software engineers, with decent software engineering skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they've built, and move the business forward a little bit more, day by day, week by week.

11 © 2025 Hound Technology, Inc. All rights reserved. A
truly great engineering org is one where normal, workaday software engineers can consistently move fast, ship code, respond to users, understand the systems they’ve built, and move the business forward, a little bit more, every single day. This demands a lot more from your managers, directors and even staff+ engineers. Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. That is not hard. And putting all the spotlight on individual ability has a way of letting your leaders off the hook for doing their jobs. It is a HUGE competitive advantage if you can build sociotechnical systems where less experienced engineers can convert their effort and energy into product and business momentum. The bar for leadership is much higher

13 © 2025 Hound Technology, Inc. All rights reserved. It
is a massive competitive advantage if you can draw from a broader talent pool So many companies out there bragging about how they hire the top 10% (or top .1%!!!) of talent. If that’s your strategy, I hope you’re prepared to offer them something in the top 10% (or .1%!) of salary bands. Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. That is not hard. And putting all the spotlight on individual ability has a way of letting your leaders off the hook for doing their jobs. It is a HUGE competitive advantage if you can build sociotechnical systems where less experienced engineers can convert their effort and energy into product and business momentum. I personally find language like “top .1%” or “top 10%” deeply off-putting. So do a lot of other people. But some people do actually find it motivating. They WANT to measure themselves against the best in the world and come out on top, and they build a life and career out of doing this over and over again. I’m not saying this is right or wrong, only that you should be aware of the tradeoffs, and what kind of people this kind of strategy is likely to attract. if you are trying to hire the top 10% of talent, ask yourself: are you ready, willing and able to pay them in the top 10% of salaries? if this makes you hesitate, you may want to rethink your strategy.

14 © 2025 Hound Technology, Inc. All rights reserved. Let’s
talk about “normal” for a moment. It can be humbling to think of ourselves as normal people, but most of us are in fact pretty normal people, with many years of highly specialized experience. “Normal” encompasses a vast spectrum of neurodiversity and neurospiciness. Being weird is normal too. 🥰 We are ALL more normal than we are not. 💜 “Normal” is a pretty loaded term — I think a lot of us have learned to wince and avoid it. A lot of technical people got really attached to our identities as smart kids. The software industry tends to reflect and reinforce this preoccupation at every turn, from Netflix’s “we look for the top 10% of global talent” to Amazon’s talk about “bar-raising” or Coinbase’s recent claim to “hire the top .1%”. (Seriously, guys? Ok, well, Honeycomb is going to hire only the top .00001%!) In this essay, I would like to challenge us to set that baggage to the side and think about ourselves as normal people. It can be humbling to think of ourselves as normal people, but most of us are in fact pretty normal people (albeit with many years of highly specialized practice and experience), and there is nothing wrong with that. Even those of us who are certified geniuses on certain criteria are likely quite normal in other ways — kinesthetic, emotional, spatial, musical, linguistic, etc. “Normal” encompasses a wide range of neurodiversity and neuro spiciness.

15 © 2025 Hound Technology, Inc. All rights reserved. Nobody
is born a great software engineer; great engineers are forged over years and years of practice. The reason I like to use the term “normal” is this — it reminds us that nobody is born a great engineer. Even the best world class engineers spent a solid decade or so of their life shipping code as an engineer, before they became world class. Software engineering both selects for and develops certain types of intelligence, particularly around abstract reasoning, but nobody is born a great software engineer. Great engineers are made, not born. I just don’t think there’s a lot more we can get out of thinking of ourselves as a special class of people, compared to the value we can derive from thinking of ourselves collectively as relatively normal people who have practiced a fairly niche craft for a very long time.

16 © 2025 Hound Technology, Inc. All rights reserved. How
do you turn normal engineers into world class engineering teams? Honestly, none of this should be very surprising to anyone here. But you start by realigning the way you think, away from the overly individualistic focus of thinking about hiring individuals, and towards “composing teams”. This is a skill and a practice you get better with over time. Focusing too much on individuals has the effect of letting your leadership off the hook. It is HARDER to craft 10x engineering teams than it is to hire the most senior engineers in the world and drop them into chaos to figure shit out. Yes, This takes more from leaders.

17 © 2025 Hound Technology, Inc. All rights reserved. How
do you turn normal engineers into world class engineering teams? How do you craft the kind of systems that consistently turn normal engineers and engineering teams into world class results? Now we’re getting somewhere…. Honestly, none of this should be very surprising to anyone here. But you start by realigning the way you think, away from the overly individualistic focus of thinking about hiring individuals, and towards “composing teams”. This is a skill and a practice you get better with over time. Focusing too much on individuals has the effect of letting your leadership off the hook. It is HARDER to craft 10x engineering teams than it is to hire the most senior engineers in the world and drop them into chaos to figure shit out. Yes, This takes more from leaders.

only measure of productivity that matters is business impact. Software engineering is about solving business problems using technology, not writing tons of code. I’ll show my cards here / my biases right up front: The only thing that actually matters when it comes to engineering productivity is whether or not you are moving the business materially forward. Businesses don’t grow in leaps and bounds, but step by step. Which means…we can’t do this in a vacuum. The most important question is whether or not we are working on the right thing, which is a problem engineering can’t answer without help from product, design, and the rest of the business. Software engineering isn’t about writing lots of lines of code, it’s about solving business problems using technology.

number one productivity question is: Are you working on the right thing? Is everyone? In other words: You’ve heard just a smidge about this here at this conference, i think ;) Alignment IS THE JOB of technical leadership. It doesn’t matter how fast you’re typing or outputting code if you aren’t fundamentally going in the right way to move the needle of the business. Can people make decisions independently? Transparency, etc The only thing that actually matters when it comes to engineering productivity is whether or not you are moving the business materially forward. Which means…we can’t do this in a vacuum. The most important question is whether or not we are working on the right thing, which is a problem engineering can’t answer without help from product, design, and the rest of the business. This so often gets skipped in our rush to measure cycle time, code review, turnaround time, etc.

20 © 2025 Hound Technology, Inc. All rights reserved. You
can’t wall teams off from the “why”. Any manager who sees their role as that of “shit umbrella” is a liability. Engineers are the innovation engine of your company, not task-takers or ticket monkeys. Invest in org transparency, hard conversations, saying no (and hearing no) You can’t wall teams off from the “why”. Shit umbrellas — the managers who try to “protect” their engineers from what’s going on in the rest of the business — are a plague. You want to build an org of thinkers and dreamers and collaborators, the innovation engine of modern businesses, not ticket-takers. You have to commit to transparency, hard conversations, saying no (and hearing no). Clear Is Kind, people. The software industry is obsessed with hiring and recruiting “top talent”, “best of the best”, “10x engineers”, and so on. I think this obsession misunderstands the very nature of excellence, both for engineers and for teams, and gets the causal chain precisely backwards. Managers are there to connect you, not protect you

21 © 2025 Hound Technology, Inc. All rights reserved. Don’t
hire the “best” people. Hire the right people. Hire for their strengths, not their lack of weaknesses. Know your business, craft a talent strategy to match. I feel like a whole slew of issues (candidates self-selecting out of the interview process, diversity of applicants, etc) would be improved simply by shifting the focus on engineering hiring and interviewing away from this inordinate emphasis on hiring the BEST PEOPLE (whatever THAT means) and realigning around the more reasonable and accurate RIGHT PEOPLE. There’s no such thing as “best”, any more than there are 10x engineers. It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams rather than hiring the BEST people; where inclusivity is a given both for ethical reasons and because it raises the bar for performance for everyone. Inclusive culture is what actual meritocracy depends on. This is the kind of place that engineering talent (and good humans) are drawn to like a moth to a flame. It feels good to ship. It feels good to move the business forward. It feels good to sharpen your skills and improve your craft. It’s the kind of place that people go when they want to become world class engineers. And it tends to be the kind of place where world class engineers want to stick around, to train up the next generation.

Pretty much every engineer who’s been at honeycomb for 2-3
years could waltz out the door any minute and go make $1m/year at nvidia or google. And a couple of them actually have! Most of them couldn’t have done that at the point they joined. But that’s kind of the point.. This is the experience that forges you.

22 © 2025 Hound Technology, Inc. All rights reserved. What
does excellence mean for your org? (Keep that list as short as possible) 1. How difficult, scarce, and/or hard to learn are the technical skills you need in this role? (Be honest) 2. How much support or training are you equipped to give them? 3. How long a time horizon are you planning out? 4. What’s your risk tolerance? Know your business. You need to know your business, and craft a talent strategy that helps it succeed. SPECIFICALLY. What time horizon are you building for? A six month horizon calls for a very different strategy than a one or two year horizon, or a 5-10 year horizon. If you’re confident your company will exist in 10 years… there are plenty of google principal engineers who didn’t successfully make the leap to being a happy, productive startup engineer, and vice versa You can’t be all things to all people. Don’t try. Your job is to provide people with clarity on expectations and reasons for them, so they can decide if this is the right place for them to work or not. the best distributed systems engineers in the world all work at google/facebook/etc. because they’ve been working on distributed systems for the past few years. not because they were the best going in What specifically makes someone excellent in your line of work? Keep that list as short as possible. You can’t cargo cult excellence any more than you can cargo cult your company’s values or culture. For some companies, some teams.. lifestyle businesses make them happy. Remote vs in-office vs hybrid.

how do you build an organization that forges great engineers?
to some extent, only you can answer this question. what it means to be a great engineer at a bay area startup is different than what it means to be a great engineer at pivotal, or at Ford motors, or at an australian bank. there’s this weird assumption that everyone wants/likes LESS WORK, but it is extremely not true we are not all chasing after the same few handful of engineers, because we want some very different things Know your business. You need to know your business, and craft a talent strategy that helps it succeed. What time horizon are you building for? A six month horizon calls for a very different strategy than a one or two year horizon, or a 5-10 year horizon. If you’re confident your company will exist in 10 years… i am saying that talent is as common as dirt. the possibility and potential for excellence is everywhere. but there are a million different ways excellence can flower, and a million different types excellence that can be called for. precision and specificity is how we bridge the gap. the more precise you can be about the excellence you need, and the more your org can build in the systems to develop that talent, the more your business does not have to pay top-10% salaries for top-10% talent. “10x engineer” acts like that can all be flattened to one universal metric of productivity, like a personality attribute A great founding engineer is typically a very different profile than a great principal engineer in a 10,000-person org. you can’t copy-paste any other company’s definition of excellence and use it as your own. you can learn from prior art, but yours must be authentic to you being able to draw from a broader talent pool will always be a business advantage

23 © 2025 Hound Technology, Inc. All rights reserved. You
can’t be all things to all people; don’t try. You can’t cargo cult excellence, any more than you can cargo cult another company’s values or culture. If you can think of several GREAT contributors, who you would wholeheartedly refer to other companies you respect, but you wouldn’t try to hire yourself… that’s a sign you’re doing it right. You can’t be all things to all people. Don’t try to be. this might sound like a truism, but .. it means that the best engineering orgs are ones that are working on the right things, leveraging the fewest resources to do the most work. the core job of leadership is not, from “how do we hire the best people & get out of their way” to “how do we build an environment where people can do their best work, and get a little bit better every day?” The more you are able to draw from a wider bench of talent, and develop skills and talent internally, the more of a competitive advantage it can be. We often make the mistake of thinking everyone wants what we want. But some people WANT to work on database storage engines, 60 hours a week. Some people WANT to work

24 © 2025 Hound Technology, Inc. All rights reserved. Build
sociotechnical systems for software delivery with ✨normal people✨ in mind When your systems are designed to be used by normal engineers, all that excess brilliance and energy can get poured into the product itself, instead of wasting it on navigating the system. How do we do that? Build sociotechnical systems with “normal people” in mind When it comes to hiring talent and building teams, yes, absolutely, we should focus on identifying the ways people are exceptional and talented and strong. But when it comes to building sociotechnical systems for software delivery, we should focus on all the ways people are normal. Normal people have cognitive biases — confirmation bias, recency bias, hindsight bias. We work hard, we care, and we do our best; but we also forget things, get impatient, and zone out. Our eyes are inexorably drawn to the color red (unless we are colorblind). We develop habits and ways of doing things, and resist changing them. When we see the same text block repeatedly, we stop reading it. We are embodied beings who can get overwhelmed and fatigued. If an alert wakes us up at 3 am, we are much more likely to make mistakes while responding to that alert than if we tried to do the same thing at 3pm. Our emotional state can affect the quality of our work. Our relationships impact our ability to get shit done. When your systems are designed to be used by normal engineers, all that excess brilliance they have can get poured into the product itself, instead of wasting it on navigating the system itself. (none of this should be too surprising :) )

sociotechnical systems for software delivery with ✨normal people✨ in mind 1. Keep the deploy interval short and sweet 2. Make it easy to do the right thing, hard to do the wrong thing. The fastest way to ship a single line of code should also be the easiest. 3. Every engineer should be able to deploy and (roll back) their code 4. Invest in observability and sense-making tools. 5. Invest in internal tooling and enablement. Only prod is prod. Technical: ✨ ✨ ✨ Shrink the interval between when you write the code and when the code goes live. Make it as short as possible; the shorter the better. I’ve written and given talks about this many, many times. The shorter the interval, the lower the cognitive carrying costs. The faster you can iterate, the better. The more of your brain can go into the product instead of the process of building it. One of the most powerful things you can do is have a short, fast enough deploy cycle that you can ship one commit per deploy. I’ve referred to this as the “software engineering death spiral” … when the deploy cycle takes so long that you end up batching together a bunch of engineers’ diffs in every build. The slower it gets, the more you batch up, and the harder it becomes to figure out what happened or roll back. The longer it takes, the more people you need, the higher the coordination costs, and the more slowly everyone moves. Deploy time is the feedback loop at the heart of the development process. It is almost impossible to overstate the centrality of keeping this short and tight. Make it easy and fast to roll back or recover from mistakes. Developers should be able to deploy their own code, figure out if it’s working as intended or not, and if not, roll forward or back swiftly and easily. No muss, no fuss, no thinking involved.

Make it easy to do the right thing and hard
to do the wrong thing. Wrap designers and design thinking into all the touch points your engineers have with production systems. Use your platform engineering team to think about how to empower people to swiftly make changes and self-serve, but also remember that a lot of times people will be engaging with production late at night or when they’re very stressed, tired, and possibly freaking out. Build guard rails. The fastest way to ship a single line of code should also be the easiest way to ship a single line of code. Invest in instrumentation and observability. You’ll never know — not really — what the code you wrote does just by reading it. The only way to be sure is by instrumenting your code and watching real users run it in production. Good, friendly sociotechnical systems invest heavily in tools for sense-making. Being able to visualize your work is what makes engineering abstractions accessible to actual engineers. You shouldn’t have to be a world-class engineer just to debug your own damn code. Devote engineering cycles to internal tooling and enablement. If fast, safe deploys, with guard rails, instrumentation, and highly parallelized test suites are “everybody’s job”, they will end up nobody’s job. Engineering productivity isn’t something you can outsource. Managing the interfaces between your software vendors and your own teams is both a science and an art. Making it look easy and intuitive is really hard. It needs an owner.

sociotechnical systems for software delivery with ✨normal people✨ in mind 6. Build an inclusive culture. People do their best work when they feel a sense of belonging. 7. Instill a growth mindset into your culture. Acknowledge your mistakes publicly, and learn from them. 8. Diverse teams are resilient teams 9. Assemble engineering teams from a range of levels Social: ✨ ✨ ✨ Build an inclusive culture. Growth is the norm, growth is the baseline. People do their best work when they feel a sense of belonging. An inclusive culture is one where everyone feels safe to ask questions, explore, and make mistakes; where everyone is held to the same high standard, and given the support and encouragement they need to achieve their goals. Diverse teams are resilient teams. Yeah, a team of super-senior engineers who all share a similar background can move incredibly fast, but a monoculture is fragile. Someone gets sick, someone gets pregnant, you start to grow and you need to integrate people from other backgrounds and the whole team can get derailed — fast. When your teams are used to operating with a mix of genders, racial backgrounds, identities, age ranges, family statuses, geographical locations, skill sets, etc — when this is just table stakes, standard operating procedure — you’re better equipped to roll with it when life happens. Assemble engineering teams from a range of levels. The best engineering teams aren’t top-heavy with staff engineers and principal engineers. The best engineering teams are ones where nobody is running on autopilot, banging out a login page for the 300th time; everyone is working on something that challenges them and pushes their boundaries. Everyone is learning, everyone is teaching, everyone is pushing their own boundaries and

growing. All the time.

work you put into making your systems resilient, discoverable, and humane will be used over and over. By the way — all of that work you put into making your systems resilient, well-designed, and humane is the same work you would need to do to help onboard new engineers, develop junior talent, or let engineers move between teams. It gets used and reused, over and over. Costs vs investments

31 © 2025 Hound Technology, Inc. All rights reserved. I
am NOT saying that excellence doesn’t matter, or that you should manage to the “lowest common denominator,” or that you should not have high standards, All of this is done in service of excellence. or not manage underperformers out. I am saying that excellence is specific, and a learnable skill. The truth is, you can’t buy excellence, you can only build it in house. Know what excellence means to you specifically, and hold your standards high. Recruit, interview, train, retain for those skills and qualities. Remember that your company is an ecosystem. Excellence for a security consultancy is very different from a 12 person VC backed startup, or a 5000 person enterprise hardware tech company Remember, again, excellence is SPECIFIC. All advice should come with context. I am NOT saying that excellence doesn’t matter and shouldn’t be sought, searched for or fought to achieve. it absolutely fucking matters. ALL of this is in the pursuit of excellence there are a million different ways excellence can flower, and a million different types excellence that can be called for. precision and specificity is how we bridge the gap. the more precise you can be about the excellence you need, and the more your org can build in the systems to develop that talent, the more your business does not have to pay top-10% salaries for top-10% talent.

“10x engineer” acts like that can all be ﬂattened to
one universal metric of productivity, like a personality attribute most of the world class engineers i’ve known are pretty humble people, because they know they AREN’T that special. They are the result of years of compounding hard work and opportunities and mentorship.

am NOT saying that excellence doesn’t matter, or that you should manage to the “lowest common denominator,” or that you should not have high standards, All of this is done in service of excellence. or not manage underperformers out. I am saying that excellence is specific, and a learnable skill. The truth is, you can’t buy excellence, you can only build it in house. Know what excellence means to you specifically, and hold your standards high. Recruit, interview, train, retain for those skills and qualities. Remember that your company is an ecosystem. Excellence for a security consultancy is very different from a 12 person VC backed startup, or a 5000 person enterprise hardware tech company Remember, again, excellence is SPECIFIC. All advice should come with context. I am NOT saying that excellence doesn’t matter and shouldn’t be sought, searched for or fought to achieve. it absolutely fucking matters. ALL of this is in the pursuit of excellence there are a million different ways excellence can flower, and a million different types excellence that can be called for. precision and specificity is how we bridge the gap. the more precise you can be about the excellence you need, and the more your org can build in the systems to develop that talent, the more your business does not have to pay top-10% salaries for top-10% talent.

“10x engineer” acts like that can all be ﬂattened to
one universal metric of productivity, like a personality attribute most of the world class engineers i’ve known are pretty humble people, because they know they AREN’T that special. They are the result of years of compounding hard work and opportunities and mentorship.

am saying that your org is a ✨system✨ Who will people become in the time they spend on your team? We (by which I mean the entire human race) place too much emphasis on individual agency and characteristics, and not enough on the systems that shape us and inform our behaviors. Any work you put into building a system where engineers are in the driver’s seat and can self-serve deploys, instrumentation, and fast feedback loops; where experimentation and learning is baseline, where feedback loops are fast and curiosity is rewarded.. will pay off over and over again.

am saying that talent is as common as dirt; the potential for excellence is everywhere. Be an org that values continuous learning and development, curiosity and experimentation, and invests in people. Know your business. You need to know your business, and craft a talent strategy that helps it succeed. What time horizon are you building for? A six month horizon calls for a very different strategy than a one or two year horizon, or a 5-10 year horizon. If you’re confident your company will exist in 10 years… How difficult, novel, and/or differentiating is the engineering labor you need to get done? How much specialized expertise does it take (or intersections of expertise)? Look at the most successful engineers in your org, the ones every manager would love to clone over and over and over again. What do they have in common? Don’t be one of those

In Praise of "Normal" Engineers (with full spea...

In Praise of "Normal" Engineers (with full speaker notes)

More Decks by Charity Majors

Other Decks in Technology

Featured

Transcript