back
494 comments
> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management.

I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most waste I've ever seen has always come down to poor communication rather than anything actually business or technical related.

Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers.

Off the top of my head these are the most common two "negative engineer" behaviors I have seen

1) Biggest one: an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place. This is the key to never shipping and destroying entire companies.

2) Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is the key to your product dying a slow death over several years.

There are negative engineers doing this stuff ALL. THE. TIME. EVERYWHERE. Despite unquantifiable volumes of both ink and blood spilled trying to prevent them.

FWIW :)

I used to despise the incredible amount of time we could spend on a single powerpoint slide sometimes.

Then one day when going over same slide for the 5th time with my boss and mentor, I realized:

* This slide will be seen by a person in power

* they will make a decision based upon that slide

* I would like to spend 3 hours explaining them the intricacies of my project/architecture/problem/whatever

* But they have 10/100/1000 other projects, and they have 20/10/5/1 minute to devote to me before they make a decision

* A slide or set of slides might therefore have an impact across 1/10/100 people over week/month/years due to a decision based on a slide or set of slides

* therefore, it can at times be rationally logical to spend a lot of time word-smithing a slide in order to help the right decision

As programmers, we understand that we might spend 10min/hour/days/weeks on a small but crucial piece of code, because we need the computer to understand it and do the exactly right thing in a complicated scenario; and we do not consider it a waste of time (though our management might! It's a curiously symmetrical situation :-)

Sometimes, slides are exactly that, but for people - distilled information to enable executive stakeholder to do the correct thing.

Same with other items - diagrams? They can be phenomenally useful! A good diagram can spread understanding of goal and ensure we all build the right thing. Bad diagram can set 100 smart people on divergent paths!

I suspect that the presentations and diagrams which need to be made, are made. Good communication is important, but the artefacts come about from the organic need to communicate an idea rather than orders from on high.

Consider "The Bar team wants to know about our new Foo architecture" vs "The Bar team needs a 30 minute presentation on our new Foo architecture". Does the Bar team actually need a presentation, and could it be a live demo? Do they just need better documentation? Are they building an integration, and would someone from your team working with them for a week unblock them in a way a presentation wouldn't? Could this be a ten minute call between you and the one engineer who needs a hand?

Good and experienced engineers do their best work on open-ended tasks. This is as true of communication as it is solo work. Artificially dictating the solution without understanding the problem limits them.

I'm going to go out on a limb and suggest that the author probably thinks a healthy balance exists between zero communication and spending 100% of one's time playing JIRA games and visibility hacking.
I recently heard a quote that resonated with me: "If you want to go fast, go alone. If you want to go far, go together". I wonder if someone who treats these tasks as "non-work" is thinking of themselves as being more productive because they go faster than the folks around them, not considering that these other tasks that slow them down individually also help the team go farther in the long run...
> Common examples include presentations, diagrams, and ticket management.

Ticket management is stuff that needs doing, obviously.

Diagrams are illustrations; if something is so complicated it can only be understood with a picture, it's too complicated. But a quick diagram on a whiteboard (or with a pencil on the back of a fag packet) might be helpful.

Presentations (with slide-decks) are for managers[0], not engineers. They are a huge drain on time. I got severely dinged by my manager for doing a presentation without a slide-deck; I hadn't prepared one, because I had real work to do. But I think I showed my manager up, because all the other engineers had turned up with slide decks.

A crap slide deck is quick to make, and completely useless. A really good slide deck can take days to make; it's a specialist trade, like making good user documentation. Slides must augment the presentation, not distract from it.

[0] I've been forced into formal management once or twice; my experience was that at least half of management is bragging to other managers about how important your team is, and slide decks are great for that.

> Ticket management is not busy work, it's a necessity for everyone to keep updated.

I would say that rather depends on how much of it you do.

I don’t know. Tickets can still be busy work depending on when you demand them to be done. Sometimes a ticket might best be handled at a different stage in the project to give it the time and context it deserves. If you are just closing out tickets, sometimes out of context and as fast as possible, you are doing busy work.

This could just be bad ticket management with where I work. Or we use tickets in a less standard way. I’m not sure, I work in fpga design so it’s not like a user submitted bug, it’s a request from one of the 1000 review meetings.

Yeah, in my experience writing complete tickets forces people to actually think through designs and trade-offs. It also has the nice benefit of exposing their thinking to others in the organization, who can weigh in and go, "Oh, if you're doing that, we have to do this on our project."
A lot of toxic negativity in that post.

Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk.

https://www.inc.com/jessica-stillman/studies-being-a-jerk-is...

Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.

I'm nodding along to this list because I've been consulting with a large government department that has dozens of programmers with the effective output of maybe... two? Three at the most.

They tick just about every item on that list. Staggering inefficiencies everywhere, duplicated work, duplicated codebases, etc, etc...

The worst thing about these problems is that they compound, often exponentially or at least quadratically. Slow builds mean bug fixes take longer. Longer bug fix times means they can't all be fixed to meet deadlines. That means that they now have to be prioritised, which incurs management overheads and shuffling things around in spreadsheets. This then delays things further, which means even critical requirements (security!) get dropped on the floor.

The inevitable consequence is that things are constantly breaking in production, and everyone spends half their time fighting fires. Fires that were marked as a "low-priority" smell of smoke six months ago.

Productive staff see the writing on the wall, quit, leaving only the unproductive staff that "couldn't get a job elsewhere".

The snowball builds rapidly from here into an avalanche of badness.

> Attract bright engineers and waste their potential. Undersell the difficulty of the project to management; oversell the project’s usefulness. Tell management it’s “almost complete” until they scrap it.

People at every level of the organization, from the top-down, have done this since forever. The -10x engineer will choose a language that they're fascinated by, but have no production experience with, and then spend most of the budget building libraries that they assumed already existed in the ecosystem. "Almost complete" becomes "almost ready to start".

I think as engineers we have to realize a few things:

1. Unless you are working alone and for yourself good communications are more important than most engineers will admit. The thing is: the quality of communication does not necessarily correlate with the quantity or the duration of it. And depending what role you play, you might not need a lot of communication in order to get a clear picture, while others might need more (for you: unnecessary) communiation to get on the same page. The drummer of my band always used to say there shouldn't be that much discussion about what we are playing, which is super easy to say if you don't need to harmonically integrate with other instrumentalists.

2. Every single one of us is in danger of dialing the degree of complexity too far, or not far enough. Every single one of us is in danger of doing things a certain way because we try to make them nice, while that makes them technically unmaintainable. Code is communication as well. Communication with your collegues or yourself in the future. Good code is efficient, reliable and communicates well. Sometimes we have to sacrifice a little bit of one for the other, but clear code and e.g. efficient code should not be seen as opposites, but as a multidimensional problem to which there are solutions that work better on both fronts and solutions that suck on both fronts.

3. Context. Many engineers I have met have a hard time explaining some concept or problem in a way that it is understandable. Either they dive in way to hard and assume everybody knows what they know or they will start explaining it and get side-tracked and end up talking about something entirely else. Giving someone a clear image of where we are and then zooming in on the detail in well-sized steps is a skill I wish more people had. This skill also helps when debugging, because you will check your zoomed-out-priors first and then bifurcate the problem space as you zoom in.

Good list but it's It's missing: - "use an new, different and exciting technology for each new project, however small"
The "don't rock boats" is really what can slowly destroy companies. The -nx engineers know a lot of other -nx engineers that can come onboard until the stable boat just sinks.
I love the skunkworks reference. Every time I see something like this in a 3 person startup, I just want to grab someone by the neck and tell them:

"Bro, your mobile app redesign to Flutter is not a 'skunkworks' project. Unless you are Lockheed Martin, or Boeing, and the project will approach a trillion dollars of spend, has the capability to eliminate millions of human lives, and requires 1000 security managers and 25,000 Top Secret/SCI employees you ain't doing no 'skunkworks'"

Cracks me up.

> Make undebuggable programs. Plaster layers of abstraction over everything. Write spaghetti code. Make everything sensitive to initial conditions. Avoid pure functions. Use dependencies liberally. Say “it works on my machine” whenever possible.

A lot of legacy software is like this. I wonder how many billions it costs the economy per year.

This reads a lot like one of those WW2 low-risk sabotage manuals.
This whole thing about company/team culture is that it is random.

Even when you are at the best team, culture-wise and productivity-wise, accept that this will not last. All it takes is for 1 person to arrive/depart to ruin the culture.

Just do your best and bounce when it's time. You cannot move Mount Fuji with a teaspoon.

Got it. The -10x engineer is bad management who are in turn bad because the rest of the business is completely illiterate about anything even slightly technical.
I've seen engineers who are good candidates for -10x... The moral of this story is, of course, if people are submitting work that creates more work, you must push back against them.

Part of the issue is that intelligent people can be better at justifying work that wastes everyone's time. So if you're in a leadership position you really need to make sure people have their eyes on the prize and that they aren't padding their resume or needlessly doing tasks that worked at their previous job.

A lot of these look like Goldilocks problems, e.g.

> "Waste 400 hours of engineering on bad architecture: Give zero consideration to how your system design will evolve over time. Alternatively, drive your team obsess over architecture decisions so that they don’t have time to test their hypotheses."

A complex project with many people working on it in different teams calls for modularization and well-defined interfaces, so working out the architecture up-front does matter, and changing it down the line will have huge costs. Staged progession is the answer, probably, which is why you'd want to have a meeting where everyone agrees, "this is the architecture we're going with, now everyone go build the modularized widgets that fit into this architecture, here are the stable interfaces to build to." Screw that up and you end up with tons of wasted effort, but dithering around and never making a decision is no better.

Some of the other stuff relates to the 'build team spirit' corporate mentality which is kind of culturally variable - some people love it and some people hate it. Minimal is better, IMO.

Then there's the 'basic technical proficiency' category of problems, e.g. recompliling the entire collection of source code every time you make a lttle change because the build configuration in the makefiles is incorrect etc. That's probably the easiest category to fix, some people just have holes in their knowledge and those can be filled. Here is where the company jerk is a major liability, though - you want people who can teach others how to improve their workflows without engaging in any condescending / egomaniacal / prima donna behavior.

Most of these are either management issues or written as if the person is acting in bad faith. But there are plenty of engineers who are 1) smart 2) driven, and 3) well-meaning that still find themselves in this position

