Hacker News Reader

Comment by dahart | Hacker News Reader

My translation: labeling an engineer as 10x may be mis-attributing the discrepancy to individual people, when the causes are most often environmental. Sure, there are outstanding performers and catastrophic duds every once in a while, they do exist. But more often than not your performance is less a reflection of innate skill and more a reflection of things like your managers, your situation and motivation, your momentum and familiarity with your tools, the mood in your office, your level of ownership, etc., etc..

I have been both subject and observer of situations where someone's performance was amazing in some cases and lacking at best in others. I have experienced being 10x when the situation was right, and 0.5x when it was wrong.

So how do you make a 10x environment on purpose? I've tried on teams I've led, and it is by no means easy. Can anyone with concrete experience share reliable tips?

View on HN

>So how do you make a 10x environment on purpose?

I think there are two necessary parts:

1. A high level, well-known, agreed-upon plan. Everyone needs to know what they're working towards, why they're working on it, and how they'll do it. This lets people work largely autonomously but towards the same goal, reducing friction. I've been a 0.5x engineer because my manager told me what I needed to build but not why. So, I'd build something, and the feedback would be "no, that's not exactly right, just do it this way". What could have taken an hour would take days while I slowly figured out what he was imagining.

2. As few blockers as possible. Use tools and languages the whole team knows or can learn well. Create a collaborative environment where people can ask questions instead of spending hours working through tiny issues. The manager should make removing external blockers one of their highest priorities.

This is what allows people to work at peak efficiency. I think when there's nothing holding them back, most good engineers are "10x" engineers.

Great points. One thing I would add is to pay a lot of attention to your team's dynamics. One bad (or just not as engaged) team member could derail the whole team's morale. Friction should be dealt with immediately, even if it's really minor.

I think we should strive to avoid 0.1x environments. I work in a cube farm and there are plenty of days when my neighbors are so loud that my productivity goes to 0.1x or less. When I work at home on Fridays I often get more than than during the 4 preceding workdays.

Add to this constant meaningless meetings where everybody is late and unprepared.

I often hear "I will work tonight or on the weekend so I get things done". I don't understand why everybody seems to accept that the workplace environment is bad and nothing can be done. I have raised this to senior management quite a few times but they just shrug their shoulders.

I think it's a autonomy thing. People that care about their work will care about their work environment, and they're the best stewards for getting that kind of work environment in place. They've got the tightest feedback loops after all.

This seems to conflict with ease of management, which might be why this kind of autonomy is rarely granted. Cubicles are cheap and easy to manage, having 50 different environments in a 50 person office and resolving conflicts between them is not.

There's some approaches that partially address this problem, for example "Work from home", which whilst allowing some workplace customization has a number of drawbacks.

I guess the simplest way to go about it from a strictly physical (eg. excluding communication channels) work environment standpoint would be to give people a space and money budget, and treating them like responsible adults with it. "want to wall in and sound-proof your space? sure". "Need 2 different office chairs for your back problems? Put it on the list."

Set a suitable budget cap per person, divvy up available space, and optionally set up a position that handles ordering of things and tracking of funds spent.

Historically speaking, very senior employees get to do this with their own office to a degree. But the output and impact of good software engineers might warrant the same kind of autonomy.

It may be a considerable leap of faith from a management standpoint, but there's some absurdity in managers trusting engineers with business critical systems, but at the same time being concerned about their ability to pick a desk and chair to seat their butts upon.

Then there's the thing with open offices, but that's a cost of communication issue, signal-to-noise ratio kind of thing. Talking in an open office is broad-spectrum and cheap for some of the participants, but information conveyed is not necessarily valuable in the greater scheme of things, in addition to incurring attention costs for everyone else.

It's like radio without the FCC or everyone communicating over the broadcast address in a network.

Everybody deciding their own layout won't work IMO.You can't just put up walls as you like. There need to be fire escapes and stuff.

In my company senior employees seem to view offices as a reward not as a productivity tool.

You'd probably need to put sensible routes through these divvied up plots. You could even specify the location the door needs to be at, and veto things that aren't up to code. It's more of a thing of "default restrictions" and "default permissions". Default restrictions are easier to work with, and they seem to solve problems, but they impede things. Default permissions let things happen, but they also let things happen.

I do think that senior employees seeing offices as a reward instead of a productivity tool is not ideal. Depends on the organization though, a call centre doesn't follow the same rules as a start-up or an assembly line. Forcing any of these models on the other would result in sub-par results.

It might just be latency, where the structure and nature of a business changes, but the culture and processes don't quite catch up. Software engineers in cube farms like Skype trying to push P2P messaging to mobile. Some mix of sunk-cost fallacies and the slow momentum of behemoths, I'm sure of it.

I do have some opinions on how to achieve these changes, but it'd be hubris for me to suggest them to you, since I'm unaware of your particulars. But I still hope that you get to work in a 10x environment some day. We all should.

It doesn't matter if you're a 10x peanut butter sandwich maker; no one is 10x all the time.

There are projects, and there are chores. Everyone wants to work on the projects all of the time, but that is wasteful. When one is productive, they should work on the projects, and when one isn't productive, they should do the chores. That's a habit that can be learned.

The only person who knows what they should be working on is themself. So, autonomy is important. You can't have a person with a habit of using their time most effectively who also isn't in charge of when and how they spend their time. Self-management is a skill that can be taught.

I think that talking about a 10x engineer or 0.5x engineer misses the right optimization: good software is built in teams, so build a strong team. Cross-skilling, pairing, and blocker removal all help give people a collective sense of commitment and autonomy: you have the right to touch the systems you need to accomplish your job, and it's my job as servant-leader to remove whatever's stopping you. But you have less leverage and less resilience without that sense of collective ownership.

I've likewise experienced both 10x and 0.5x situations. The latter invariably arose from sitting in a corner, divorced from context or support. The former is extremely rare and I've only achieved it on personal projects. But I'll settle for a motivated and healthy team of 5xers any day.

Pair programming, I think, can lead to a 10x environment, if the culture is built around pairing.

How has pair programming worked in your experience?

i am infinity better with a pair (can solve problems i cant solve alone) but you have to build the company culture around it. i am a founder, I pair with my partner, we think we can scale the company this way. You can't force it into an existing company. You hire different types of people when you're pairing full time, and that's just the tip of the culture iceberg.

> You hire different types of people when you're pairing full time

Yes, extroverts, specifically. :)

Even if you've been close friends with someone for twenty-five years (as is the case with someone I pair with for some problems), there's still a fair percentage of your thinking that will have to be focused on social stuff: putting expressions on, conversational behavior, avoiding asides that take a second to think but would require a minute to explain, etc. These are things that tend to occupy the same mental space as where I am thinking about the context of the code I'm writing, and while pairing can bring back some of that contextual thinking in the form of the other person, the bandwidth is so much lower that pairing seems useful mostly for learning, or for sharing a problem that I've already struggled with (so that my deepest thinking about the problem happened while I didn't also have to run sociability at the same time).

I've had the same problems trying to pair with another junior engineer. I would seem as if you'd be better of pairing with a senior engineer/mentor where you're focused on problem solving but also it is seen as an apprenticeship exercise, which means less distractions.

Work with easy to understand frameworks, and don't try to link together tons of complex systems that are hard to configure and require outside support. Don't have nitpicking code reviews. Don't have complex and bureaucratic process rules for code check in. Don't have build and test environments that break all the time. Don't have too many meetings. Don't have deadlines or ETAs for engineers, this makes them stressed out. Allow for flexible work hours.

Culture/environment is a critical enabler, but alone it doesn't create 10x people.

Reply on news.ycombinator.com