> The smallest unit of software ownership and delivery is the engineering team.
I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in days or weeks, while, on the best teams I've seen, it's measured in months, quarters or years.
It's counterintuitive, but you absolutely can have real individual owernship for engineers without creating single points of failure or brittle systems. It's a matter of having other sources of slack, encouraging quality work, and giving people a lot of room to fluidly adjust what they're working on when. Folks still have real ownership and can make longer-term decisions on their own, but they also collaborate in ad hoc ways and share tacit knowledge, so that somebody else can jump in, help out or even take over in a pinch. I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.
In practice, the model I saw did end up with more rewriting than a normal team—but we were still way more productive overall, even accounting for the rewrites! Turns out that rewriting systems incrementally, in self-contained chunks, is an amazing way to both evolve the design and to build up instutitional knowledge and capacity. It looks like waste, but it's actually slack that is crucial to making your system as a whole more flexible, adaptable and resilient. (In fact, that's true of a lot of the "waste" top-down management systems try to reduce—I'm incresingly convinced that anybody trying to optimize software team "utilization" is actively sabotaging the work!)
People outside of engineering can't give engineers immediate credit for long-term decisions. They don't have the competency to know what to reward.
I'd go further and say that even within engineering, people outside of a team can't give immediate rewards for work whose long-term value is internal to the team, for the same reason: they don't know if the work you're doing is actually valuable or is just superficially similar to the kind of work that often does have long-term value.
If you're confident enough in your long-term decisions, and how you spend slack time, then you should be fine with being rewarded for delivery, since you expect your long-term work to pay off in future delivery and future rewards.
I think that rewrites are an important part of how software is written, and it's an important part of being "agile", in the sense that you can go in and write a prototype that's coded very simply without much regard for long-term architecture, knowing that requirements likely will change and that you likely won't get the design right on the first go anyways.
Coding is like writing, in the sense that it's often faster to write a sloppy first draft followed by a better second draft than it is to agonize over getting the first draft right on the first go. The first draft is generative. Its purpose is not to be good but instead to let you get something built quickly and to let you explore the problem, so that you know what edge cases you'll need to account for in your final architecture.
But this still of working will never get through management because the moment you show them a working product, they'll tell you to ship it and won't give you a chance to rewrite.
I think the best way to solve this is to flatten the hierarchy. Get rid of the notion of managers who rule over engineers and give ownership of the code back to the engineers. Have the engineers and product "owners" make decisions together in a democratic fashion.
I used to share this mindset, and I still agree that individual ownership is possible for engineers. Unfortunately many, many engineers simply do not want it. I would reckon most if not all engineers are comfortable with ownership at the team boundary, but many simply do not care beyond that. It's just a day job.
Individual ownership at the individual engineer boundary can breed distrust within a team or org, but often alienates team members who like their job but aren't trying to lead, at least with respect to what ownership entails. In this blended environment someone almost always ends up without agency. Sometimes no one gets agency. Who wants that?
It's surprisingly simple and effective by comparison to give a team agency and ownership, usually in part because of the dynamic of having a manager or lead to begin with.
Simply put, there are too many modes of failure at the individual level for software ownership to settle there comfortably: staffing changes, job security, career growth are the obvious ones, but the dysfunction (even in otherwise healthy orgs, there's always some amount) will find the shortest path to complete the circuit here.
I like to think of it like a gearbox. If you only have one gear, and you break it, or wear out all the teeth, then you don't get to go. If you have many gears, well, the ride may be uncomfortable at times, but you'll keep moving.
Agreed that you can have real individual ownership. Not only that, I think that is the only way to be really "productive".
But I think that is beside the point.
Individuals are not fungible, but team members are - or at least can be, depending on how you structure your teams.
And as your org grows, you want predictability on a team level. Skipping a bunch of reasoning steps, this means having somewhat fungible team members, to give you redundancy.
The engineering parallel here is the tradeoff between resilience and efficiency. You can make a system more reliable by adding redundancy. You make a system more efficient by removing redundancy.
Ownership has never gotten me anything but more headache. I'm just here to put the things on the pages.
We've got to charge for additional responsibility. Manager/executive pay scales with how many people they're responsible for, no sense in not giving developers that too.
that does work in smaller places, but there are many reasons and many books about exactly why this does not scale or work at most organizations.
> I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.
being vague does not work when talking about organizational design so telling people that they don't need to build teams around systems is a bit irresponsible
It's extremely simple. Stop hiring/promoting into management who don't know the job. This is extremely common in every other industry, and I and legion of people will keep saying this.
It only seems like not a big deal while "good enough" is a really low bar.
I definitely agree that the best teams have cultures that make even normal engineers incredibly effective compared to the status quo. Managers definitely put too much stock in hiring and "engineering quality" compared to culture, trust, systems and processes.
> Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress.
But I have to wonder: if "any asshole" can build orgs like that, why don't they? I know of only a handful of orgs that actually manage to build strong teams of really strong engineers, and they're almost exclusively either trading firms or specialized/research-oriented teams. What's stopping everyone else?
I guess this comes down to the initial point in the article: what do we even mean by "productivity"? (Or, the word I'd prefer: "effectiveness"?) There are lots of orgs where only experienced folks can succeed because they're the best at working around and tolerating disfunction. I've seen performance review processes that—intentionally or unintentionally—selected not for some general technical strength/taste/etc, but for the willingness, ability and stamina to put up with management dysfunction. But, to me, that is very much not what I have in mind when I think "top engineer".
> But I have to wonder: if "any asshole" can build orgs like that, why don't they
Well the supply of extremely talented engineers isn't limitless so you wind up competing for talent with companies much larger than you building much cooler stuff or the same stuff but paying more
> But I have to wonder: if "any asshole" can build orgs like that, why don't they?
Other posters have said money, but it’s also a function of time—how long can a company afford to wait to find the perfect “unicorn” engineer who excels in every aspect of the product but may take a long time to hire, versus hiring someone whose expertise only covers some of the product’s needs but can be found immediately?
Certain companies benefit disproportionately from unicorns, especially those in interdisciplinary fields. For instance, in quantitative finance, a single individual who’s an excellent 1. systems programmer, 2. mathematician, and 3. financial market expert will contribute a lot more than a team of three specialists in each of those domains. But it’s a lot faster to hire that team of three versus finding the rare individual who can supplant a whole team. This is also true in less exotic fields—it’s rare to find someone who’s truly a “full stack” web developer, with a deep understanding of networking protocols and Linux system administration and (cloud based) distributed systems and databases and caching services and frontend development & cetera. But the company that can afford the money and time to find these people will make a much better product than the company that cannot.
(Whether the product actually needs the quality commensurate with all that engineering firepower is an entirely other question.)
because there is, by definition, an extremely limited supply of the "best engineers in the world". if you can afford to pay top-10% salaries, and attract and retain top-10% engineers, more power to you.
maybe not literally "any asshole" can do it -- but it certainly asks more of your leaders to craft sociotechnical systems oriented towards learning and enablement. and i don't think that's a bad thing.
>> I know of only a handful of orgs that actually manage to build strong teams of really strong engineers
The best teams I've been on work like a team in sports.
You have the guys who are really good, really sharp developers. They know all the ins and outs of the framework, but are insanely specialized with one thing, but do the majority of the heavy lifting. Then you have the mid-range guys who are more of the JOT guys. They know UI/UX, accessibility, front-end dev and some back-end stuff. Then you have all the entry level rubes. The guys you can give them something to do and they'll figure it out. They're usually learning as they go, but can handle tasks with some direction and hand holding. As the project runs on, they get more comfortable with the processes and tasks so they need less direction and hand holding.
Building teams is all about finding a good mix of people who compliment each other. Too many of the really sharp devs and they'll be arguing over everything. Get too many mid-range or entry level guys and it will slow down the whole project. You also have to have devs who are comfortable with their skill level and know what they're expected to be doing. Too many times I've been on teams where the mid-range guys start bumping heads with the senior devs. Lunch becomes a rage fest over what we should be doing better. They think they should a lead dev, not the guy they don't like.
The last thing is your senior/lead devs have to have the right attitude too. I've been around some insanely sharp lead devs, but they're complete assholes. They know everything, you know nothing. You use shit frameworks, they're always on the cutting edge and your an idiot because you like Angular not something bougie like Svelt.
The key in all of this is finding the chemistry that works. When you get that chemistry, you can capture lightening in a bottle and really build some amazing stuff. When it works, its the coolest thing. People are dialed in, they're enthusiastic about what they're doing. They're willing to work longer hours to make sure the product we're building is incredible. The team is happy, delivering and working on faster sprints and things just feel effortless.
There are large parts of this I really like, but it's hard to overstate just how much I disagree with the idea that "The only meaningful measure of productivity is impact to the business". The natural result of this view is a focus on quantifiable changes and short term thinking. The greatest value of experienced engineers is in avoiding landmines that will destroy a project or even a company. It's difficult to quantify things that never happen, or communicate the value in avoiding them in terms that don't sound wildly hyperbolic.
100%. I've taken to using intentionally fuzzy phrases to describe productivity/impact/effectiveness/whatever. Like, "in a holistic accounting, person X did a great job". It's not necessarily—in fact, necessarily not—easily quantifiable or legible, it requires some human insight and judgement, but so does any complex, creative endeavor. Trying to reduce management to metrics is inherently short-sighted.
I'm not sure I totally agree with measuring value by avoiding landmines or anything at all related to project management, but it definitely bugs me to see everything reduced to business impact. There are plenty of things in life that matter to individuals, to humanity, to the entire world at large, that have nothing to do with selling products for money. When I think of the engineers I revere the most, I don't think of titans of post-2001 Silicon Valley so much as John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo DaVinci, whoever the hell built the Roman aqueducts and Egyptian pyramids, Babylonians and Mesoamericans who figured out how to predict eclipses.
Did these people have a business impact? I guess Tesla made Westinghouse a lot of money at one point, but that seems far from the most distinguishing thing that made him great at what he did. If anything, he was mediocre at business.
Even if we want to look at current titans of the computing industry, I admire the work done by orgs like Nvidia or humans like Geoff Hinton, but they also just got lucky that what they were doing for completely different reasons ended up benefiting so tremendously from the galaxy-scale data harvesting that has been going on due to the Internet becoming primarily ad-monetized, which they didn't know was going to happen. How many equally great engineers toiled in obscurity on dead ends but did equally great work? Doug Lenat was just as great an AI engineer, if not better, than Geoff Hinton. History just went one way and not the other, due to factors completely outside of the control of either of them.
You can build systems for efficiency, or build them to minimize disaster. It's really hard to see the negative impact on the business that was prevented.
I’ve been lucky enough to work on a number of teams in my career that are full of brilliant high performing people who are also kind, empathetic, and focused working together to deliver something to customers. These days I’m lucky enough to lead a team like that.
Counter to the article, in my experience these are the hardest teams to manage well because organizations typically aren’t set up to deal with them. Larger companies tend to lean into standardization and making things accessible to average engineers in ways that make high performing teams less effective and often demotivated.
I think this is an overly cynical approach that assumes that you can’t invest and grow people into exceptional engineers. In my experience you can if you are willing to invest in it, and the long term benefit of having more high performing engineers who aren’t being restricted from doing good work outweighs the cost of training and growing people.
Some good points, bad logic. The fact that you can't effectively measure something doesn't mean that something doesn't exist.
Individual productivity exists.
Maybe it's easier to measure groups' productivity? Probably.
"Business impact"? I don't think so, that later concept seems much more arbitrary. But feel free to look for the keys under the lamplight. If you choose that metrics, you're not going to retain many extra productive people anyway.
The old problem: judging the work of an expert is very difficult if you lack comparable expertise. I can give you advice, but I can't make you smart to accept it. How could you tell if I'm a genius or an overconfident asshole?
> The best engineering orgs are the ones where normal engineers can do great work
I quite like this. It is absolutely true as well, not all teams can be 100% rockstars. How well do you enable the average dev to be good, maybe not GREAT but good and reliable.
> Make it easy to do the right thing and hard to do the wrong thing.
This is basically the mantra of every platform team I've worked on. Your goal is to make the easy and obvious solution to engineers' problems the "right" one for the sustainability of software and reliability of services.
Make it easy to ship things that are reliable and manage distributed state well and can scale well and engineers will build better muscle memory for building software in that shape and your whole org will benefit.
> Assemble a small council of trusted senior engineers.
> Task them with creating a recommended list of default components for developers to use when building out new services. This will be your Golden Path, the path of convergence (and the path of least resistance).
> Tell all your engineers that going forward, the Golden Path will be fully supported by the org. Upgrades, patches, security fixes; backups, monitoring, build pipeline; deploy tooling, artifact versioning, development environment, even tier 1 on call support. Pave the path with gold. Nobody HAS to use these components … but if they don’t, they’re on their own. They will have to support it themselves.
> Are you using golang, python, COBOL, lisp, perl, React, or brainfuck?
For years now I had this feeling that people confuse React with the entire frontend ecosystem, but dismissed it thinking that surely they're aware that there's a whole world of non-React frontend out there?
At my company, I always prefer hiring average engineers with great attitude. Too many high-credential people with bad attitude were placed on high pedestals due to their perception-creating skills, and became immune to questioning. Once they bag that sweet perception from the boss, they also start bully around. Bosses would usually dismiss any data that goes against their perceptions. Mostly because going by perception is lot easier than looking into the data.
> 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.
This hits close to home for me recently. I don't profess to be a 10x engineer, but I found myself on a team with a few people with much less experience and competence than I am normally accustomed to. I started getting every single ticket with any kind of complexity, because I could get it done, and some people on my team couldn't. I could have continued this way, contributing a massive percentage of the output and claimed to be superior to everyone - but the reality is, for me anyway, this is exhausting (and feels really unfair). Plus I am a little lazy (as I believe all good sysadmins/sre's/ops guys are). I want my team to help me. So what I did was work extra for a few weeks and wrote a ton of abstractions over the most complex stuff we do (I dont write software, I write IAC, I'm aware this is a common pattern in software engineering) so that the less knowledgeable engineers could do the work I'd been doing much of. It freed my time up to work on more interesting problems. This was the first time in my career I had to do this without anyone already ordering me to.
I've been on teams where there was someone like me and everyone else was running around behind them frantically trying to keep up or cleaning up the inevitable tech debt that accumulates. It's miserable and really inefficient.
This is all well and good, but it all hinges on your manager not being an insane maniac. All of those systems are great with the right manager, but if your manager is a KPI chaser / VP position seeker you are cooked.
I have had managers that were essentially like a sergeant, serving engineers as a phalanx against the business so we can go fast.
I have also had a manager who was so obsessed on showing off how much better of a dev he was than everyone else on the team, that he was largely hated and all talent on that team moved away if they could. I moved, and had a much better time in data science.
I largely agree that killer onboarding, and a clear path to deploy are big wins for normalizing your dev culture to new hires. The measurement tech is always a double edged sword.
There are plenty of good "normal" engineers whose abilities top out at following direction from management, implementing a spec (albeit really well), adding to an existing architecture etc. I'd wager the vast majority of the industry falls into this category. Yes, it's very important for an org to ensure that these kinds of engineers are successful, because they are the workhorses of your company and without them nothing will get done.
Ultimately though you can't have a workforce just of these engineers. Someone has to lead. Someone has to tell management what to build. Someone has to invent new tech from scratch.
"10x engineer" is a bullshit LinkedIn thoughtfluencer term that has unfortunately caught on, but everyone who has worked in the industry for more than a day knows that there is a hierarchy in the tech org, and the ones on top are more valuable than the rest.
10x engineer in the original sense to me is simply someone that 10x-es your company in some way. Maybe Avie Tevanian who brought Apple OSX/etc. or Andy Rubin who brought Google Android.
I’ve thought a lot about this my whole life. How do you build a good team? People simply don’t like each other so the natural sorting that happens is that teams hire for who they like and likes them in return (or at least in mating terms, will certainly appear as likable as can be). By definition, this can never be the most optimal team.
There may have to be a different way to think about this. How can you have things that hate each other but still run an amazing operation? The best operation I can think of is a zoo. You have your tigers over here, and your penguins over there. The operation as a whole is amazing.
A company of just tigers will destroy everything and a company of just penguins need too much caretaking.
Most armed forces are not a “team”, they are an operation. If you constantly try to fit an operation into a team framework, that’s when you’ll try to turn penguins into tigers (how do you turn someone into a 100x engineer?). Or worse, you tell a tiger to chill out and relax with the penguins (you’re asking for trouble). If you need a 100x engineer, make sure the engineer is a thousand miles away and gets paid like it and far away from the normal engineers lest they start believing the tiger cage is suitable for penguins or vice versa. It’s a big operation, no teams.
If you MUST build a team, then just be yourself. You probably are building something small dogs like, so hire a few street dogs and you won’t even need to worry about zoo-scale decisions and operations. You won’t need to go through the mistake of jamming 4 different species into the same enclosure to finally learn how things live separately but together.
> Build sociotechnical systems with “normal people” in mind
From the perspective of the composition of software engineering teams: Most of us have to make due with the average, we strive to find the above average and avoid the mediocre, but mostly we are teams composed of "normal" people. The article has some good advice for making the best out of a group of normal people. It particularly relevant because it's unlikely that you'll see anything else.
> 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.
Yes, and there are often teams of one. I am currently in such a team. Even though I work on a different problem than other "teams", I think it's reasonably easy to eyeball the relative productivity (not in my favour, in my current circumstances; though, to the credit of my superiors, they're being very patient with me).
[+] [-] tikhonj|8 months ago|reply
I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in days or weeks, while, on the best teams I've seen, it's measured in months, quarters or years.
It's counterintuitive, but you absolutely can have real individual owernship for engineers without creating single points of failure or brittle systems. It's a matter of having other sources of slack, encouraging quality work, and giving people a lot of room to fluidly adjust what they're working on when. Folks still have real ownership and can make longer-term decisions on their own, but they also collaborate in ad hoc ways and share tacit knowledge, so that somebody else can jump in, help out or even take over in a pinch. I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.
In practice, the model I saw did end up with more rewriting than a normal team—but we were still way more productive overall, even accounting for the rewrites! Turns out that rewriting systems incrementally, in self-contained chunks, is an amazing way to both evolve the design and to build up instutitional knowledge and capacity. It looks like waste, but it's actually slack that is crucial to making your system as a whole more flexible, adaptable and resilient. (In fact, that's true of a lot of the "waste" top-down management systems try to reduce—I'm incresingly convinced that anybody trying to optimize software team "utilization" is actively sabotaging the work!)
[+] [-] dkarl|8 months ago|reply
I'd go further and say that even within engineering, people outside of a team can't give immediate rewards for work whose long-term value is internal to the team, for the same reason: they don't know if the work you're doing is actually valuable or is just superficially similar to the kind of work that often does have long-term value.
If you're confident enough in your long-term decisions, and how you spend slack time, then you should be fine with being rewarded for delivery, since you expect your long-term work to pay off in future delivery and future rewards.
[+] [-] matthewkayin|8 months ago|reply
Coding is like writing, in the sense that it's often faster to write a sloppy first draft followed by a better second draft than it is to agonize over getting the first draft right on the first go. The first draft is generative. Its purpose is not to be good but instead to let you get something built quickly and to let you explore the problem, so that you know what edge cases you'll need to account for in your final architecture.
But this still of working will never get through management because the moment you show them a working product, they'll tell you to ship it and won't give you a chance to rewrite.
I think the best way to solve this is to flatten the hierarchy. Get rid of the notion of managers who rule over engineers and give ownership of the code back to the engineers. Have the engineers and product "owners" make decisions together in a democratic fashion.
[+] [-] xyzzy_plugh|8 months ago|reply
Individual ownership at the individual engineer boundary can breed distrust within a team or org, but often alienates team members who like their job but aren't trying to lead, at least with respect to what ownership entails. In this blended environment someone almost always ends up without agency. Sometimes no one gets agency. Who wants that?
It's surprisingly simple and effective by comparison to give a team agency and ownership, usually in part because of the dynamic of having a manager or lead to begin with.
Simply put, there are too many modes of failure at the individual level for software ownership to settle there comfortably: staffing changes, job security, career growth are the obvious ones, but the dysfunction (even in otherwise healthy orgs, there's always some amount) will find the shortest path to complete the circuit here.
I like to think of it like a gearbox. If you only have one gear, and you break it, or wear out all the teeth, then you don't get to go. If you have many gears, well, the ride may be uncomfortable at times, but you'll keep moving.
[+] [-] athoscouto|8 months ago|reply
But I think that is beside the point.
Individuals are not fungible, but team members are - or at least can be, depending on how you structure your teams.
And as your org grows, you want predictability on a team level. Skipping a bunch of reasoning steps, this means having somewhat fungible team members, to give you redundancy.
The engineering parallel here is the tradeoff between resilience and efficiency. You can make a system more reliable by adding redundancy. You make a system more efficient by removing redundancy.
[+] [-] hnthrow90348765|8 months ago|reply
Ownership has never gotten me anything but more headache. I'm just here to put the things on the pages.
We've got to charge for additional responsibility. Manager/executive pay scales with how many people they're responsible for, no sense in not giving developers that too.
[+] [-] inky-solver|8 months ago|reply
> I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.
being vague does not work when talking about organizational design so telling people that they don't need to build teams around systems is a bit irresponsible
[+] [-] spimmy|8 months ago|reply
[+] [-] sublinear|8 months ago|reply
It only seems like not a big deal while "good enough" is a really low bar.
[+] [-] dkkergoog|8 months ago|reply
[deleted]
[+] [-] tikhonj|8 months ago|reply
> Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress.
But I have to wonder: if "any asshole" can build orgs like that, why don't they? I know of only a handful of orgs that actually manage to build strong teams of really strong engineers, and they're almost exclusively either trading firms or specialized/research-oriented teams. What's stopping everyone else?
I guess this comes down to the initial point in the article: what do we even mean by "productivity"? (Or, the word I'd prefer: "effectiveness"?) There are lots of orgs where only experienced folks can succeed because they're the best at working around and tolerating disfunction. I've seen performance review processes that—intentionally or unintentionally—selected not for some general technical strength/taste/etc, but for the willingness, ability and stamina to put up with management dysfunction. But, to me, that is very much not what I have in mind when I think "top engineer".
[+] [-] bluefirebrand|8 months ago|reply
Well the supply of extremely talented engineers isn't limitless so you wind up competing for talent with companies much larger than you building much cooler stuff or the same stuff but paying more
[+] [-] MontyCarloHall|8 months ago|reply
Other posters have said money, but it’s also a function of time—how long can a company afford to wait to find the perfect “unicorn” engineer who excels in every aspect of the product but may take a long time to hire, versus hiring someone whose expertise only covers some of the product’s needs but can be found immediately?
Certain companies benefit disproportionately from unicorns, especially those in interdisciplinary fields. For instance, in quantitative finance, a single individual who’s an excellent 1. systems programmer, 2. mathematician, and 3. financial market expert will contribute a lot more than a team of three specialists in each of those domains. But it’s a lot faster to hire that team of three versus finding the rare individual who can supplant a whole team. This is also true in less exotic fields—it’s rare to find someone who’s truly a “full stack” web developer, with a deep understanding of networking protocols and Linux system administration and (cloud based) distributed systems and databases and caching services and frontend development & cetera. But the company that can afford the money and time to find these people will make a much better product than the company that cannot.
(Whether the product actually needs the quality commensurate with all that engineering firepower is an entirely other question.)
[+] [-] spimmy|8 months ago|reply
maybe not literally "any asshole" can do it -- but it certainly asks more of your leaders to craft sociotechnical systems oriented towards learning and enablement. and i don't think that's a bad thing.
[+] [-] ChrisMarshallNY|8 months ago|reply
The biggest reason, is that most first-line and middle managers suck. They can't create and maintain a productive environment.
The cure is/was to pay heaps of money. People will put up with almost any kind of hell, for good pay.
[+] [-] sorokod|8 months ago|reply
Their brilliance may be in the way of finding the necessary compromises and doing the required but not intellectually challenging work.
[+] [-] burningChrome|8 months ago|reply
The best teams I've been on work like a team in sports.
You have the guys who are really good, really sharp developers. They know all the ins and outs of the framework, but are insanely specialized with one thing, but do the majority of the heavy lifting. Then you have the mid-range guys who are more of the JOT guys. They know UI/UX, accessibility, front-end dev and some back-end stuff. Then you have all the entry level rubes. The guys you can give them something to do and they'll figure it out. They're usually learning as they go, but can handle tasks with some direction and hand holding. As the project runs on, they get more comfortable with the processes and tasks so they need less direction and hand holding.
Building teams is all about finding a good mix of people who compliment each other. Too many of the really sharp devs and they'll be arguing over everything. Get too many mid-range or entry level guys and it will slow down the whole project. You also have to have devs who are comfortable with their skill level and know what they're expected to be doing. Too many times I've been on teams where the mid-range guys start bumping heads with the senior devs. Lunch becomes a rage fest over what we should be doing better. They think they should a lead dev, not the guy they don't like.
The last thing is your senior/lead devs have to have the right attitude too. I've been around some insanely sharp lead devs, but they're complete assholes. They know everything, you know nothing. You use shit frameworks, they're always on the cutting edge and your an idiot because you like Angular not something bougie like Svelt.
The key in all of this is finding the chemistry that works. When you get that chemistry, you can capture lightening in a bottle and really build some amazing stuff. When it works, its the coolest thing. People are dialed in, they're enthusiastic about what they're doing. They're willing to work longer hours to make sure the product we're building is incredible. The team is happy, delivering and working on faster sprints and things just feel effortless.
[+] [-] AlotOfReading|8 months ago|reply
[+] [-] Retric|8 months ago|reply
Maximum impact is a long term proposition.
[+] [-] tikhonj|8 months ago|reply
[+] [-] nonameiguess|8 months ago|reply
Did these people have a business impact? I guess Tesla made Westinghouse a lot of money at one point, but that seems far from the most distinguishing thing that made him great at what he did. If anything, he was mediocre at business.
Even if we want to look at current titans of the computing industry, I admire the work done by orgs like Nvidia or humans like Geoff Hinton, but they also just got lucky that what they were doing for completely different reasons ended up benefiting so tremendously from the galaxy-scale data harvesting that has been going on due to the Internet becoming primarily ad-monetized, which they didn't know was going to happen. How many equally great engineers toiled in obscurity on dead ends but did equally great work? Doug Lenat was just as great an AI engineer, if not better, than Geoff Hinton. History just went one way and not the other, due to factors completely outside of the control of either of them.
[+] [-] jessitron|8 months ago|reply
You can build systems for efficiency, or build them to minimize disaster. It's really hard to see the negative impact on the business that was prevented.
[+] [-] esafak|8 months ago|reply
[+] [-] spimmy|8 months ago|reply
[+] [-] rebeccaskinner|8 months ago|reply
Counter to the article, in my experience these are the hardest teams to manage well because organizations typically aren’t set up to deal with them. Larger companies tend to lean into standardization and making things accessible to average engineers in ways that make high performing teams less effective and often demotivated.
I think this is an overly cynical approach that assumes that you can’t invest and grow people into exceptional engineers. In my experience you can if you are willing to invest in it, and the long term benefit of having more high performing engineers who aren’t being restricted from doing good work outweighs the cost of training and growing people.
[+] [-] narag|8 months ago|reply
Individual productivity exists.
Maybe it's easier to measure groups' productivity? Probably.
"Business impact"? I don't think so, that later concept seems much more arbitrary. But feel free to look for the keys under the lamplight. If you choose that metrics, you're not going to retain many extra productive people anyway.
The old problem: judging the work of an expert is very difficult if you lack comparable expertise. I can give you advice, but I can't make you smart to accept it. How could you tell if I'm a genius or an overconfident asshole?
[+] [-] acedTrex|8 months ago|reply
I quite like this. It is absolutely true as well, not all teams can be 100% rockstars. How well do you enable the average dev to be good, maybe not GREAT but good and reliable.
[+] [-] lizardking|8 months ago|reply
[+] [-] ericvolp12|8 months ago|reply
This is basically the mantra of every platform team I've worked on. Your goal is to make the easy and obvious solution to engineers' problems the "right" one for the sustainability of software and reliability of services.
Make it easy to ship things that are reliable and manage distributed state well and can scale well and engineers will build better muscle memory for building software in that shape and your whole org will benefit.
This will never stop being true.
[+] [-] simonw|8 months ago|reply
> Assemble a small council of trusted senior engineers.
> Task them with creating a recommended list of default components for developers to use when building out new services. This will be your Golden Path, the path of convergence (and the path of least resistance).
> Tell all your engineers that going forward, the Golden Path will be fully supported by the org. Upgrades, patches, security fixes; backups, monitoring, build pipeline; deploy tooling, artifact versioning, development environment, even tier 1 on call support. Pave the path with gold. Nobody HAS to use these components … but if they don’t, they’re on their own. They will have to support it themselves.
[+] [-] Tade0|8 months ago|reply
For years now I had this feeling that people confuse React with the entire frontend ecosystem, but dismissed it thinking that surely they're aware that there's a whole world of non-React frontend out there?
[+] [-] zkmon|8 months ago|reply
[+] [-] JohnMakin|8 months ago|reply
This hits close to home for me recently. I don't profess to be a 10x engineer, but I found myself on a team with a few people with much less experience and competence than I am normally accustomed to. I started getting every single ticket with any kind of complexity, because I could get it done, and some people on my team couldn't. I could have continued this way, contributing a massive percentage of the output and claimed to be superior to everyone - but the reality is, for me anyway, this is exhausting (and feels really unfair). Plus I am a little lazy (as I believe all good sysadmins/sre's/ops guys are). I want my team to help me. So what I did was work extra for a few weeks and wrote a ton of abstractions over the most complex stuff we do (I dont write software, I write IAC, I'm aware this is a common pattern in software engineering) so that the less knowledgeable engineers could do the work I'd been doing much of. It freed my time up to work on more interesting problems. This was the first time in my career I had to do this without anyone already ordering me to.
I've been on teams where there was someone like me and everyone else was running around behind them frantically trying to keep up or cleaning up the inevitable tech debt that accumulates. It's miserable and really inefficient.
[+] [-] anarticle|8 months ago|reply
I have had managers that were essentially like a sergeant, serving engineers as a phalanx against the business so we can go fast.
I have also had a manager who was so obsessed on showing off how much better of a dev he was than everyone else on the team, that he was largely hated and all talent on that team moved away if they could. I moved, and had a much better time in data science.
I largely agree that killer onboarding, and a clear path to deploy are big wins for normalizing your dev culture to new hires. The measurement tech is always a double edged sword.
[+] [-] paxys|8 months ago|reply
Ultimately though you can't have a workforce just of these engineers. Someone has to lead. Someone has to tell management what to build. Someone has to invent new tech from scratch.
"10x engineer" is a bullshit LinkedIn thoughtfluencer term that has unfortunately caught on, but everyone who has worked in the industry for more than a day knows that there is a hierarchy in the tech org, and the ones on top are more valuable than the rest.
[+] [-] commandersaki|8 months ago|reply
[+] [-] ysofunny|8 months ago|reply
uhm, as a research university or private company like a startup??
[+] [-] ivape|8 months ago|reply
There may have to be a different way to think about this. How can you have things that hate each other but still run an amazing operation? The best operation I can think of is a zoo. You have your tigers over here, and your penguins over there. The operation as a whole is amazing.
A company of just tigers will destroy everything and a company of just penguins need too much caretaking.
Most armed forces are not a “team”, they are an operation. If you constantly try to fit an operation into a team framework, that’s when you’ll try to turn penguins into tigers (how do you turn someone into a 100x engineer?). Or worse, you tell a tiger to chill out and relax with the penguins (you’re asking for trouble). If you need a 100x engineer, make sure the engineer is a thousand miles away and gets paid like it and far away from the normal engineers lest they start believing the tiger cage is suitable for penguins or vice versa. It’s a big operation, no teams.
If you MUST build a team, then just be yourself. You probably are building something small dogs like, so hire a few street dogs and you won’t even need to worry about zoo-scale decisions and operations. You won’t need to go through the mistake of jamming 4 different species into the same enclosure to finally learn how things live separately but together.
[+] [-] polytely|8 months ago|reply
this seems like an insane statement to me, you can just hire for ability to function in a team?
[+] [-] physix|8 months ago|reply
From the perspective of the composition of software engineering teams: Most of us have to make due with the average, we strive to find the above average and avoid the mediocre, but mostly we are teams composed of "normal" people. The article has some good advice for making the best out of a group of normal people. It particularly relevant because it's unlikely that you'll see anything else.
[+] [-] physix|8 months ago|reply
One reason I clicked on this one is that I was hoping to learn stuff about engineers beyond just software.
But it's a good read nevertheless. Thanks for that!
[+] [-] raincole|8 months ago|reply
Yeah, it's obviously not true.
If it were true then the market salaries of coaches and trainers in professional sports would be really low. And they aren't.
[+] [-] lysace|8 months ago|reply
It also works when building something new with a captive audience (banking, insurance, etc.)
Everything doesn’t need to be world-class. Sometimes long term development stability/resiliency is what matters.
[+] [-] mlhpdx|8 months ago|reply
Yep. I’ve been here for a career or so with moments of brilliance and marathons of mediocrity, but consistent kindness (I hope).
[+] [-] tasuki|8 months ago|reply
Yes, and there are often teams of one. I am currently in such a team. Even though I work on a different problem than other "teams", I think it's reasonably easy to eyeball the relative productivity (not in my favour, in my current circumstances; though, to the credit of my superiors, they're being very patient with me).
[+] [-] ChrisArchitect|8 months ago|reply
https://news.ycombinator.com/item?id=43356995