4 ms·

I agree with this up to a point. It’s been valuable to me as an IC, and I feel it’s a value I provide when the problem is so hard there isn’t a clear solution.

by 0xEFF 6y ago

I agree with this up to a point. It’s been valuable to me as an IC, and I feel it’s a value I provide when the problem is so hard there isn’t a clear solution. It’s nice to be able to say, “what do you think I should do?” as an IC, and nice to be able to analyze the problem if necessary as a manager. On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it.

RHSeeger 6y ago
> On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it. Those are the problems that it's the developer's job to figure out, in my opinion. If the manager can figure out the problem and solution but the developer cannot, then the dynamic is backwards (or the manager is actually a dev/tech lead, not a project/product manager). Or it's a totally different team structure than I'm used to.
- skohan 6y ago
  The reason I think it's good to have a product/project manager who can get down to this level if needed is that it increases the scope of possible solutions. With a strict division between tech and product, typically the solution space is bounded by the product requirements. But if you have a product manager who is able to operate on the level of implementation details, you can adapt the requirements in ways which are better on both a user side and implementation side. It shouldn't be the norm that a manager is operating on the level of implementation details, but it is good if they can understand them, because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue.
  - RHSeeger 6y ago
    > because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue. I think I understand the disconnect here. From my point of view it's the manager's job to figure out what problem the client is trying to solve. It's the developer's job to figure out what the possible solutions are, and recommend what they think is the best one. As a developer, I expect to be in the meetings with the clients long before the solutions are chosen.

by 0xEFF 6y ago

RHSeeger 6y ago

> On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it. Those are the problems that it's the developer's job to figure out, in my opinion. If the manager can figure out the problem and solution but the developer cannot, then the dynamic is backwards (or the manager is actually a dev/tech lead, not a project/product manager). Or it's a totally different team structure than I'm used to.

skohan 6y ago
The reason I think it's good to have a product/project manager who can get down to this level if needed is that it increases the scope of possible solutions. With a strict division between tech and product, typically the solution space is bounded by the product requirements. But if you have a product manager who is able to operate on the level of implementation details, you can adapt the requirements in ways which are better on both a user side and implementation side. It shouldn't be the norm that a manager is operating on the level of implementation details, but it is good if they can understand them, because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue.
- RHSeeger 6y ago
  > because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue. I think I understand the disconnect here. From my point of view it's the manager's job to figure out what problem the client is trying to solve. It's the developer's job to figure out what the possible solutions are, and recommend what they think is the best one. As a developer, I expect to be in the meetings with the clients long before the solutions are chosen.