One time I found myself in this position was overseeing an infrastructure migration for scaling reasons. The goal was to have it done before we hit scaling limits, and we had a team of 2 people and a fairly complex architecture. From the start, I suspected it might be difficult to do with the current staffing, even after extensive planning, but I underestimated what the costs would be to not completing the project on time.

I was told by my manager that completing the project before hitting scaling limits was life or death for the company (it wasn’t, I know this because the sales team didn’t hit their targets and we survived). I now realize this was my manager attempting to motivate me to take on a tough project, rather than real truth. Had I pushed back harder, inquired about company financials, this would have been exposed as not true.

While we eventually ended up completing the project, we completed our largest phase of hiring while in limbo between 2 architectures. The company became disorganized, accepting large amounts of tech debt as it was tough for new hires to understand what the “correct” thing to do was, and many people ended up adding to the legacy architecture in cases where they didn’t need to. It was a mistake that likely cost millions, even tens of millions in my eyes.

The correct thing to do, of course, was just to insist that we couldn’t scale until we trained or hired more people to help. Limiting growth is often seen as unacceptable in startup culture, but IMO should be considered more often.

You forgot the most crucial part to making a career in big corps: After you fucked everything up "rescue" the project with witnesses.
> To ensure developers are context-switching, recompilation should take at least 20 seconds.

