Foreword

This post will be mostly about software engineering, but the overall ideas should apply to other engineering domains. There is an idea of a “x10 programmer”/”x10 engineer” — someone, who is ten times more productive than average.

Every result-oriented leader would want to have people like that in their team. After all, the productivity would be higher, while the required expense would likely go nowhere near x10 of the average. Sounds like a win. In fact, having a x2 engineer would still be an epic win. Unfortunately, it is hard to find such productive individuals. While the legends persist, most people see them exactly as legends or even myths.

So do x10 engineers exist or not? I would argue they do. However, a “x10 engineer” is not a person, it is a state in which a person is. Furthermore, due to the nature of engineering, it is hard to quantify it, so “x10” should not be seen as literally x10 more productive, as there is no way to measure productivity precisely — and if someone tells you there is one, you should be very sceptical.

Defining “Productivity”

To even begin to consider a x10 improvement in productivity we ought to decide on the method of measuring it.

Let’s consider software engineering for a start. Historically, the following methods were used:

Lines of code - this is perhaps the oldest. The idea is that the more lines of code are written by a person, the better. The good thing here is that the metric is easily obtainable and objective. The bad thing is that it is utterly meaningless, easy to manipulate, and harmful. It is meaningless because writing a hundred lines instead of a three-line loop does not change the functionality but does boost the metric dramatically. It is easy to manipulate because adding a few blank lines or an autogenerated pointless comment creates an imaginary value. It is harmful because it leads to long, incomprehensible, and hard-to-maintain code. And what about the situation where the code — which may already be worthless by then — is being deleted? Is it a destruction of “value”?

Implemented units of work - here, all changes to the codebase are driven off a backlog of changes (“stories” in the parlance of “Agile Software Development“), and each change has an estimate of some sort (in hours, points, whatnot). The measure of productivity here is the sum of all change estimates for all changes implemented by an individual. This is a much saner metric than lines of code, but it is not without its faults: it can still be manipulated (by creatively estimating the changes/stories), but it starts to break down when a seemingly implemented change fails QA or damages the codebase as a whole, it is a difficult one when considering refactorings, and it does not take into attention the actual value of the change.

Oh… And this is it, as far as metrics grounded in the actual codebase are concerned. Sure enough, the world is a huge place, and there may be a team which is using an exotic metric to measure productivity based on the code alone, but that would be an exception to the rule.

Both metrics above are mostly unsatisfactory and that is for a reason. Just like a painter is normally judged by the quality of a picture rather than the amount of paint spent (Modern art, begone!), the productivity of engineering should be measured in a way related to the practical outcomes: the number of clients serviced, the number of bugs reported, the percentage of negative feedback from customers, the reaction time of a system, the weight that can be supported by a bridge, the distance a car can travel on a single charge, etc. You can argue about specific ways of measuring the outcomes numerically, but ultimately that does not matter that much. As it often happens, it is more important to move in the correct direction than to do it fast.

Does Productivity Vary Between Individuals?

This matter is trivial, but let’s cover it anyway.

It may be argued whether a person can be x10 more productive than his/her peers, but it is obvious that productivity varies from a person to a person.

If a professional carpenter and I are given all the tools and materials that may be needed, and we both are asked to make a chair, I am fairly sure both of us will end up making one. However, I would be so slow and my chair would be so awful (and likely dangerous) that it would be fine to call me a x0 carpenter.

Similarly, some people are just better than average at doing their work. I once worked with a peculiar man. Compared to everyone else in the team he seemed slow: soft, slow movements, a slow manner of speech, a generally relaxed posture. When he was given a task to take care of, he took it slowly. Had a long look at it, contemplated it for a while, and then gently touched his keyboard. A short while later, the task was done. It was hard to measure his productivity, to be honest, but the gut feeling was that he was way more productive than others.

So yes, productivity does vary from person to person. People are not uniform cogs, despite what may be believed in within corporate environments. A shocker, I know. You may ask about the causes which make people more efficient, and you may debate the roles of education and personality, but the fact that there is a bit of variation between people is hardly a matter of debate.

Is it Possible to Improve Productivity?

Yes, in most cases productivity can be improved.

The first thought is “upskilling”. I may help, although only in the case where people lack skill. When people are hired or chosen, they are pre-selected to already have the required skills. This means upskilling may not be a viable option because there is no lack of skills.

