{ "archive_path": "archive/1766158857.518876", "base_url": "charity.wtf/2025/06/19/in-praise-of-normal-engineers", "basename": "", "bookmarked_date": "2025-12-19 15:40", "canonical": { "archive_org_path": "https://web.archive.org/web/charity.wtf/2025/06/19/in-praise-of-normal-engineers", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=charity.wtf", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "charity.wtf", "downloaded_at": "2025-12-19T15:41:00.807686+00:00", "downloaded_datestr": "2025-12-19 15:41", "extension": "", "hash": "SZ07D6VY6PS408RQHXW6", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-19T15:42:44.481497+00:00", "index_texts": null, "output": "TimeoutExpired: Command '['/usr/bin/curl', '--silent', '--location', '--compressed', '--proxy', 'socks5://tor-socks-proxy:9150', '--head', '--max-time', '60', '--user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)', 'https://web.archive.org/save/https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/']' timed out after 60 seconds", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:44.207869+00:00", "status": "failed" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/" ], "cmd_version": "131.0.6778", "end_ts": "2025-12-19T15:41:23.175998+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:10.980503+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=charity.wtf" ], "cmd_version": "8.10.1", "end_ts": "2025-12-19T15:41:05.140109+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:01.688549+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-19T15:41:05.446391+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:05.177136+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2025-12-19T15:41:39.375505+00:00", "index_texts": [ "(http://gmpg.org/xfn/11) (https://charity.wtf/xmlrpc.php) In Praise of \u201cNormal\u201d Engineers \u2013 charity.wtf (//secure.gravatar.com) (//stats.wp.com) (//fonts-api.wp.com) (//widgets.wp.com) (//jetpack.wordpress.com) (//s0.wp.com) (//public-api.wordpress.com) (//0.gravatar.com) (//1.gravatar.com) (//2.gravatar.com) (//i0.wp.com) (//c0.wp.com) (charity.wtf \u00bb Feed) (https://charity.wtf/feed/) (charity.wtf \u00bb Comments Feed) (https://charity.wtf/comments/feed/) (charity.wtf \u00bb In Praise of \u201cNormal\u201d Engineers Comments Feed) (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/feed/) (oEmbed (JSON)) (https://charity.wtf/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fcharity.wtf%2F2025%2F06%2F19%2Fin-praise-of-normal-engineers%2F) (oEmbed (XML)) (https://charity.wtf/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fcharity.wtf%2F2025%2F06%2F19%2Fin-praise-of-normal-engineers%2F&format=xml) (https://c0.wp.com/c/6.9/wp-includes/css/dist/components/style.min.css) (https://charity.wtf/wp-content/plugins/coblocks/includes/Dependencies/GoDaddy/Styles/build/latest.css?ver=2.0.2) (https://charity.wtf/wp-content/plugins/jetpack/_inc/genericons/genericons/genericons.css?ver=3.1) (https://charity.wtf/wp-content/themes/minnow/style.css?ver=6.9) (//fonts-api.wp.com/css?family=Open+Sans%3A300%2C400%2C700%2C700italic%2C400italic%2C300italic%7COpen+Sans+Condensed%3A700%2C700italic&subset=latin%2Clatin-ext) (https://charity.wtf/wp-content/plugins/jetpack/modules/comments/subscription-modal-on-comment/subscription-modal.css?ver=15.4-a.3) (https://charity.wtf/wp-content/plugins/jetpack/modules/likes/style.css?ver=15.4-a.3) (https://charity.wtf/wp-content/plugins/jetpack/modules/sharedaddy/sharing.css?ver=15.4-a.3) (https://charity.wtf/wp-content/plugins/jetpack/_inc/social-logos/social-logos.min.css?ver=15.4-a.3) (https://charity.wtf/wp-json/) (JSON) (https://charity.wtf/wp-json/wp/v2/posts/10001) (RSD) (https://charity.wtf/xmlrpc.php?rsd) (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/) (https://wp.me/p74lOS-2Bj) (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/amp/) (https://s0.wp.com/i/webclip.png) (https://s0.wp.com/i/webclip.png) (https://s0.wp.com/i/webclip.png) (https://c0.wp.com/c/6.9/wp-includes/blocks/heading/style.min.css) (https://c0.wp.com/c/6.9/wp-includes/blocks/group/style.min.css) (https://c0.wp.com/c/6.9/wp-includes/blocks/paragraph/style.min.css) (https://charity.wtf/wp-content/plugins/jetpack/_inc/blocks/swiper.css?ver=15.4-a.3) (https://charity.wtf/wp-content/plugins/jetpack/modules/carousel/jetpack-carousel.css?ver=15.4-a.3) (https://charity.wtf/wp-content/plugins/jetpack/_inc/blocks/subscriptions/view.css?minify=false&ver=15.4-a.3) (https://0.gravatar.com/js/hovercards/hovercards.min.css?ver=0.15.0-1) Skip to content (https://charity.wtf/) (https://charity.wtf/) charity.wtf charity wtf's about technology, databases, startups, engineering management, and whiskey. (Sidebar) Sidebar Pages (https://charity.wtf/about/) About me Recent Posts (https://charity.wtf/2025/12/19/hello-world-xpost-from-substack/) Hello World (xpost from substack) (https://charity.wtf/2025/12/14/moving-from-wordpress-to-substack/) Moving from WordPress to Substack (https://charity.wtf/2025/11/24/from-cloudwashing-to-o11ywashing/) From Cloudwashing to O11ywashing (https://charity.wtf/2025/10/30/the-pillar-is-a-lie/) How many pillars of observability can you fit on the head of a pin? (https://charity.wtf/2025/10/13/got-opinions-on-observability-i-could-use-your-help-once-more-with-feeling/) Got opinions on observability? I could use your help (once more, with feeling) Archives (https://charity.wtf/2025/12/) December 2025 (https://charity.wtf/2025/11/) November 2025 (https://charity.wtf/2025/10/) October 2025 (https://charity.wtf/2025/09/) September 2025 (https://charity.wtf/2025/07/) July 2025 (https://charity.wtf/2025/06/) June 2025 (https://charity.wtf/2025/05/) May 2025 (https://charity.wtf/2025/04/) April 2025 (https://charity.wtf/2025/03/) March 2025 (https://charity.wtf/2025/02/) February 2025 (https://charity.wtf/2024/12/) December 2024 (https://charity.wtf/2024/11/) November 2024 (https://charity.wtf/2024/10/) October 2024 (https://charity.wtf/2024/08/) August 2024 (https://charity.wtf/2024/07/) July 2024 (https://charity.wtf/2024/06/) June 2024 (https://charity.wtf/2024/01/) January 2024 (https://charity.wtf/2023/12/) December 2023 (https://charity.wtf/2023/09/) September 2023 (https://charity.wtf/2023/08/) August 2023 (https://charity.wtf/2023/06/) June 2023 (https://charity.wtf/2023/05/) May 2023 (https://charity.wtf/2023/03/) March 2023 (https://charity.wtf/2023/02/) February 2023 (https://charity.wtf/2022/10/) October 2022 (https://charity.wtf/2022/09/) September 2022 (https://charity.wtf/2022/08/) August 2022 (https://charity.wtf/2022/07/) July 2022 (https://charity.wtf/2022/06/) June 2022 (https://charity.wtf/2022/04/) April 2022 (https://charity.wtf/2022/03/) March 2022 (https://charity.wtf/2022/01/) January 2022 (https://charity.wtf/2021/08/) August 2021 (https://charity.wtf/2021/06/) June 2021 (https://charity.wtf/2021/04/) April 2021 (https://charity.wtf/2021/03/) March 2021 (https://charity.wtf/2021/02/) February 2021 (https://charity.wtf/2021/01/) January 2021 (https://charity.wtf/2020/12/) December 2020 (https://charity.wtf/2020/11/) November 2020 (https://charity.wtf/2020/10/) October 2020 (https://charity.wtf/2020/09/) September 2020 (https://charity.wtf/2020/07/) July 2020 (https://charity.wtf/2020/05/) May 2020 (https://charity.wtf/2020/04/) April 2020 (https://charity.wtf/2020/03/) March 2020 (https://charity.wtf/2019/12/) December 2019 (https://charity.wtf/2019/11/) November 2019 (https://charity.wtf/2019/10/) October 2019 (https://charity.wtf/2019/09/) September 2019 (https://charity.wtf/2019/05/) May 2019 (https://charity.wtf/2019/04/) April 2019 (https://charity.wtf/2019/02/) February 2019 (https://charity.wtf/2019/01/) January 2019 (https://charity.wtf/2018/12/) December 2018 (https://charity.wtf/2018/10/) October 2018 (https://charity.wtf/2018/08/) August 2018 (https://charity.wtf/2018/03/) March 2018 (https://charity.wtf/2018/02/) February 2018 (https://charity.wtf/2017/05/) May 2017 (https://charity.wtf/2016/10/) October 2016 (https://charity.wtf/2016/06/) June 2016 (https://charity.wtf/2016/05/) May 2016 (https://charity.wtf/2016/04/) April 2016 (https://charity.wtf/2016/03/) March 2016 (https://charity.wtf/2016/02/) February 2016 (https://charity.wtf/2015/12/) December 2015 Categories (https://charity.wtf/category/acquisitions/) acquisitions (https://charity.wtf/category/ai/) AI (https://charity.wtf/tag/aws/) aws (https://charity.wtf/category/books/) books (https://charity.wtf/category/crossposted/) crossposted (https://charity.wtf/category/databases/) databases (https://charity.wtf/category/deploys/) deploys (https://charity.wtf/tag/devops/) devops (https://charity.wtf/tag/management/) management (https://charity.wtf/category/niblets/) niblets (https://charity.wtf/category/observability/) observability (https://charity.wtf/tag/operations/) operations (https://charity.wtf/category/pendulum/) pendulum (https://charity.wtf/category/politics/) politics (https://charity.wtf/tag/security/) security (https://charity.wtf/tag/serverless/) serverless (https://charity.wtf/tag/sre/) sre (https://charity.wtf/category/startup/) startup (https://charity.wtf/tag/tech-culture/) tech culture (https://charity.wtf/category/uncategorized/) Uncategorized (https://charity.wtf/category/vendor/) vendor Search for: (Search \u2026) () (Search) Meta (https://charity.wtf/wp-login.php) Log in (https://charity.wtf/feed/) Entries feed (https://charity.wtf/comments/feed/) Comments feed (https://wordpress.org/) WordPress.org In Praise of \u201cNormal\u201d Engineers (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/) June 19, 2025 June 19, 2025 (https://charity.wtf/author/mipsytipsy/) mipsytipsy (https://charity.wtf/tag/10x-engineers/) 10x engineers , (https://charity.wtf/tag/crossposted/) crossposted , (https://charity.wtf/tag/engineering-culture/) engineering culture , (https://charity.wtf/tag/high-performing-teams/) high performing teams , (https://charity.wtf/tag/teams/) teams This article was originally (https://refactoring.fm/p/in-praise-of-normal-engineers) commissioned by Luca Rossi (paywalled) for refactoring.fm, on February 11th, 2025. Luca edited a version of it that emphasized the importance of building \u201c10x engineering teams\u201d . It was later picked up by IEEE Spectrum (!!!), who scrapped most of the teams content and published a (https://spectrum.ieee.org/10x-engineer) different, shorter piece on March 13th. This is my personal edit. It is not exactly identical to either of the versions that have been publicly released to date. It contains a lot of the source material for the talk I gave last week at #LDX3 in London, \u201c(https://speakerdeck.com/charity/in-praise-of-normal-engineers-ldx3) In Praise of \u2018Normal\u2019 Engineers \u201d (slides), and a couple weeks ago at CraftConf. In Praise of \u201cNormal\u201d Engineers 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.(In Praise of \"Normal\" Engineers) 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 \u201c10x engineer\u201d meme. It may be based on flimsy, shoddy research, and the claims people have made to defend it have often been\u00a0risible (e.g. \u201c10x engineers have dark backgrounds, are rarely seen doing UI work, are poor mentors and interviewers\u201d), or blatantly double down on stereotypes (\u201cwe look for young dudes in hoodies that remind us of Mark Zuckerberg\u201d). But damn if it doesn\u2019t 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\u2019t have a problem with this statement; in fact, that much seems self-evidently true. The problems I do have are twofold. Measuring productivity is fraught and imperfect 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: Are you working on microprocessors, IoT, database internals, web services, user experience, mobile apps, consulting, embedded systems, cryptography, animation, training models for gen AI\u2026 what? Are you using golang, python, COBOL, lisp, perl, React, or brainfuck? What version, which libraries, which frameworks, what data models? What other software and build dependencies must you have mastered?() What adjacent skills, market segments, or product subject matter expertise are you drawing upon\u2026design, security, compliance, data visualization, marketing, finance, etc? What stage of development? What scale of usage? What matters most \u2014 giving good advice in a consultative capacity, prototyping rapidly to find product-market fit, or writing code that is maintainable and performant over many years of amortized maintenance? Or are you writing for the Mars Rover, or shrinkwrapped software you can never change? 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\u2019t debugged a query plan in years. \u201c10x engineer\u201d 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\u2019ve never met anyone who is 10x better than everyone else across the board, in every situation. Engineers don\u2019t own software, teams own software Second, and even more importantly: So what? It doesn\u2019t matter. Individual engineers don\u2019t own software, teams own software. The smallest unit of software ownership and delivery is the engineering team . It doesn\u2019t 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. Everyone uses the same software delivery pipeline. If it takes the slowest engineer at your company five hours to ship a single line of code, it\u2019s 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. If you have services or software components that are owned by a single engineer, that person is a single point of failure.() I\u2019m not saying this should never happen. It\u2019s 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\u2026ownership 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. If teams own software, then the key job of any engineering leader is to craft high-performing engineering teams. If you must 10x something, 10x this. Build 10x engineering teams. The best engineering orgs are the ones where normal engineers can do great work 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. But I would argue that a truly great engineering org is one where you don\u2019t HAVE to be one of the \u201cbest\u201d or most pedigreed engineers in the world to get shit done and have a lot of impact on the business. I think it\u2019s 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\u2019ve built, and move the business forward a little bit more, day by day, week by week. 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. A truly great engineering org also happens to be one that mints world-class software engineers. But we\u2019re getting ahead of ourselves, here. Let\u2019s talk about \u201cnormal\u201d for a moment 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\u2019s \u201cwe look for the top 10% of global talent\u201d to Amazon\u2019s talk about \u201cbar-raising\u201d or Coinbase\u2019s recent claim to \u201chire the top .1%\u201d. (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 \u2014 kinesthetic, emotional, spatial, musical, linguistic, etc. 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\u2019t think there\u2019s 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. Build sociotechnical systems with \u201cnormal people\u201d 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 \u2014 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. How do you turn normal engineers into 10x engineering teams? None of this should be terribly surprising; it\u2019s all well known wisdom. In order to build the kind of sociotechnical systems for software delivery that enable normal engineers to move fast, learn continuously, and deliver great results as a team, you should: 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\u2019ve 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\u2019ve referred to this as the \u201csoftware engineering death spiral\u201d \u2026 when the deploy cycle takes so long that you end up batching together a bunch of engineers\u2019 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\u2019s 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\u2019re very stressed, tired, and\u00a0possibly 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\u2019ll never know \u2014 not really \u2014 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\u2019t 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 \u201ceverybody\u2019s job\u201d, they will end up nobody\u2019s job. Engineering productivity isn\u2019t 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. 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 \u2014 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 \u2014 when this is just table stakes, standard operating procedure \u2014 you\u2019re better equipped to roll with it when life happens. Assemble engineering teams from a range of levels. The best engineering teams aren\u2019t 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. By the way \u2014 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 and over again. The only meaningful measure of productivity is impact to the business 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\u2026we can\u2019t 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\u2019t answer without help from product, design, and the rest of the business. Software engineering isn\u2019t about writing lots of lines of code, it\u2019s about solving business problems using technology. Senior and intermediate engineers are actually the workhorses of the industry. They move the business forward, step by step, day by day. They get to put their heads down and crank instead of constantly looking around the org and solving coordination problems. If you have to be a staff+ engineer to move the product forward, something is seriously wrong. Great engineering orgs mint world-class engineers A great engineering org is one where you don\u2019t HAVE to be one of the best engineers in the world to have a lot of impact. But \u2014 rather ironically \u2014 great engineering orgs mint world class engineers like nobody\u2019s business. The best engineering orgs are not the ones with the smartest, most experienced people in the world, they\u2019re the ones where normal software engineers can consistently make progress, deliver value to users, and move the business forward, day after day.() Places where engineers can get shit done and have a lot of impact are a magnet for top performers. Nothing makes engineers happier than building things, solving problems, making progress. If you\u2019re lucky enough to have world-class engineers in your org, good for you! Your role as a leader is to leverage their brilliance for the good of your customers and your other engineers, without coming to depend on their brilliance. After all, these people don\u2019t belong to you. They may walk out the door at any moment, and that has to be okay. These people can be phenomenal assets, assuming they can be team players and keep their egos in check. Which is probably why so many tech companies seem to obsess over identifying and hiring them, especially in Silicon Valley. But companies categorically overindex on finding these people after they\u2019ve already been minted, which ends up reinforcing and replicating all the prejudices and inequities of the world at large. Talent may be evenly distributed across populations, but opportunity is not. Don\u2019t hire the \u201cbest\u201d people. Hire the right people. 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. 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 and realigning around the more reasonable and accurate RIGHT PEOPLE. () It\u2019s 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\u00a0because 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\u2019s the kind of place that people go when they want to become world class engineers. And it\u2019s the kind of place where world class engineers want to stick around, to train up the next generation. <3, charity Share this: (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?share=twitter&nb=1) Click to share on X (Opens in new window) X (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?share=facebook&nb=1) Click to share on Facebook (Opens in new window) Facebook Like this: Like Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/) In Praise of \u201cNormal\u201d Engineers Post navigation (https://charity.wtf/2025/06/08/on-how-long-it-takes-to-know-if-a-job-is-right-for-you-or-not/) \u2190 On How Long it Takes to Know if a Job is Right for You or Not (https://charity.wtf/2025/07/09/thoughts-on-motivation-and-my-40-year-career/) Thoughts on Motivation and My 40-Year Career \u2192 21 thoughts on \u201cIn Praise of \u201cNormal\u201d Engineers \u201d () foo says: Years of toiling in businesses that had zero clue wrt. management have led me to basically the same conclusions. I\u2019m going to use this post to craft a set of questions for the next time I\u2019ll be interviewing with a prospective employer, i.e. tomorrow! Perfect timing, thanks <3 Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7058) June 19, 2025 at 7:01 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7058#respond) Reply () (http://charitydotwtf.wordpress.com) mipsytipsy says: GOOD LUCK to you!! and if it\u2019s not too late \u2026 check out this post i wrote a couple years ago, on how to interview a company. might be timely / useful for your purposes. <3 (https://charity.wtf/2022/01/29/how-can-you-tell-if-the-company-youre-interviewing-with-is-rotten-on-the-inside/) https://charity.wtf/2022/01/29/how-can-you-tell-if-the-company-youre-interviewing-with-is-rotten-on-the-inside/ Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7062) June 19, 2025 at 7:39 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7062#respond) Reply () foo says: Thank you! For the kind words, and for the extra ammunition/links. Definitely not too late, as tomorrow I\u2019ll just reconnect with a former colleague: not a formal interview, but also not just a friendly chat. Barring any red flag, I\u2019ll probably formally interview with his employer in the coming weeks. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7064) June 19, 2025 at 10:01 pm () (http://charitydotwtf.wordpress.com) mipsytipsy says: and another one: (https://charity.wtf/2021/02/19/questionable-advice-how-can-i-sniff-out-bad-managers-while-interviewing-for-a-job/) https://charity.wtf/2021/02/19/questionable-advice-how-can-i-sniff-out-bad-managers-while-interviewing-for-a-job/ Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7063) June 19, 2025 at 7:39 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7063#respond) Reply () Konrad says: That is a very good read, thanks for writing it up! Beyond that, I would like to call out the tiny, colorful graphics \u2013 not sure whether these are real stickers or how they were made (ai?) but they are dope. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7066) June 19, 2025 at 10:45 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7066#respond) Reply () (http://charitydotwtf.wordpress.com) mipsytipsy says: Thank you!! Me + ChatGPT, fucking around together late at night. I might turn some of them into stickers though.. I like them too!! \ud83d\ude00 Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7075) June 20, 2025 at 11:45 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7075#respond) Reply () Ayudh Sharma says: good stuff Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7068) June 20, 2025 at 5:58 am (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7068#respond) Reply () Andrew Ritchie says: Lots of awesomeness to digest here as always Charity, thanks for sharing Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7069) June 20, 2025 at 6:52 am (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7069#respond) Reply () (http://vbelolapotkov.wordpress.com) Vasily Belolapotkov says: Thanks for writing this, Charity, lots of things resonated with me! I\u2019ve been always thinking about software development as team sports, where a team with normal good players complimenting each other can outperform a team with the best players in the league. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7070) June 20, 2025 at 10:45 am (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7070#respond) Reply () (http://charitydotwtf.wordpress.com) mipsytipsy says: yes! if you haven\u2019t read it, i really loved teh netflix culture book, called \u201cNo Rules Rules\u201d. Reed and his coauthor talk about this in great detail.. i loved it. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7087) June 28, 2025 at 4:00 am (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7087#respond) Reply () Personal says: \u201cWhen your teams are used to operating with a mix of genders, racial backgrounds, identities, age ranges, family statuses, geographical locations, skill sets, etc \u2014 when this is just table stakes, standard operating procedure \u2014 you\u2019re better equipped to roll with it when life happens.\u201d Spoken like someone who does not own a company, or who just gets paid a salary for regardless of output. If it\u2019s your money on the line, do you want the best or do you want to chase woke goals to impress the people who aren\u2019t using your products in the first place. Hire to do work, based on competencies. What you suggest is illegal to hire based on skin or other factors. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7073) June 20, 2025 at 3:44 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7073#respond) Reply () (http://charitydotwtf.wordpress.com) mipsytipsy says: I didn\u2019t say \u201chire based on skin\u201d (sic), I said diverse teams are more resilient teams. And you clearly don\u2019t know who you\u2019re talking to. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7074) June 20, 2025 at 11:43 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7074#respond) Reply () daugavpils2000 says: Genuine interest here. Could you please elaborate on the thesis about diverse team being more resilient?I can see why this can be a value but the devil is in the details. Too much diversity, especially in how values are perceived, and you will end up with a team that does not have a common direction. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7083) June 27, 2025 at 7:48 am () (http://charitydotwtf.wordpress.com) mipsytipsy says: Ooooohhhh, yeah, lack of alignment or shared values or sense of mission will fuck a team up fast, but I think that\u2019s a slightly different matter. I\u2019m not arguing for doing anything silly, like, idk, casting teams to look like Benetton ads. I\u2019m not saying that identity issues are the MOST important thing. But people do their best work when they feel a sense of belonging, and having a variety of perspectives typically leads to more creative solutions. By default, humans tend to prefer (and surround ourselves with) people like ourselves. I just think we should try to be conscious of this tendency we all have so we can try to lean against it, and give people _less_ similar to ourselves an equally fair shake. Does that help? Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7086) June 28, 2025 at 3:59 am () (https://jomcgi.dev) Joe says: This gave me a lot to think about! Appreciate you sharing content like this.I\u2019m moving to a new role so I\u2019ve been reflecting on what my previous org could have done better / what I should do in future. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7079) June 26, 2025 at 9:50 am (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7079#respond) Reply () (https://blog.koehntopp.info) Kristian K\u00f6hntopp says: Charity, there is an older, somewhat famous single page site (https://1x.engineer/) https://1x.engineer/ that picks up many of the same ideas. Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7097) July 2, 2025 at 6:19 am (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7097#respond) Reply () (http://charitydotwtf.wordpress.com) mipsytipsy says: Ooooo I love that, thank you! I\u2019ve seen this before but completely forgot about it. \ud83d\ude42 Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7115) July 9, 2025 at 8:20 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7115#respond) Reply () (https://www.linkedin.com/in/kvnkho/) Kevin Kho says: Thank you for the article. It really resonates with what I\u2019ve been feeling lately because my employer decided to bring in a technical lead who loves to build everything from scratch to the point that we\u2019re learning the frameworks they write. You write very well! Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7106) July 7, 2025 at 11:02 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7106#respond) Reply () (http://charitydotwtf.wordpress.com) mipsytipsy says: Thank you!! <3 Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7116) July 9, 2025 at 8:20 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7116#respond) Reply (https://jamesburt.me.uk/2025/08/weeknotes-2025-33-to-30/) Weeknotes: 2025-33 to 30 \u2013 James On Programming says: [\u2026] great piece from Charity Majors was In Praise of \u2018Normal\u2018 Engineers, where she talks about the importance of teams rather than individual developers, and how systems [\u2026] Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7253) August 16, 2025 at 10:11 am (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7253#respond) Reply (https://curtismchale.ca/2025/09/27/writing-tools-boredom-wins-and-average-is-okay/) Writing Tools, Boredom Wins, and Average is Okay \u2013 Curtis McHale says: [\u2026] we may have an area of expertise, most of us are pretty dang average on most things. I\u2019m a reasonably fast cyclist and love taking long adventures but I came 30th [\u2026] Loading... (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/#comment-7374) September 27, 2025 at 1:00 pm (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?replytocom=7374#respond) Reply Leave a Reply(/2025/06/19/in-praise-of-normal-engineers/#respond) Cancel reply (Comment Form) () (https://wordpress.com/?ref=footer_custom_powered) Powered by WordPress.com . Discover more from charity.wtf Subscribe now to keep reading and get access to the full archive. Type your email\u2026 (Type your email\u2026) () (Please fill in this field.) (subscribe) (104471542) (https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/) (subscribe-block) (atomic-subscription-modal-lo) (subscribe-blog) (en_US) (5b67a7fce2) (/2025/06/19/in-praise-of-normal-engineers/) (10001) Subscribe Continue reading Loading Comments... Write a Comment... (Write a Comment...) Email (Required) Name (Required) Website (Post Comment) %d () " ], "output": "htmltotext.txt", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:39.288130+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/" ], "cmd_version": "2024.10.7", "end_ts": "2025-12-19T15:41:44.125857+00:00", "index_texts": [], "output": "ArchiveError: Failed to save media", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:40.772331+00:00", "status": "failed" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/" ], "cmd_version": "2.2.3", "end_ts": "2025-12-19T15:41:39.257721+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:36.616788+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmphkcw1nod", "https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/" ], "cmd_version": "0.0.11", "end_ts": "2025-12-19T15:41:29.514242+00:00", "index_texts": [ "This article was originally commissioned by Luca Rossi (paywalled) for refactoring.fm, on February 11th, 2025. Luca edited a version of it that emphasized the importance of building \u201c10x engineering teams\u201d . It was later picked up by IEEE Spectrum (!!!), who scrapped most of the teams content and published a different, shorter piece on March 13th.\nThis is my personal edit. It is not exactly identical to either of the versions that have been publicly released to date. It contains a lot of the source material for the talk I gave last week at #LDX3 in London, \u201cIn Praise of \u2018Normal\u2019 Engineers\u201d (slides), and a couple weeks ago at CraftConf.\u00a0\nIn Praise of \u201cNormal\u201d Engineers\nMost 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.\nI 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 \u201c10x engineer\u201d meme. It may be based on flimsy, shoddy research, and the claims people have made to defend it have often been\u00a0risible (e.g. \u201c10x engineers have dark backgrounds, are rarely seen doing UI work, are poor mentors and interviewers\u201d), or blatantly double down on stereotypes (\u201cwe look for young dudes in hoodies that remind us of Mark Zuckerberg\u201d). But damn if it doesn\u2019t resonate with experience. It just feels true.\nThe problem is not the idea that there are engineers who are 10x as productive as other engineers. I don\u2019t have a problem with this statement; in fact, that much seems self-evidently true. The problems I do have are twofold.\nMeasuring productivity is fraught and imperfect\nFirst: 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:\n\nAre you working on microprocessors, IoT, database internals, web services, user experience, mobile apps, consulting, embedded systems, cryptography, animation, training models for gen AI\u2026 what?\nAre you using golang, python, COBOL, lisp, perl, React, or brainfuck? What version, which libraries, which frameworks, what data models? What other software and build dependencies must you have mastered?\nWhat adjacent skills, market segments, or product subject matter expertise are you drawing upon\u2026design, security, compliance, data visualization, marketing, finance, etc?\nWhat stage of development? What scale of usage? What matters most \u2014 giving good advice in a consultative capacity, prototyping rapidly to find product-market fit, or writing code that is maintainable and performant over many years of amortized maintenance? Or are you writing for the Mars Rover, or shrinkwrapped software you can never change?\n\nAlso: 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\u2019t debugged a query plan in years.\n\u201c10x engineer\u201d 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\u2019ve never met anyone who is 10x better than everyone else across the board, in every situation.\nEngineers don\u2019t own software, teams own software\nSecond, and even more importantly: So what? It doesn\u2019t matter. Individual engineers don\u2019t own software, teams own software. The smallest unit of software ownership and delivery is the engineering team. It doesn\u2019t 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.\nEveryone uses the same software delivery pipeline. If it takes the slowest engineer at your company five hours to ship a single line of code, it\u2019s 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.\nIf you have services or software components that are owned by a single engineer, that person is a single point of failure.\nI\u2019m not saying this should never happen. It\u2019s 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\u2026ownership 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.\nIf teams own software, then the key job of any engineering leader is to craft high-performing engineering teams. If you must 10x something, 10x this. Build 10x engineering teams.\nThe best engineering orgs are the ones where normal engineers can do great work\nWhen 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.\nBut I would argue that a truly great engineering org is one where you don\u2019t HAVE to be one of the \u201cbest\u201d or most pedigreed engineers in the world to get shit done and have a lot of impact on the business.\nI think it\u2019s 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\u2019ve built, and move the business forward a little bit more, day by day, week by week.\nAny 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.\nA truly great engineering org also happens to be one that mints world-class software engineers. But we\u2019re getting ahead of ourselves, here.\nLet\u2019s talk about \u201cnormal\u201d for a moment\nA 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\u2019s \u201cwe look for the top 10% of global talent\u201d to Amazon\u2019s talk about \u201cbar-raising\u201d or Coinbase\u2019s recent claim to \u201chire the top .1%\u201d. (Seriously, guys? Ok, well, Honeycomb is going to hire only the top .00001%!)\nIn this essay, I would like to challenge us to set that baggage to the side and think about ourselves as normal people.\nIt 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 \u2014 kinesthetic, emotional, spatial, musical, linguistic, etc.\nSoftware 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\u2019t think there\u2019s 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.\nBuild sociotechnical systems with \u201cnormal people\u201d in mind\nWhen 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.\n\nNormal people have cognitive biases \u2014 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.\nWe 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.\nWhen 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.\nHow do you turn normal engineers into 10x engineering teams?\nNone of this should be terribly surprising; it\u2019s all well known wisdom. In order to build the kind of sociotechnical systems for software delivery that enable normal engineers to move fast, learn continuously, and deliver great results as a team, you should:\nShrink the interval between when you write the code and when the code goes live.\nMake it as short as possible; the shorter the better. I\u2019ve 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.\nOne 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\u2019ve referred to this as the \u201csoftware engineering death spiral\u201d \u2026 when the deploy cycle takes so long that you end up batching together a bunch of engineers\u2019 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.\nDeploy 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.\nMake it easy and fast to roll back or recover from mistakes.\nDevelopers should be able to deploy their own code, figure out if it\u2019s working as intended or not, and if not, roll forward or back swiftly and easily. No muss, no fuss, no thinking involved.\nMake it easy to do the right thing and hard to do the wrong thing. \nWrap 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\u2019re very stressed, tired, and\u00a0possibly 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.\nInvest in instrumentation and observability.\nYou\u2019ll never know \u2014 not really \u2014 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.\nBeing able to visualize your work is what makes engineering abstractions accessible to actual engineers. You shouldn\u2019t have to be a world-class engineer just to debug your own damn code.\nDevote engineering cycles to internal tooling and enablement.\nIf fast, safe deploys, with guard rails, instrumentation, and highly parallelized test suites are \u201ceverybody\u2019s job\u201d, they will end up nobody\u2019s job. Engineering productivity isn\u2019t 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.\nBuild an inclusive culture.\nGrowth 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.\nDiverse teams are resilient teams.\nYeah, 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 \u2014 fast.\nWhen your teams are used to operating with a mix of genders, racial backgrounds, identities, age ranges, family statuses, geographical locations, skill sets, etc \u2014 when this is just table stakes, standard operating procedure \u2014 you\u2019re better equipped to roll with it when life happens.\nAssemble engineering teams from a range of levels.\nThe best engineering teams aren\u2019t 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.\nBy the way \u2014 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.\nIt gets used and reused. Over and over and over again.\nThe only meaningful measure of productivity is impact to the business\nThe only thing that actually matters when it comes to engineering productivity is whether or not you are moving the business materially forward.\nWhich means\u2026we can\u2019t 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\u2019t answer without help from product, design, and the rest of the business.\nSoftware engineering isn\u2019t about writing lots of lines of code, it\u2019s about solving business problems using technology.\nSenior and intermediate engineers are actually the workhorses of the industry. They move the business forward, step by step, day by day. They get to put their heads down and crank instead of constantly looking around the org and solving coordination problems. If you have to be a staff+ engineer to move the product forward, something is seriously wrong.\nGreat engineering orgs mint world-class engineers\nA great engineering org is one where you don\u2019t HAVE to be one of the best engineers in the world to have a lot of impact. But \u2014 rather ironically \u2014 great engineering orgs mint world class engineers like nobody\u2019s business.\nThe best engineering orgs are not the ones with the smartest, most experienced people in the world, they\u2019re the ones where normal software engineers can consistently make progress, deliver value to users, and move the business forward, day after day.\nPlaces where engineers can get shit done and have a lot of impact are a magnet for top performers. Nothing makes engineers happier than building things, solving problems, making progress.\nIf you\u2019re lucky enough to have world-class engineers in your org, good for you! Your role as a leader is to leverage their brilliance for the good of your customers and your other engineers, without coming to depend on their brilliance. After all, these people don\u2019t belong to you. They may walk out the door at any moment, and that has to be okay.\nThese people can be phenomenal assets, assuming they can be team players and keep their egos in check. Which is probably why so many tech companies seem to obsess over identifying and hiring them, especially in Silicon Valley.\nBut companies categorically overindex on finding these people after they\u2019ve already been minted, which ends up reinforcing and replicating all the prejudices and inequities of the world at large. Talent may be evenly distributed across populations, but opportunity is not.\nDon\u2019t hire the \u201cbest\u201d people. Hire the right people.\nWe (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.\nI 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 and realigning around the more reasonable and accurate RIGHT PEOPLE. \nIt\u2019s 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\u00a0because it raises the bar for performance for everyone. Inclusive culture is what actual meritocracy depends on.\nThis 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\u2019s the kind of place that people go when they want to become world class engineers. And it\u2019s the kind of place where world class engineers want to stick around, to train up the next generation.\n<3, charity" ], "output": "readability/", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:23.930603+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-19T15:41:23.292625+00:00", "index_texts": null, "output": "In Praise of \u201cNormal\u201d Engineers \u2013 charity.wtf", "pwd": "/data/archive/1766158857.518876", "schema": "ArchiveResult", "start_ts": "2025-12-19T15:41:23.229198+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "TimeoutExpired: Command '['/usr/bin/curl', '--silent', '--location', '--compressed', '--proxy', 'socks5://tor-socks-proxy:9150', '--head', '--max-time', '60', '--user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)', 'https://web.archive.org/save/https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/']' timed out after 60 seconds", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "ArchiveError: Failed to save media", "pdf": null, "screenshot": null, "singlefile": null, "title": "In Praise of \u201cNormal\u201d Engineers \u2013 charity.wtf", "warc": null, "wget": null }, "link_dir": "/data/archive/1766158857.518876", "newest_archive_date": "2025-12-19T15:41:44.207869+00:00", "num_failures": 2, "num_outputs": 7, "oldest_archive_date": "2025-12-19T15:41:01.688549+00:00", "path": "/2025/06/19/in-praise-of-normal-engineers/", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01KCVMAXBEBD183ADD01MHQYBP", "snapshot_id": "824a83ea-c3ec-4420-90de-bca0e91bf976", "sources": [ "/data/sources/1766158856-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1766158857.518876", "title": "In Praise of \u201cNormal\u201d Engineers \u2013 charity.wtf", "url": "https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/" }