I'm now wondering what languages and projects the author has worked on if they expect compilation to take less than 20 seconds. Maybe small-ish golang projects? I don't remember the last time I worked on something interesting where recompilation was always under a minute...

sigh. The 10x engineer has become tech's most toxic concepts and devs are its victims, yet we keep bringing it up constantly. Every time it's brought up it's a new variation that's either bad or good but always different than the original proposal of the BEST programmers are 10x more productive than the WORST developers from a paper in 1968. All that is come of it is devs arguing about a hypothetical programmer is and made management even more insufferable. The idea is only hurting you, quit bringing it up, when it is brought up point out it's a bad concept and move on.
I don't agree that writing and communicating designs, plans, and discussing problems or solutions is a waste of time. Our job isn't to blast code out and not talk to anyone (unless you're the sole developer on a project, but even then you should still write). Writing is thinking! Thinking is our job. Code is the artifact.
- Add cool new tech to projects you're working on with ten other people. Ensure only one other person knows.

- Name all your variables 'data'.

- Copy and paste everywhere. People will think they've fixed a bug, and they have, but you've got seven slightly different copies of the function that needed fixing and now there's six left.

- Take a project that's using one of those 'prettier' 'black' style tools to avoid bike-shedding discussions about linting. Change the options because you prefer different ones. Start a bike-shedding discussion about linting.

- Use multiple divs for a single circle-shaped avatar.

Missing: Start migrating the code base to new technologies/frameworks early, but never finish it.

Though that might actually end up costing more that 400 hours of wasted time.

This does underline a key point. Avoid unnecessary perf hits in your workflow. The whole Interstellar meme of "this little maneuver is gonna cost us 10 years" is very much true. I've worked on high performance teams that did the wrong thing strategically and it ended up effectively slowing down their pace massively. It doesn't matter how fast you're running if you're running in the wrong direction.
I got burned out and lost a few years of my life due to a job like this.

We had two things:

a. Poor systems and poor communication permeated the IT department

b. IT was viewed as a cost center so no amount of heroic intervention was ever rewarded proportionately to business impact. It was Sisyphean.

If you are in a situation like this, please run away. You can't win - either the free market will destroy your employer, or your employer will destroy you.

I actually wrote an article a little bit like this one, a tongue in cheek piece called "The Unethical Developer's Guide to Personal Success": https://blog.kronis.dev/articles/the-unethical-developers-gu...

In short, software development should most of the time be treated as a group activity and you should consider how the output of your own work affects those around you. While you might not feel like documenting your decisions is a wise use of time, it could help others down the line. The same goes for choosing the simplest solution that works well vs going out and writing lots of "clever" code. Things like the ways how we communicate, how much nitpicking vs accepting "good enough" solutions all compount and have a pretty great effect on the output of others.

> To ensure developers are context-switching, recompilation should take at least 20 seconds.

So true. But only 20 seconds? The project im working on takes 20 MINUTES to compile for any code change. I constantly forget about it while trying to get something else done in the mean time. It frequently takes whole days to track down and verify simple issues.

> Trap 10 engineers in a futile skunkworks project.

LOL, I thought I was cynical

Good list. Should be called "How to be a -10x Manager" though, since the majority of the bad decisions listed there are under the manager's purview.

Reminds me of the CIA sabotage field manual: https://www.hsdl.org/c/abstract/?docid=750070

On another note, many of the items there are "create pointless X". It's actually a thin line between "important X" and "pointless X" and many people will disagree where it actually lies (as evidenced in the comments here).

Thanks for sharing! I'll start putting everything here in practice immediately. Some of these are already widely practiced at the company I work for, though, so I probably won't stand out too much.
> To inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible.

I transitioned from startups (for 10 years) to a large company (for 5 years). Part of that move was adjusting from a culture of no lengthy documents to a culture full of lengthy documents, and I would never want to go back. Having explicit documentation in writing, where folks can debate the merit of ideas is so so much better than having it living in a few people's heads, unable to be critiqued.

Edit: add a word.

I might be skipping the competence part but personally my performance has been directly correlated to how much I care about my team/org. My attention is focused and goal oriented in a proactive way when I do care but passive and reactive when I just want a paycheck. I don't have good advice to spot how people care so its not super helpful but people that don't attempt to help in hairy situations or seem withdrawn from conversations are probably not on the good end of things.
>>> inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible. Welcome all opinions and aim for engagement.

Mostly spot on but I am not sure of this one - well written notes / emails about technical issues and some of the trade offs or desired outcomes are really useful - they actually help "align" people. Think more "Linus rant" than "CEO powerpoint" but the idea is there

Oh, you forgot “publish a service with undocumented limitations that others are required to use”. You can easily achieve -10x that way!
Frankly there's a kernel of truth in here. We've all worked with that one engineer who seems to have a knack for creating chaos and confusion. But let's not forget, it's also important to acknowledge the value of a good -1x engineer - they're the ones who make us appreciate the +1x engineers even more!
From my experience the lowest productivity engineers are the ones that just never talk. I understand being an introvert but we all chat about things we have passion for.

Anyways ive seen so many "programmers" that sit silently in meetings and also just do not produce good code. Usually they produce bad code that I have to revert.

Article's points shouldn't be taken as seriously as the general message: be just as aware of the invisible, negative forces that hinder employees as you are of the positive forces which stellar employees bring. Yin and yang.

Important to note that there are also 10x environments that make everyone in them 10x as effective.

"Change requirements as far into development as possible. To avoid blame, obfuscate requirements from the start." -> "Refuse to change course even though new information came to light. To avoid blame, display extreme confidence in the requirements even though there are still unknowns."
Excellent manual when it doesn't matter if you pretend to work or do the work and the outcome is the same.
Meetings are a huge opportunity to either value-add or value-subtract and a little planning can go a long way. Some pointers:

* Have an agenda and circulate it along with the invite. Let people know what you want to discuss so they can prepare. * Know what outcome you want from a meeting and let people know in the invite. Again, it lets them come prepared and even better, make pre-meeting suggestions. * Think about who needs to be involved. Do you really need everyone, or just one or two people. Again, agenda lets folks know if they can contribute or if someone else needs to be pulled in.

It's not that meetings are bad, but bad meetings waste lots of people's time. Good meetings save time.

Oh, and write down meeting minutes and publish results. The person you're recording this for is usually yourself. :>

As a manager, I’d rather have a 1x engineer who spends that x doing exactly what I want/need.
In that context, I love giving complete responsibility to a small, integrated team of designers and programmers. They define their tasks, adjust the scope, and work together to build vertical slices of the product one at a time. This completely differs from other methodologies, where managers chop up the work and programmers act like ticket-takers.

Instead of having 10x engineers, make the team 10x. Shape Up (https://basecamp.com/shapeup/0.3-chapter-01#making-teams-res...) by Basecamp is the best resource I've seen on that topic.