4 ms·

I would suggest the core issue was that you did not have the freedom to go get the important work down and be responsible for it. Too often work is subdivided s

I would suggest the core issue was that you did not have the freedom to go get the important work down and be responsible for it. Too often work is subdivided so no one actually owns anything important -- because the bits are too small.

JimboOmega 13y ago
That's a very interesting observation. I've always been taught that breaking things down as small as possible is good - easier to estimate, easier to understand, easier to track. You don't want to give a developer a week long task - that turns into two weeks, for instance. There just isn't the visibility. I'd agree, there's a huge issue of none of the work feeling important, and an issue of Developers having no real power in the process (other than to unilaterally dictate how long we thought things would cost, strangely enough). But is it a result of subdividing tasks too small? I'm not sure; it's an interesting concept to explore.
- bdehaaff 13y ago
  I think you need to do both and that's why building great products/software is hard. You need to see the big picture yet deliver against it in bite-sized chunks. Good PMs and Engs are capable of doing both at the same time. That's they key. Give folks responsibility for owning big ideas and allow them to get their in an agile, incremental way.
- derefr 13y ago
  I find that the best thing that's ever happened to my task-delegation is Service-Oriented Architecture. You break a project down into a tree of tasks--then find the nodes are the most weakly coupled, and call each such subtree a "service." Each service gets assigned to one developer to build and own. Each developer then publishes a protocol/API for their service, and other developers--instead of needing to talk to them to consume their service--just consume its API. This means each service can be developed, tested, mocked, gateway-ed, and made Highly Available in isolation from synchronous/blocking work by other developers.

JimboOmega 13y ago

That's a very interesting observation. I've always been taught that breaking things down as small as possible is good - easier to estimate, easier to understand, easier to track. You don't want to give a developer a week long task - that turns into two weeks, for instance. There just isn't the visibility. I'd agree, there's a huge issue of none of the work feeling important, and an issue of Developers having no real power in the process (other than to unilaterally dictate how long we thought things would cost, strangely enough). But is it a result of subdividing tasks too small? I'm not sure; it's an interesting concept to explore.

bdehaaff 13y ago
I think you need to do both and that's why building great products/software is hard. You need to see the big picture yet deliver against it in bite-sized chunks. Good PMs and Engs are capable of doing both at the same time. That's they key. Give folks responsibility for owning big ideas and allow them to get their in an agile, incremental way.
derefr 13y ago
I find that the best thing that's ever happened to my task-delegation is Service-Oriented Architecture. You break a project down into a tree of tasks--then find the nodes are the most weakly coupled, and call each such subtree a "service." Each service gets assigned to one developer to build and own. Each developer then publishes a protocol/API for their service, and other developers--instead of needing to talk to them to consume their service--just consume its API. This means each service can be developed, tested, mocked, gateway-ed, and made Highly Available in isolation from synchronous/blocking work by other developers.