3 ms·

> Because I had special skills it meant that I was being relied upon more to do work that no one else could do. This is a textbook example of a bad system with

> Because I had special skills it meant that I was being relied upon more to do work that no one else could do. This is a textbook example of a bad system with a single failure point/bottleneck. One way to be considered "10x" is to be the only person with the know-how to keep a critical function afloat. We really don't learn from history. Eli Goldratt wrote about this in his book The Goal--publication date 1984. Context was manufacturing but it's easy to see the principles at work and consider them in other contexts. Gene Kim, George Spafford, and Kevin Behr wrote about this in a DevOps context in The Phoenix Project--publication date 2013. These are just two examples of individuals who wrote books with mass market appeal that read like novels to illustrate their points. Many, many other people have thought and written about how to avoid building bad systems. And yet still, in 2019, as this 10x discussion flares up again, it's a myopic view of the individual without a scent or sight of talking about bottlenecks or systems. Sometimes I'm in awe of Startupland and Tech World's accomplishments. Other times I'm in awe of what it doesn't even know it doesn't know. https://en.wikipedia.org/wiki/The_Goal_(novel) https://en.wikipedia.org/wiki/The_Goal_(novel) https://www.goodreads.com/book/show/17255186-the-phoenix-project https://www.goodreads.com/book/show/17255186-the-phoenix-pro...

