6 ms·

This post actually doesn't resonate with me at all (and I've always respected Ben). I feel like I'm constantly solving a multitude of problems and actively loo

This post actually doesn't resonate with me at all (and I've always respected Ben). I feel like I'm constantly solving a multitude of problems and actively look for opportunities where I can introduce new tech that hits on multiple disparate streams at once (I have neither the bandwidth as an org or the personal time to operate in a different manner), typically coupled with other new tech; even that is orthogonal to running dozens of work streams concurrently, which isn't exactly outside the gist of the article. Even getting a sufficiently complex product/program off the ground necessitates solving countless problems at once, otherwise the architecture has no chance of supporting growth. Perhaps I'm at the stage where advice like this doesn't apply, but looking back over my career, I can't really identify a point at which it did. To change my phrasing -- If someone manages a large team, let's assume that they are responsible for all that the team does and can be viewed as a single entity, synonymous with a single engineer working at high bandwidth. That entity is absolutely not solving singular problems at once. Individual engineers within that team are not working in isolation from one another and they all have interconnect impact unless their delivery is absolutely rote. In order to move at a speed necessary for on-time results on complex problems, the advice proposed in the article must be violated.

shove 4y ago
I think the advice is fine if applied to one context at a time. You can paint one room in your house and replace the carpet in another "simultaneously" without too much risk, but doing both at once in the same room is asking for disaster.
- lightbendover 4y ago
  It really depends on the congruency between orthogonal tasks. Painting walls and laying carpet are diametrically opposed and are mutually exclusive. There are other mixed contexts that don't attribute this trait, e.g. I can make updates to multiple disparate ad products in tandem which independently have impact on a central ad server while also introducing new caches to the ad server without exceeding the risk threshold of making such changes at once. This kind of thing happens every day.
dcow 4y ago
I think the post is discussing building software/product not managing teams of people. Also a manager is not synonymous with a high bandwidth engineer.
- lightbendover 4y ago
  How is a manager not synonymous with a high bandwidth engineer? If I told an engineer to execute on an immensely huge and complex problem (e.g. go build a new secondary market with tendrils into everything else the company is doing) by themselves and they did, how is that different than telling a senior manager to do the same? Really depends on the lens you're looking through.
  - dcow 4y ago
    Because a manager manages. Having weekly 1:1s with 8 direct reports is not “high bandwidth”. That’s normal bandwidth. 1 engineer doing all that on their own is incredibly high bandwidth. Also, a high bandwidth engineer building all that is way more valuable than a manager building a team to do it, in terms of bottom line. Sure managers are important and good ones produce results. But that’s not equivalent to a 10x engineer. That’s just the normal expectation for a manager.
kybernetikos 4y ago
Particularly on large architectural changes - if they don't make multiple different things easier, there's a good chance they're not worth the effort.
- collyw 4y ago
  I think that would depend a lot on context (like everything).
gregmac 4y ago
I have the same reaction. Sometimes there's multiple problems that can all be solved at once, and it is like a force multiplier. Often it's from what you could call "outside the box" thinking, where you maybe take a totally different approach. For example, there's a bug in the login system, again. Ok, we could probably fix it, but this is an old system built by outside contractors (aka "built cheaply, but expensive to maintain"). It's not the first bug, and won't be the last. There's some technical debt in the way it stores unsalted sha1 passwords, password resets work in a way that allows an attacker to effectively lock out accounts and do a DoS. Looking forward we have customers asking about MFA and SSO support that this system just can't do. "Solve only one problem" philosophy says to just fix the bug. This is a case where replacing the system (whether buy or build) might make more sense. You have to be pragmatic about this of course, because if you can't live with the bug for however long it takes to replace the system, it isn't going to fly. I'd still advocate some constraint, though: iteration 1 should fix the bug(s) and underlying tech debt, but shouldn't be adding anything new. Some of the most productive work I do is this style because it's often only a bit more effort. I used "login system" only as an easy to understand example, it's often more subtle, along the lines of: refactor a class so it has unit tests and fixes 3 other related but low priority bugs at the same time, instead of just patching. Instead of a day, it takes a week, but more value was delivered (other bugs fixed), there's significantly lower chances of bugs in the future (as future dev work happens), and we can reduce or eliminate manual QA on that component. The extra 4 days have saved dozens we'd spend over the next year if we dogmatically stick to "one thing at a time".
- hbrn 4y ago
  Doing things incrementally almost always feels more expensive. And sometimes it is. But it is always a net positive in the long run. When you're starting those "replace X system" projects, what you're not anticipating is that half of those projects fail: they're either end up taking way longer than planned, or they don't get finished at all because they miss some critical requirements. The bigger the project, the more risky it is. Your login system has two problems: 1. It has a specific bug 2. It has tech debt The issue is that you're using current bugs as a justification to remove tech debt. Because, let me guess, you want to refactor, but you can't sell refactoring to the management. Here's how management might look at your arguments: > password resets work in a way that allows an attacker to effectively lock out accounts and do a DoS Did it actually happen? I worked at a SaaS startup that had over 50K users, it had the same potential problem. It never happened. Side note: some security standards actually require this DoS vector to exist. > Looking forward we have customers asking And how far in the future are we looking? It might be years before it becomes a real problem. You might be absolutely right in your desire replace the login system. Or you might be a perfectionist that's eager to solve problems that don't matter. The great thing about incremental process is that for a relatively small cost those risks go away.
