In all the people I ever hired and worked with over the years (data entry, devs, bizdev, sales or otherwise), attention to detail was the single most predictive trait for good performance. "Conscientious" is a better word perhaps. People who can't be bothered to understand how things work rarely produce amazing "high level" work either. It's a fallacy to assume you can "skip the details" IMO.

It's like inspecting a house: if you see shoddy plumbing and the walls are crooked and all the details are off, it is still possible the construction is amazing in all the attributes you CAN'T inspect so easily. But it's also quite likely the construction company didn't give a shit and were cutting costs left and right, and buying this house would be a safety hazard.

Also, you can pay attention to detail in strategic jobs as well. "Attention to detail" and "complex spaces" are not mutually exclusive.

But in my experience there is a kind of so-called "perfectionists" that won't work well in complex enviroments where:

1. they actually have to weight in the importance of details (and the cost of dealing with them)

2. Details aren't always obvious, and are easy to miss

So these kind of perfectionists might end up very focused on obvious details that don't matter that much and aren't useful to be taken care of in terms of cost-benefit relation, while ignoring not-so-obvious details that might actually matter more.

Important details are just as annoying to check as less important details.

IMO, it's the ability to discern and apply elbow grease to boring things that matter, and walk away from unimportant things that really predicts good outcomes.

Employees who are well-specialized can avoid betraying their lack of care about some aspects because they aren't even asked to think about that part of the work - they can go in for massive depth instead. But someone who wants to operate the whole business is in the position of "caring about things I don't want to care about". A lot of businesses are weakest where the owners are unable to muster sufficient sympathy.

I have literally no patience for the idea that attention to detail/conscientiousness is anything less than absolutely necessary at any level of an organisation.

Lack of attention to detail leads to screw-ups. Lack of attention to detail at a higher level just leads to bigger screw-ups. Lack of attention to detail at the top leads to colossal screw-ups.

Just think, for example, of RBS. No attention was being paid, certainly not at the top, to the details of all those supposedly investment grade CDOs. And then one day... BOOM! Turns out they were stuffed with junk and the whole shebang comes crashing down.

I also have literally no patience with people who describe themselves as "big picture thinkers" (thankfully this seems less prevalent these days; maybe I just move in different circles). You may as well skip the BS and say, "I am totally useless and ineffectual," because to me they're synonymous.

If you do anything without paying attention to the details you will do it badly.