lowercased 7y ago
if no one else at a company knows how to do a task, and you are doing it, you're not a 10x dev, but an 'infinite-x' dev, no?
- Jtsummers 7y ago
  And you should also start looking for a new job. It means you're 100% utilized, you have no free-time, no real opportunity for growth, and no chance to improve the situation. You have one job (or one set of jobs). You take a single day off, a week, you come back to a fire. You spend a day or a week fixing that fire and you're back in the same grind. It may be fun, but you can't be promoted without killing that business line. You can't work on new projects/products without killing something. If you have decent management, they'll set up firewalls between you and the people requesting work. Trainees or people of some experience but perhaps not as quick under pressure. Reduce the burden, start automating what can be automated. But if that's absent, if the pressure remains. Enjoy the glory, but look for an exit. You're one vacation away from returning to a layoff.
  - Balgair 7y ago
    > You take a single day off, a week, you come back to a fire Enforced vacation time is a great way to figure these things out prima facie. As employees, we all know that 'unlimited vacation time' is just a code for 'no vacation time' (with rare exceptions). But companies get into that trap too. When they red-line their employees that hard, they expose themselves to unncessary risks. People get sick, they have tooth aches that need mending, they get jury duty notices during a crunch, their folks go into the hospital, etc. Let alone actual in-house issues of burnout, server issues, internet connectivity. I worked with a shop that was dog-friendly once. They had to get fumigated every year or so, as the pooches would invariably bring in ticks and bugs. That was four days they just could not work at the office each year, with a pretty nasty decline in work enviroment quality in the lead up to each fumigation. Enforcing vacations causes the firms to deal with these issues ahead of time. Vacations have been well studied and, especially with knowledge workers, improve employee productivity (generally). But they also act as vaccinations towards unseen workplace issues and black-swan events.
    - Jtsummers 7y ago
      Tangent: This is related to the idea of JIT and low-inventory in Lean. By reducing inventory, it allows problems in production to be revealed so they can be addressed. Consider a simple 2 stage process. The first stage is down 50% of the time on average: A -> B When A is running, perhaps it can produce inventory faster than B can process it. So we run A at full-capacity and build up massive inventories in front of B. A happens to be down for a week straight, we exhaust that buffer and can't produce any more products. Because the inventory is usually allowed to go so high, the problems with A aren't addressed (they aren't pain points for the business). By the time A is down for a week and it becomes a pain point, it may be too late to save this business. In Lean, you pull inventory into B only when needed (realistically you'd have some lead time, of course). You maintain a modest buffer to accommodate that lead time. If A can't produce in time, instead of growing that buffer permanently, you address the issues with A. Identify the failing components in A and find a more reliable replacement. Maybe there's not enough people trained to operate A so you cross-train people. Maybe you buy a second system (cheaper, lower capacity?) that can do what A does to shift the burden, or you find another machine that can be conscripted and used to make the same things that's only rarely needed for its primary purpose. People who operate at 100% capacity and are your "heros" are similar to A. Everything seems great as long as they're there, but once they're gone (even for a day) they're noticed. By capping overtime (or eliminating it), by encouraging vacation time, you can find out who is critical to your business processes, and start shifting the burden (because it's an obvious pain point). Anecdote: We had a guy who wasn't officially IT, but had been doing IT for our build and other dev systems, it wasn't his main job. He was gone for a vacation or business trip for a week, on Monday the systems went down. Nothing was accomplished until he returned and fixed the problems because no one else knew how to do that work. He was a liability for the team and business. This happened on more than one occasion. Management loved him because they didn't recognize the causal relationship between his leaving and things being in a failing state (didn't happen everytime, he wasn't causing the failures, but his absence meant the failures were noticed and not addressed quickly). Control your "WIP" (work-in-progress or work-in-process) better, and you'll see work piling up in specific places. Just track it on a board or create a helpdesk ticket system that people have to interface with. It'll make all these pain points obvious so they can be addressed.
ianbicking 7y ago
> This is a textbook example of a bad system with a single failure point/bottleneck. One way to be considered "10x" is to be the only person with the know-how to keep a critical function afloat. I think often (and in this article) an organization has zero people with the know-how, and then someone struggles and figures things out, and now they have one person. That one person might be someone who has figured out how to deal with a difficult stack, or might be the person who has built that stack themselves – either way, they've done something valuable because they are handling something that is critical. The next step – spreading that knowledge, or making the knowledge more accessible, or making the system more usable – is important, but it's not wrong that the organization has ended up this position. It's part of a maturing process. And we shouldn't shit on the person who brought the organization from zero to one, just because they aren't the person fully equipped to bring the organization from one to many.
- heymijo 7y ago
  > And we shouldn't shit on the person who brought the organization from zero to one Very good point. There's an underlying principle here that I didn't say. Management is responsible for the system. Dead simple when written out, yet infrequently shown through managerial actions.

lowercased 7y ago

if no one else at a company knows how to do a task, and you are doing it, you're not a 10x dev, but an 'infinite-x' dev, no?

Jtsummers 7y ago
And you should also start looking for a new job. It means you're 100% utilized, you have no free-time, no real opportunity for growth, and no chance to improve the situation. You have one job (or one set of jobs). You take a single day off, a week, you come back to a fire. You spend a day or a week fixing that fire and you're back in the same grind. It may be fun, but you can't be promoted without killing that business line. You can't work on new projects/products without killing something. If you have decent management, they'll set up firewalls between you and the people requesting work. Trainees or people of some experience but perhaps not as quick under pressure. Reduce the burden, start automating what can be automated. But if that's absent, if the pressure remains. Enjoy the glory, but look for an exit. You're one vacation away from returning to a layoff.
- Balgair 7y ago
  > You take a single day off, a week, you come back to a fire Enforced vacation time is a great way to figure these things out prima facie. As employees, we all know that 'unlimited vacation time' is just a code for 'no vacation time' (with rare exceptions). But companies get into that trap too. When they red-line their employees that hard, they expose themselves to unncessary risks. People get sick, they have tooth aches that need mending, they get jury duty notices during a crunch, their folks go into the hospital, etc. Let alone actual in-house issues of burnout, server issues, internet connectivity. I worked with a shop that was dog-friendly once. They had to get fumigated every year or so, as the pooches would invariably bring in ticks and bugs. That was four days they just could not work at the office each year, with a pretty nasty decline in work enviroment quality in the lead up to each fumigation. Enforcing vacations causes the firms to deal with these issues ahead of time. Vacations have been well studied and, especially with knowledge workers, improve employee productivity (generally). But they also act as vaccinations towards unseen workplace issues and black-swan events.
  - Jtsummers 7y ago
    Tangent: This is related to the idea of JIT and low-inventory in Lean. By reducing inventory, it allows problems in production to be revealed so they can be addressed. Consider a simple 2 stage process. The first stage is down 50% of the time on average: A -> B When A is running, perhaps it can produce inventory faster than B can process it. So we run A at full-capacity and build up massive inventories in front of B. A happens to be down for a week straight, we exhaust that buffer and can't produce any more products. Because the inventory is usually allowed to go so high, the problems with A aren't addressed (they aren't pain points for the business). By the time A is down for a week and it becomes a pain point, it may be too late to save this business. In Lean, you pull inventory into B only when needed (realistically you'd have some lead time, of course). You maintain a modest buffer to accommodate that lead time. If A can't produce in time, instead of growing that buffer permanently, you address the issues with A. Identify the failing components in A and find a more reliable replacement. Maybe there's not enough people trained to operate A so you cross-train people. Maybe you buy a second system (cheaper, lower capacity?) that can do what A does to shift the burden, or you find another machine that can be conscripted and used to make the same things that's only rarely needed for its primary purpose. People who operate at 100% capacity and are your "heros" are similar to A. Everything seems great as long as they're there, but once they're gone (even for a day) they're noticed. By capping overtime (or eliminating it), by encouraging vacation time, you can find out who is critical to your business processes, and start shifting the burden (because it's an obvious pain point). Anecdote: We had a guy who wasn't officially IT, but had been doing IT for our build and other dev systems, it wasn't his main job. He was gone for a vacation or business trip for a week, on Monday the systems went down. Nothing was accomplished until he returned and fixed the problems because no one else knew how to do that work. He was a liability for the team and business. This happened on more than one occasion. Management loved him because they didn't recognize the causal relationship between his leaving and things being in a failing state (didn't happen everytime, he wasn't causing the failures, but his absence meant the failures were noticed and not addressed quickly). Control your "WIP" (work-in-progress or work-in-process) better, and you'll see work piling up in specific places. Just track it on a board or create a helpdesk ticket system that people have to interface with. It'll make all these pain points obvious so they can be addressed.

ianbicking 7y ago

> This is a textbook example of a bad system with a single failure point/bottleneck. One way to be considered "10x" is to be the only person with the know-how to keep a critical function afloat. I think often (and in this article) an organization has zero people with the know-how, and then someone struggles and figures things out, and now they have one person. That one person might be someone who has figured out how to deal with a difficult stack, or might be the person who has built that stack themselves – either way, they've done something valuable because they are handling something that is critical. The next step – spreading that knowledge, or making the knowledge more accessible, or making the system more usable – is important, but it's not wrong that the organization has ended up this position. It's part of a maturing process. And we shouldn't shit on the person who brought the organization from zero to one, just because they aren't the person fully equipped to bring the organization from one to many.

heymijo 7y ago
> And we shouldn't shit on the person who brought the organization from zero to one Very good point. There's an underlying principle here that I didn't say. Management is responsible for the system. Dead simple when written out, yet infrequently shown through managerial actions.