However, it is also possible to be more productive by being more selective. Yossi Kreinin has written an excellent post on this matter, and I recommend getting oneself familiar with it. Being selective means focusing on the kind of work which brings the most value, is most appreciated, and — hopefully — happens to feel like the lowest-hanging fruit.

The approach can be implemented on all levels of an organisation: individual contributors select the things that they do, top management selects the overall direction of the firm, and middle management decides which way to steer their teams. Yes, it goes against the grain of how things are done in so many places, but the approach has been known for almost a century, and it is popular amongst military organisations (likely because for them failure means death, and they cannot indulge in doing things which do not work). They call it “mission-type tactics“.

Is it Possible to Destroy Productivity?

Oh yes, easily.

Just like before, I am going to save myself some trouble and just put a link here to a lovely post called “(How to be a -x10 Engineer)[https://taylor.town/-10x]”. It provides many hands-on instructions on how to drive your productivity down to zero, and then even lower, by causing serious, long-lasting damage. While the post focuses on software engineering, many suggestions are applicable in other fields too.

Here are a few quotes with my comments:

“Change requirements as far into development as possible. To avoid blame, obfuscate requirements from the start.” When the team complains, confidently tell them that collecting requirements and planning work before doing the work is a feature of a beastly Waterfall, while in the blessed Agile Software Development sudden changes to requirements must be embraced and valued as an opportunity to ensure customer satisfaction. He-he.

“Let engineers discuss ideas. Encourage them to pursue elegance over pragmatism. Ensure nobody has the authority to make any decisions.” Alternatively, force engineers to do things in the only way the Party has approved, no matter the cost. Encourage them to take shortcuts whenever they can: a minute saved now is months of pain later (by which point you will work for another organisation anyway).

“Decide that existing solutions aren’t quite what you need. Write scripts that only one person understands. If the script does something important, avoid documentation.” Alternatively, be fanatical about never using in-house tools. Adopt “industry standard solutions” which do not take into account the specifics of your business, and cannot be adapted accordingly. Enjoy low levels of automation, poor reliability, and the need to spend hours if not days to explain to each individual how to use these tools. Accept that when things go wrong, it will take days and weeks for the SMEs of your vendor to mend the problem, as you will have no clue how to mend it on your own.

Does Productivity Depend on the Environment?

I would say, the role of the environment is the overarching theme if you seriously consider the productivity of people. Let’s go through the discussed points and contemplate them.

Upskilling

Is an opportunity for upskilling good for productivity? Yes.

People can upskill themselves, and most of them do. But it is also clear that it does not harm when a firm provides these opportunities to its employees.

Being Selective

Being selective is great. However, being selective is not always possible and the process of selection has several aspects, so let’s have a look.

Useful Work vs Much Hard Work

It is better to select one-tenth of the work that matters and do it, rather than trying to do all of it and then a bit more. Also, it is better to select one-tenth of the most critical work among the work that matters and do it first.

At the beginning of the existence of the Soviet Union, it was in vogue there to be an udarnik, a highly productive worker. Imagine a sweaty chap in a coal mine, who is swinging a hammer for half a day and delivers more coal than his somewhat feeble and less enthusiastic comrades. That’s an udarnik. I am sure the image feels warm and fuzzy to some.

I, however, cannot get rid of the thought that instead of having thousands of people work pretty much as slaves in those horrid conditions (this book gives a great description) it would be far better had some effort been invested in automation first.

It is true, that swinging a hammer non-stop may look powerful, but why not look around and select a different task — procure a jackhammer? Or better still, grab some sort of specialised machine and drill the living light out of that rock?

That is all great, but can a person select?

In most environments, people are told what to do, and they are expected to do exactly what they are told. Selecting what to do and when to do it is simply not an option. Is your organisation flexible enough to let people focus on what’s important?

Freedom to Choose

Apart from the freedom to choose what to work on, there is also the freedom of choosing how to get the job done and which resources to employ for that.

Suppose your team is working on a high-rise building. Would you expect a stellar result if they are required to build it out of mud and sticks, and document everything in the project in Sumerian language? I doubt it.

Why is it then, that software engineers are often required to use a specific framework or a tool? Some may say “But there is a value in standardization!”, and I agree with that. However, there is also value in picking the right tool for the job. Nobody is using scissors to drive nails into a wood, even though scissors are a fantastic tool for cutting nails.

In order words, if you want efficiency — let your engineers decide what is right. If the environment does not allow professionals to exercise their judgment and make the right call — that is a fault with the environment.

People are Different

People are different, so the same task can be easy for one person and hard for another. The reasons for this are many, and we do not want to drown in nature vs nurture debates and other things.

The important thing here is that if you have a team of actually different individuals, then pretty much for any task there will be someone for whom that task is much easier than for others. So if you want to improve the productivity of your team, you need to create an environment where people have the freedom to pick whatever they see as the lowest-hanging fruit, while also rewarding those who solve the problems which others find difficult. With this arrangement, you can benefit from diversity for real.

Stability of the Environment

The stability and predictability of the working environment matter. People should be able to do their jobs rather than struggling with half-broken infrastructure or wasting their time on yet another migration to the “best ticket system ever” (the third one in a single year).

A great environment is where this matter is appreciated: a few solid tools are better than an ever-changing zoo of whatever is riding the hype these days. People will learn the nooks and crannies of the ecosystem and will then focus on productive work. That’s how it should be. Is it like that for you?

Great Leadership

There are different definitions of what could be called “great leadership”.

For example, a definition I heard once is that a great leader is someone who boldly makes the first step. I guess the other way of saying the same is that a great leader is good at making a decision fairly quickly and confidently.

Naturally, there is value in that, and I am not going to dispute that. However, not every bold decision is a jolly good idea, and I believe the fourth block of the Chornobyl power plant would agree.

So how about an alternative definition? “A great leader is someone who helps his/her team to get the job done via appropriate means.” The leader can and should make decisions, of course. But a great leader would do whatever is necessary to help the team members to do their best.

The latter type of leadership is particularly good when you seek to increase the efficiency of the team of professionals, while the former is perhaps better when you seek to get at least something from a team of unmotivated and confused sloths.

Hiring Practices

As mentioned previously, people differ in their ability to get things done. Hiring decisions can be made in various ways, of course. They can be based on the ability of candidates to get the specific type of work done effectively. But similarly, they can be based on other metrics, such as sports achievements or the favourite music band. The hiring policies determine who gets employed by the firm, so the approach matters.

Look, I know it sounds silly. But can you honestly say that the hiring policies in your organisation are designed to boost the firm’s ability to find and retain top talent?

Here is an enlightening article I found about hiring where it is claimed that at least in some countries people are, in essence, hired for being taller and being able to say things confidently (even though those things may be utter rubbish).

Theatre of Work

Do you know the real reason for having many conference calls, often the ones without any agenda whatsoever? It is a status show: “Look how important I am! There are so many people under my command. I preside over them.” Meanwhile, people’s time is wasted. Twenty people in a half an hour call means that time equivalent to around a working day of a single person is spent, often for nothing.

Tickets… They are a way to track work and reduce chaos, but often they end up being a tool for creating more worthless bureaucracy. Once a system is in, there is a tendency to introduce metrics based on it, so that the “efficiency” of people is determined by how many tickets are created/serviced (which leads to a push for more fine-grained bureaucracy) or how quickly these tickets are closed (which leads to tickets being closed too aggressively, without addressing the actual problem).

The worst case that I have seen so far was where there was an overcomplicated ticketing system where you need to fill out tens of poorly understood interconnected fields, some of which are mandatory and some not (and it is never clear which is which). To get some triviality done — which I could have done myself in five minutes or so had I been allowed to do it myself — I had to spend hours figuring out the correct way of creating a ticket specifically for this case. Then, after getting approved by ten or so people, that ticket resulted in yet another ticket created by specially trained people, and the process was repeated. After a week or two the job was done… after two failed attempts as people were utterly confused by all this.

If you care about efficiency, you should stop distracting people who are doing their job: understand which work is real and which one is merely a theatre, and then get rid of the latter.

The Flow

The state of flow is the state of mind where a person is truly focused on the task at hand, and so it is extremely valuable. Where engineers spend much of their time in the state of flow, not only they are more efficient, but they are also happier.

However, the state of flow is easily disrupted. Instant messages, random chatter, slow or broken tools — all of these things and many more can easily pull a person out of this valuable state.

In a good environment, people can achieve the state of flow and stay in it for as long as necessary. In an awful environment, the state of flow is not possible at all.

Nodes and Flows of Information

The efficiency of storing/retrieving/sharing information amongst team members impacts the efficiency of their work. That is obvious and true, I think.

There are many ways to get this done: WIKIs, emails, instant messages, meetings, chatter in a kitchen, etc. So let’s have a closer look at them.

Meetings

Many would disagree, but I do believe that meetings are generally a bad idea. They waste time, they are often done without due preparation, and little good comes out of them. I know that’s not how it should be, but that’s how it often is.

There are few exceptions, however.

Intensive one-on-one meetings can be good. Both participants would be completely involved in the communication and meaningful interaction can take place.

Group meetings with not more than ten people, a well-defined agenda prepared and distributed before the meeting, and a follow-up email or WIKI update can be good too in some situations, especially when there is a need to discuss a matter involving everyone and collect opinions.

Group meetings such as daily stand-up meetings in Scrum are awful. They tend to be long (not a desired feature, but that’s how it tends to be) and waste the time of many people regularly. During such group meetings often there is no well-defined agenda and no real follow-up. A cherry on top is that as 90% of the meeting is irrelevant to any given participant, many of them just wait for this to end so that they can do something valuable.

What is the alternative to daily scrums and similar meetings that are meant to organise the work of a team? A shared written record, of course. It does not have to be based on a specific technology. It could be a WIKI or a shared spreadsheet file, a job tracking application, or even a Markdown file in Git. The important thing is that it should have, as a minimum, sections corresponding to each team member, and containing information like “planned activities”, “completed activities”, and “unresolved problems”.

With that at hand, you end up with the following:

1. A written record of what was planned and achieved, week by week. You can always review it rather than guessing what was it that was said on the last daily scrum or planned for the second week of February. You have the information, and it is ready for your use whenever you want. Priceless!
2. You can update your progress at the time that fits you, and spend on that a few minutes rather than half an hour or more.

WIKI

WIKIs are great. It is fantastic when there is a place where people can store and retrieve information valuable in the context of their specific work. However, that has to be a single place, not several. Otherwise, people will get confused and WIKI won’t be loved and trusted.

Emails

Emails are easy to write, they form a written record that one can review at a later time, and they are not aggressively pulling people out of the state of flow.

However, emails are often abused. If you have emails sent out for silly, trivial reasons, the signal will drown in the noise and people won’t be able to use emails efficiently. If you also build an environment where emails are supposed to be read and reacted to in a matter of hours or even minutes - you can forget about the flow.

If you generate automated reports and send them around via email - that’s likely a bad idea.

If you have emails generated by various automations to, for example, report that something went broken - please stop. This is not how adults do these things.

If it is not a firing offence to send out an email with a short remark “look into that or else” to hundreds of people, then your firm is in bad shape.

Instant messaging

Instant messaging is fantastic to pull an unsuspecting engineer out of the state of flow. It is also great for wasting time by chatting with colleagues, the chatting which can probably be replaced by an email or a short voice meeting.

Instant messaging is not a new thing and has developed over decades. The modern implementations feature a powerful A.I. which can suggest you when to say “Thanks”. They also feature rich abilities at sending emojis, which you cannot switch off. This helps you to send your colleagues business-related messages like this one “🐱‍🐉”.

Jokes aside, the benefits of instant messaging in engineering teams appear to pale in comparison with the nuisance.

Chatter in a Kitchen

This method of sharing information is often overlooked, but it is valuable. Think of it mostly as flexible one-on-one meetings that happen in an informal environment. When people do things together they tend to chat, and sometimes they share useful ideas or information. The nice thing about chatter in a kitchen/gym/etc. is that it does not pull people out of the flow, while still helping them to share information.

Alternatives?

I think it would be nice to have a system where one can send non-realtime requests to other individual and receive the same from others, where such requests would be non-intrusive (without even notification pop-ups) and always be tracked until their original author has marked them as done.

This could combine the flexibility of instant messaging and emails with tracking of job tracking systems, while still being as non-intrusive as possible.

Does such a thing exist? I have not seen one.

Valuable vs Worthless Standards

Sooner or later, teams end up with standards on how work should be done. Some of these standards are a direct consequence of laws and regulations. These are inevitable and valuable due to their nature. Others are a matter of convenience or tradition. Let’s talk about the latter.

In software engineering, people tend to love coding standards. The advertised benefit is that the code looks the same everywhere, and so it is “easy” to work with. If you like that, and it helps you — please introduce these standards and follow them. However, here are my two cents on this matter.

The value of uniformity in coding style is not zero, but it is overrated. A good and deep post on this matter is worth a read to understand various nuances.

You can take a stand and demand that there has to be exactly two empty lines between two top-level definitions in Python, or that commas, other than those at the end of the lines, must be followed by a whitespace. You can be militant about it and make builds break whenever there is even the tiniest deviation from the largely arbitrary rules you have chosen to adopt. But the ugly truth is that it won’t help you much to deliver the actual value. The code may look very uniform indeed while being full of bugs and indecipherable even by its author. I have seen plenty of that in my life.

Maybe, just maybe, the members of your team should get properly exposed to various programming languages and styles. You know, a bit of JavaScript with its curly brackets, a bit of Python with its enforced indentation, and some LISP for good measure. Then, perhaps, people would be focused more on the essence of what’s written and not on its shape.

And maybe, instead of insisting on precisely how you are indenting the if-else, you should rather gently introduce ideas that deep inheritance should be avoided, and that optimising the code before ever profiling it may not be such a great move.

High-Quality Tools

Workers of all professions need appropriate tools and the quality of tools has an impact on the efficiency.

You would not expect miracles from a chef who is forced to use a blunt knife, would you? So why do people expect that engineering of any sort can be done efficiently with poor-quality tools?

The quality of tools in software engineering — as well as modern hardware engineering, I suppose — has two aspects: reliability and responsiveness.

Reliability of Tools

A tool is reliable if it does what it is meant to do and neither breaks in the process nor surprises its user. “Not breaking” is trivial, but what about “not surprising”?

The tool must not be too clever to pretend it is more clever than the person using it. For example, let’s say you want your command line to autocomplete a file name. Let’s further assume you have two files there: file1.txt and file2.txt, and you have typed “f” already. In Windows cmd, if you try to autocomplete, it will immediately autocomplete to file1.txt. Why not file2.txt? Because it is so clever and helpful. By doing so, however, it hides the fact that there was file2.txt nearby. If you hit the “Tab” key one more time, it will switch to file2.txt. Surprise! In Linux, you would normally have a different behaviour. The command file will autocomplete up to “file” and beep. If you hit “Tab” again, it will show you that you can autocomplete to either file1.txt or file2.txt. Then you type “2” and hit “Tab” again. The file name gets autocompleted to file2.txt. As you can see, it is as predictable as possible at every step.

What is the best way to violate the “don’t surprise me” rule? That’s right, an A.I. Or Lord, have we not suffered enough from autocorrection in mobile phones? Why unleash this upon us?

Responsiveness of Tools

Now let’s consider the matter of responsiveness.

When you are using a hammer, it is as interactive and responsive as it can get. However, pick a random modern web-based tool, and you may perish before it finishes loading a page. I am exaggerating, of course, but you know what I mean.

Modern software tends to be s-l-o-w. This is worse than bad, it is disruptive. When working with a hammer, you neither think about the hammer nor wait for the hammer to drive that nail into a plank of wood. This lets you focus on a higher-level problem: building whatever you are building at the moment. When working on something which requires you to use slow software you get distracted by its sluggishness and the focus of your mind switches from the job to the tool. That is not good for productivity.

There is a good article on the latency of user interfaces and how that affects people who use them. In general, you want to be sure that the response to any of the user’s actions is below a tenth of a second. The faster - the better. If it is slower - the state of flow may get broken, and you do not want that to happen.

Do your tools react in less than a tenth of a second? I guess I know the answer to that.

Riding Hype vs Being Ridden by Hype

I am deliberately avoiding naming names here, as hype cycles come and go, and the same thing that used to be a hyped-up and likely unreliable product may one day become a boring but sturdy and useful one… or just disappear.

You may be riding hype (for example, developing and selling a hyped-up product or service) or being ridden by hype (that is where you bought into the hype). The former is often lucrative, while the latter often kills productivity and wastes your finances.

There are two reasons why buying into the hype is a bad strategy. First, if that’s what you do, you will feel an urge to change the new shiny toy like a magpie, often changing the direction or the foundations of your product. Second, a hyped-up product is not necessarily a reliable one, and you may end up wasting a lot of time and money essentially beta-testing it. So unless that thing is really what you need, perhaps it is prudent to wait and see.

Complexity

Excessive complexity is perhaps the single most damaging problem in software today, and possibly in other domains too. It is accumulated as levels of abstraction are formed. It is brought in when third-party libraries are used to build software. It comes as poorly designed and bloated toolchains. And it grows within the codebase as programmers write more and more code with little regard for internal elegance and simplicity. Someone may say that these are purely aesthetic matters, but that is incorrect. Ugly code is where bugs dwell. When it becomes intolerably ugly it is declared to be a “legacy” as nobody has the heart to touch it.

Complexity leads to a death by a thousand dependencies. If you are not familiar with the story of a backdoor in XZ and how that has made SSH vulnerable on Linux — I suggest reading about that. In short, neither the backdoor nor the resulting vulnerability in SSH had been possible, had people understood the dangers of excessive complexity and acted accordingly. Alas, that is not in the vogue so far.

Complexity is also detrimental to the productivity of software engineers. When it goes off-chart, they are forced to spend much of their time doing work which has little to do with the real-world outcomes. I could have gone into details, but I would rather offer you to watch an enlightening speech on that matter by Jonathan Blow.

Culture

I will save myself much typing here and refer you to a good article by another person about the culture and why it matters.

(Social) Multiprocessing

When software engineers think about parallelism and concurrency, they think about Amdahl’s Law, locking, resource contention, queueing, and so on. There are many good mental constructs which help to design an efficient software capable of solving a given problem using the available parallelism of the hardware.

The same ideas are applicable to collectives of people. No two people can meaningfully modify exactly the same part of code, it is not viable to split a simple engineering problem between millions of engineers, queueing helps in many situations.

So why is it so common to implement antipatterns in social interactions?

Why is it that people are often distracted many times a day rather than pulling work from the incoming backlog “queue” (see “actor model” and “interrupts”)?

Why is it seen normal that tens if not hundreds of engineers are supposed to be familiar with and regularly contribute to a small bit of code which can definitely be taken care of by one or two people (see “resource contention” and “cache invalidation”)?

Possible Structure of an Efficient Organisation

Can your organisation be in a position to let your engineers work at their full potential?

I suppose classic organisations with top-down control are simply incapable of it. They may be able to hire good engineers (although that is exceptionally hard for everyone), but to let them do their job and exercise their judgment when doing so…? Nah, not going to happen. This gets particularly bad as the organisation grows. With ten people there is still some flexibility. With a thousand — forget it.

But suppose you are building a new organisation from scratch, and you want your engineers to be efficient. What could you do?

I feel like a bottom-up approach would be most useful. The basic idea is that instead of “orders” and “mandated resources” disseminated and appropriately allocated top-to-bottom, there may be a way where “requests” and “suggested resources” are distributed top-to-bottom, while feedback comes bottom-to-top. On each level of organisational structure, people would consider the feedback coming from the bottom (or assess the “situation on the ground”, where applicable), intelligently pick the most suitable resources available, and aim to fulfil those requests which appear most valuable and achievable given the circumstances. Ideally, each person or organisational unit would bid on the requests to be satisfied and provide feedback on the requests which are not worked on. This is, perhaps, the most important part.

The size of each organisational unit should be smaller than the Dunbar’s number, possibly much smaller (so that people would spend more of their mental capacity on problem-solving rather that maintaining social interactions). On the other hand, small units lead to more level of hierarchy, which has its costs too.

There would be a degree of internal competition between organisational units. This competition is important, as it lets people find the niche where they are most efficient and in this way boost the overall performance. It would mimic the competition and eventually evolution in the natural world. However, care needs to be taken to avoid the internal aggression between the units. Ideally, you want to have a “pack of wolves” rather than a “cluster of spiders”: while wolves hunt in packs, spiders are solitary and would simply attack and devour each other.

If the approach seems interesting to you, I could also recommend a good book: “The Evolution of Everything” by Matt Ridley. The areas covered by it are varied: culture, technology, money, and biology. In essence, it is a great book about bottom-to-top organisation and emergence. I feel that it is very relevant here and as a minimum, could be used as an inspiration.

Is such organisational structure possible? Maybe yes. However, I have not seen it tried on a significant scale.

Conclusion

The idea that there is a magical kind of engineer who is ten times more productive than everyone else when put into a random environment is a myth. However, the productivity of people in solving any given problem varies and that is indisputable. Also, and this is important, the productivity of an individual when solving a specific problem would depend on the environment within which that problem is being solved.

Perhaps you cannot find a x10 engineer or even a x2 engineer, but it may be realistic to have all of your engineers switch from x1 to x2 or more. This should be a matter of proper management and having a suitable organisational structure.