(As an aside: I'm not here talking about micromanagement - you can't pay attention to all the details, obviously, at a higher level, but you can pay attention to the details that are appropriate at that level. This obviously only works if the people working for you are also trustworthy. If not, you clearly weren't paying attention when you hired them.)

It's rare for any individual to embody both aspects, so you usually pair these people up. For example: the strategic CEO + managerial COO. I've seen CTO/CIO combos with the same dynamic.

Just because someone resembles one more than the other does not mean the other is not just as important.

I think you just naively reprised the premise:

how exactly are you measuring "good performance"? The easily observable details they were good at attending to?

Of course, everybody wants an admin who doesn't make simple mistakes that cause outages, inconvenience, etc. But what about the one that provides an accurate asessment of the companies near-future needs vis-a-vis their trajectory, and recommends appropriate infrastructure upgrades?

Tell that to node developers who just want to stick a thousand libraries together and see what comes out.

Though I think I understand exactly what you are trying to say an wholeheartedly agree.

"Conscientious" people are probably naturally more inclined to detail to make sure that their work is good.

But I would point out a small delineation point: some things are just a matter of focus.

Typists, some kinds of accountants - it's a matter of 'process focus' - that they are focused and attentive to their work, and make few procedural errors. This I think is a behaviour and can hardly be learned - and is often not very well correlated with 'creativity' or 'big picture thinking' at all.

But I really do agree - the 'overall more conscientious' types - no matter the trade - are the best people, unless you need star talent, but even then ... They care about outcomes, not just 'handing off' some thing, or 'fulfilling their narrow duties' etc..

You know what's paradox: older people tend to be far more conscientious: they pay their bills on time, more likely to do the things they say, less averse to going off topic with hyperbole, get along with others, punctual, they vote, they volunteer, etc. etc. - and yet there is a strong bias against them in some workplaces. Though it could be related to the idea they may not want to learn new things, or 'keep pace' etc..

I know otherwise highly conscientious people who miss emails, are are a little absent minded at times. You can't have that for someone who is managing your schedule. :)

Most employee roles start as assistant roles: someone hired to take the less-important work off someone else's plate, so they can concentrate on the more-important work. Assistants aren't expected to be better at their job than the person hiring them would be—rather the opposite—but are employed anyway, because they have a comparative advantage in doing that thing. They're usually valued by the company strictly less than the person delegating the work to them.

On the other hand, there are specialist roles: people hired specifically to do a particular type of work better than a generalist (e.g. the person hiring them) could have done it; or hired to do something a generalist couldn't have done at all. These people can extract a lot of value from a company if they know their own worth; people like lawyers, trade-workers, etc. can all command high contracting rates.

But corporations tend to think a lot more in terms of the assistant role than the specialist role. There are a lot of jobs in companies that started off as assistant roles, and then kept the low pay and low status even after they became specialist roles. Companies have a hard time noticing that the people in their assistant roles are actually specialists, as long as they don't actively revolt and point out their worth.

This is, I think, a big part of why you can get an average salary as a programmer at a BigCorp "through the front door", but can get a much higher salary from the same BigCorp by building a startup that they acquire. BigCorps hire assistants, but acquire specialists, and that informs how they think of you; what they're willing to pay; and what they'll employ you to do.

It may surprise you to hear this, but I have encountered a lot of perfectionism (the negative kind) in software development.

I have struggled with perfectionism for essentially all of my life, and I find that the uncertainties of this particular trade (the lack of well established standards and the constant barrage of tool choices, to name two) make this a fertile ground for perfectionism hell.

What I've found is that while engineers will often focus on getting the implementation just right, they will just as often get stuck on murky architectural decisions. All things considered the decision is murky because the alternatives aren't clearly better, so the correct path is "pick one, try it, reflect later" rather than "debate hypotheticals until an impasse."

I've seen many engineers who are good at these murky architectural decisions, and I've also seen otherwise detail oriented engineers lock up a team on the debate around architectural decisions for so long you could have tried both ideas by then.

I've been working on a project involving some highly optimized C++ code, where the smallest architectural mistakes can cause serious slowdown. My architectural strategy thus far has been to 'just try' all of the decent options and then pick which one is the fastest. It's been working out well, but luckily my code is ~1K lines and the cost of doing this is minimal. (fun fact: template classes >> polymorphism in terms of speed, also, cache yo trig functions)

In contrast, I worked on a partial refactor of a fairly large (~150KLOC) code base, and the 'just try it' approach was definitely not an option due to the person-months work required to even make a small dent. That took quite a lot of thinking to figure out a reasonable path forward. And a lot of diagrams...

And then because there are fewer positions that involve strategic planning at the top of the pyramid, the relative status and financial compensation for those positions will be higher. The causality runs from hierarchy -> job descriptions -> pay scales & status -> educational system, not the other way around. As all the folks who graduated college/gradschool with loads of student debt but no positions available know, it does no good for everyone to train to be at the top when the top only has so many positions available.

It's an interesting thought experiment to imagine what the world would look like if we got rid of hierarchy entirely. YC was built on this premise [1]; it will be curious to see if it actually succeeds in eliminating hierarchy or if it just replaces one set of hierarchies with a different one, with different folks at the top.

[1] http://www.paulgraham.com/boss.html

You're spot on (nearly). Seth Godin will tell you[1] that it's a system quite literally built to produce compliant workers for factories during the industrial revolution: https://youtu.be/sXpbONjV1Jc

[1]: as will many others. But I like how he puts it in this video.

Maybe initially it was, but I can't see how a today's college-prep / AP sequence prepares kids for working in a factory. In fact, the opposite has happened: too many kids are going to college when many would be better off financially learning a trade.

Indeed, the primary reason that the stereotypical factory worker in the early industrial revolution was a girl was that girls were not yet required to attend school.

I would totally believe that deliberate elements of compliance were added at some point, but those seem to have mostly appeared in the late 19th and early-mid 20th centuries: clearly well past the Industrial Revolution.

Except for the traditional "professions". Everyone wants their doctors, lawyers and pilots to be heavily 'detail-orientated'. Such professions bake in a degree of perfectionism. (I'm suffering it now as I have trouble even posting an online comment without going over it six times for spelling and grammar.)

This is typical when designing software: There's limited time and resources available, and you often need to make a difficult tradeoff between the time taken to create something that's (perfectly?) maintainable long-term, and saying "enough is enough, we're losing money every day that we don't release". I get the impression that people are rarely able to keep both of these concerns in mind. Many skilled developers ignore the long-term opportunity cost of taking a long time to write "perfect" code, whereas many managerial types ignore the long-term technical cost of shipping poor-quality, difficult-to-maintain code.

Perhaps that's because (a) nobody knows how to educate people to become entrepreneurs, and (b) the kind of people who will make good entrepreneurs are the kind of people who won't be very happy in a one-size-fits-all education system like the one we have.

I'm not sure an "education system" could do this. The whole point of having a "system" for education is uniformity: everyone learns the same things. There is some variation, but not much, because no "system" can handle much diversity. But the whole point of entrepreneurship is diversity: everyone tries different things.

Because it is? That's not necessarily a bad thing, the world only needs so many entrepreneurs.

This might be true in principle, but in practice I would say our current world suffers from a huge undersupply of entrepreneurs, not an oversupply. Far too few people see the purpose of their jobs as creating wealth.

You have to learn to be a good practitioner before you can progress to a leadership role. The junior-role skills are omitted from the senior role, not because they are no longer required, but because it is taken as read that the senior candidate has already acquired them.

Years ago I read the results of a study comparing teaching approaches in the listed environments, with a very clear conclusion about the intentional training of execution vs. creativity vs. leadership and big-picture thinking.