优秀的团队关键在于“普通”工程师。
“Normal” engineers are the key to great teams

原始链接: https://spectrum.ieee.org/10x-engineer

这篇文章挑战了“10倍工程师”的观念,认为虽然高技能人才确实存在,但仅仅关注他们不利于构建高效的工程组织。生产力衡量存在缺陷,个人产出远不如团队绩效重要。作者强调,团队而非个人“拥有”软件。领导者应该致力于培养“普通”工程师也能脱颖而出的环境,而不是追逐难以捉摸的“10倍”人才。伟大的组织是为普通人而建的,考虑到了他们固有的偏见和局限性。这些系统能够将个人才华转化为产品价值。令人惊讶的是,这种环境还能通过提供成长和发挥作用的机会来“培养”世界一流的工程师。重点应该从招聘“最好”的人才转向招聘“合适”的人才,构建能够利用多元优势的包容性团队。这种方法能够吸引人才,促进创新,并创造可持续的竞争优势。

这篇 Hacker News 讨论帖围绕一篇 IEEE 文章展开,该文章认为“普通”工程师是优秀软件团队的关键,挑战了“10倍工程师”的神话。评论者们就杰出个人贡献者是否存在及其价值与强大的团队和流程的重要性展开了辩论。 一些人认为,真正杰出的人才推动创新和生产力,并以 Linus Torvalds 为例。另一些人认为,这些“10倍”工程师可能会造成破坏,需要强大的管理才能有效地发挥他们的才能。一些评论者认为,真正的“10倍”影响来自于赋能和指导其他团队成员,从而提高团队整体绩效。 许多人同意,持续的努力和明确的流程对于持续成功至关重要,过度依赖个人明星可能会造成漏洞。一些人还认为,招聘团队契合度和特定技能比寻找神话般的“最佳”候选人更重要。另一些人则反驳说,绝不应该接受平均水平的表现。这场讨论展现了反映不同环境的各种观点。
相关文章
  • (评论) 2025-03-15
  • 产品经理的角色是一个错误 2023-10-30
  • (评论) 2024-04-13
  • (评论) 2024-07-08
  • 工程领导者意想不到的反模式 2024-06-01

  • 原文

    A version of this post originally appeared in Refactoring, a Substack offering advice for software engineers.

    Most of us have encountered a few software 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 nonobvious yet elegant solutions, or emit waves of high-quality code at unreal velocity.

    I have run into many of these incredible beings over the course of my career. I think their existence is what explains the curious durability of the notion of a “10x engineer,” someone who is 10 times as productive or skilled as their peers. The ideawhich has become a meme—is based on flimsy, shoddy research, and the claims people have made to defend it have often been risible (for example, 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers) or blatantly double down on stereotypes (“we look for young dudes in hoodies who remind us of Mark Zuckerberg”). But damn if it doesn’t resonate with experience. It just feels true.

    I don’t have a problem with the idea that there are engineers who are 10 times as productive as other engineers. 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 the magnitude of skills and experiences at play:

    • Are you working on microprocessors, IoT, database internals, Web services, user experience, mobile appswhat?
    • Are you using Golang, Python, Cobol, or Lisp? Which version, libraries, and frameworks? What other software must you have mastered?
    • What adjacent skills, market segments, and product subject matter expertise are you drawing upon? Design, security, compliance, data visualization, marketing, finance?
    • What stage of development? What scale of usage? Are you writing for a Mars rover, or shrink-wrapped software you can never change?

    Also, people and their skills and abilities are not static. At one point, I was a pretty good database reliability engineer. Maybe I was even a 10x database engineer then, but certainly not now. I haven’t debugged a query plan in years.

    “10x engineer” makes it sound like 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 average (or below average). I know a lot of world-class engineers, but I’ve never met anyone who is 10 times better than everyone else across the board, in every situation.

    Engineers don’t own software, teams own software

    Second, and even more importantly: So what? Individual engineers don’t own software; engineering teams own software. 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.

    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’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.

    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 and going out of business. But as you start to grow as a company, ownership needs to get handed over to a team. Individual engineers get sick, go on vacation, and leave the company, and the business has to be resilient to that.

    When a team owns the software, then the key job of any engineering leader is to craft a high-performing engineering team. If you must 10x something, build 10x engineering teams.

    The best engineering organizations are the ones where normal engineers can do great work

    When people talk about world-class engineering organizations, they often have in mind teams that are top-heavy with staff and principal engineers, or that recruit heavily from the ranks of former Big Tech employees and top universities. 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 to 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 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.

    Anyone can build an org where the most experienced, brilliant engineers in the world can create products and make progress. That’s not hard. And putting all the spotlight on individual ability has a way of letting your leaders off the hook from doing their jobs. It is a huge competitive advantage if you can build systems where less experienced engineers can convert their effort and energy into product and business momentum. And the only meaningful measure of productivity is whether or not you are moving the business materially forward.

    A truly great engineering org also happens to be one that mints world-class software engineers. But I’m getting ahead of myself here.

    Let’s talk about “normal” engineers

    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, as seen in Netflix’s claim that “we look for the top 10 percent of global talent” or Coinbase’s desire to “hire the top 0.1 percent.” I would like to challenge us to set that baggage to the side and think about ourselves asnormal people.

    It can be humbling to think of yourself as a normal person. But most of us are, 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, and so on.

    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.

    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. 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 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 a.m., we are much more likely to make mistakes while responding to that alert than if we tried to do the same thing at 3 p.m. Our emotional state can affect the quality of our work.

    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.

    Great engineering orgs mint world-class engineers

    A great engineering organization is one where you don’t have to be one of the best engineers in the world to have a lot of impact. But—rather ironically—great engineering orgs mint world-class engineers like nobody’s business.

    The best engineering orgs are not the ones with the smartest, most experienced people in the world. They’re the ones where normal software engineers can consistently make progress, deliver value to users, and move the business forward. Places where engineers can have a large impact are a magnet for top performers. Nothing makes engineers happier than building things, solving problems, and making progress.

    If you’re lucky enough to have world-class engineers in your organization, 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’t 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. That’s probably why so many tech companies seem to obsess over identifying and hiring them, especially in Silicon Valley.

    But companies attach too much importance to finding these people after they’ve 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’t hire the “best” people. Hire the right people

    We place too much emphasis on individual agency and characteristics, and not enough on the systems that shape us and inform our behaviors.

    I believe a whole slew of issues (candidates self-selecting out of the interview process, diversity of applicants, and more) would be improved simply by shifting the focus of hiring away from this inordinate emphasis on hiring the best people and realigning around the more reasonable and accurate right people.

    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; where inclusivity is a given both for ethical reasons and because it raises the bar for performance for everyone. Inclusive culture is what meritocracy depends on.

    This is the kind of place that engineering talent is drawn to like a moth to a flame. It feels good to move the business forward, 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 and train the next generation.

    From Your Site Articles

    Related Articles Around the Web

    联系我们 contact @ memedata.com