Isamu 4y ago
So more like one fix at a time? I agree with that. And that one fix is a big win if it addresses multiple problems. We should look for commonalities among problems.

shove 4y ago

I think the advice is fine if applied to one context at a time. You can paint one room in your house and replace the carpet in another "simultaneously" without too much risk, but doing both at once in the same room is asking for disaster.

lightbendover 4y ago
It really depends on the congruency between orthogonal tasks. Painting walls and laying carpet are diametrically opposed and are mutually exclusive. There are other mixed contexts that don't attribute this trait, e.g. I can make updates to multiple disparate ad products in tandem which independently have impact on a central ad server while also introducing new caches to the ad server without exceeding the risk threshold of making such changes at once. This kind of thing happens every day.

dcow 4y ago

I think the post is discussing building software/product not managing teams of people. Also a manager is not synonymous with a high bandwidth engineer.

lightbendover 4y ago
How is a manager not synonymous with a high bandwidth engineer? If I told an engineer to execute on an immensely huge and complex problem (e.g. go build a new secondary market with tendrils into everything else the company is doing) by themselves and they did, how is that different than telling a senior manager to do the same? Really depends on the lens you're looking through.
- dcow 4y ago
  Because a manager manages. Having weekly 1:1s with 8 direct reports is not “high bandwidth”. That’s normal bandwidth. 1 engineer doing all that on their own is incredibly high bandwidth. Also, a high bandwidth engineer building all that is way more valuable than a manager building a team to do it, in terms of bottom line. Sure managers are important and good ones produce results. But that’s not equivalent to a 10x engineer. That’s just the normal expectation for a manager.

kybernetikos 4y ago

Particularly on large architectural changes - if they don't make multiple different things easier, there's a good chance they're not worth the effort.

collyw 4y ago
I think that would depend a lot on context (like everything).

gregmac 4y ago

I have the same reaction. Sometimes there's multiple problems that can all be solved at once, and it is like a force multiplier. Often it's from what you could call "outside the box" thinking, where you maybe take a totally different approach. For example, there's a bug in the login system, again. Ok, we could probably fix it, but this is an old system built by outside contractors (aka "built cheaply, but expensive to maintain"). It's not the first bug, and won't be the last. There's some technical debt in the way it stores unsalted sha1 passwords, password resets work in a way that allows an attacker to effectively lock out accounts and do a DoS. Looking forward we have customers asking about MFA and SSO support that this system just can't do. "Solve only one problem" philosophy says to just fix the bug. This is a case where replacing the system (whether buy or build) might make more sense. You have to be pragmatic about this of course, because if you can't live with the bug for however long it takes to replace the system, it isn't going to fly. I'd still advocate some constraint, though: iteration 1 should fix the bug(s) and underlying tech debt, but shouldn't be adding anything new. Some of the most productive work I do is this style because it's often only a bit more effort. I used "login system" only as an easy to understand example, it's often more subtle, along the lines of: refactor a class so it has unit tests and fixes 3 other related but low priority bugs at the same time, instead of just patching. Instead of a day, it takes a week, but more value was delivered (other bugs fixed), there's significantly lower chances of bugs in the future (as future dev work happens), and we can reduce or eliminate manual QA on that component. The extra 4 days have saved dozens we'd spend over the next year if we dogmatically stick to "one thing at a time".

hbrn 4y ago
Doing things incrementally almost always feels more expensive. And sometimes it is. But it is always a net positive in the long run. When you're starting those "replace X system" projects, what you're not anticipating is that half of those projects fail: they're either end up taking way longer than planned, or they don't get finished at all because they miss some critical requirements. The bigger the project, the more risky it is. Your login system has two problems: 1. It has a specific bug 2. It has tech debt The issue is that you're using current bugs as a justification to remove tech debt. Because, let me guess, you want to refactor, but you can't sell refactoring to the management. Here's how management might look at your arguments: > password resets work in a way that allows an attacker to effectively lock out accounts and do a DoS Did it actually happen? I worked at a SaaS startup that had over 50K users, it had the same potential problem. It never happened. Side note: some security standards actually require this DoS vector to exist. > Looking forward we have customers asking And how far in the future are we looking? It might be years before it becomes a real problem. You might be absolutely right in your desire replace the login system. Or you might be a perfectionist that's eager to solve problems that don't matter. The great thing about incremental process is that for a relatively small cost those risks go away.

Isamu 4y ago

So more like one fix at a time? I agree with that. And that one fix is a big win if it addresses multiple problems. We should look for commonalities among problems.