4 ms·

When I was managing a large, distributed team of mostly mediocre engineers (at a poor bigco), it was common to take the best case estimate (provided by a senior

When I was managing a large, distributed team of mostly mediocre engineers (at a poor bigco), it was common to take the best case estimate (provided by a senior engineer or architect), add 50-100% because due to lack of similarly experienced engineers responsible for day-to-day coding, add 25-30% for SQA, and add 50% for "business" delays (usually LOB heads who couldn't agree on features, or who asked for utterly stupid things that we'd have to explain away before we even got started ... like a web UI with a 52 column table meant to emulate the previous Excel-based "system"). The result was frustration all around because the senior engineers knew our estimates were crazy high compared to what they'd be able to do independently, our business stakeholders were mad because of the cost, and our CIO couldn't understand why it seemed literally nothing was doable in less than several thousand person hours. Good times. But when you 1) don't have an constructive relationship between CIO/CTO and business leaders, and 2) offshore everything not to follow-the-sun but purely to save money (and then pay bottom of the barrel even in lower cost regions -- that company still only pays engineers 10-12 lakh in south India), you're going to get an inefficient org creating crap quality software.

PragmaticPulp 6y ago
It sounds like you had distributed decision making authority but concentrated accountability for the outcome. Worst-case scenario. > the senior engineers knew our estimates were crazy high compared to what they'd be able to do independently Interestingly, I worked at a company where teams of engineers were given wide latitude to design, implement, and deliver their features in isolation. The theory was that engineers could be more productive if they were left alone to make the decisions. I'd say it worked about 1 in 4 times. The other 3 out of 4 times, engineers created their own labyrinth of over-engineering, spent too much time building things as reusable frameworks instead of simply getting the job done, and over complicating the system with unnecessary "Wouldn't be cool if..." type features.
- tracker1 6y ago
  I find my sense of laziness keeps me from going too far down a rabbit hole most of the time.
user5994461 6y ago
When I was in a large organization, the upper management roadmap was based on quarters and year. Like Q1 2020 Q2 2020. That's a very large granularity of 3 months. This had the benefits of ignoring the usual variations of software planning. Any development task could take 1 week or 4 weeks (if it goes well or not). This stops being an issue when the planning is quarterly because few weeks of jitter doesn't matter. The question is then, do we have time to do this task next quarter, as well as the other 3 tasks we scheduled there? otherwise we'll plan it for the quarter afterward.

PragmaticPulp 6y ago

It sounds like you had distributed decision making authority but concentrated accountability for the outcome. Worst-case scenario. > the senior engineers knew our estimates were crazy high compared to what they'd be able to do independently Interestingly, I worked at a company where teams of engineers were given wide latitude to design, implement, and deliver their features in isolation. The theory was that engineers could be more productive if they were left alone to make the decisions. I'd say it worked about 1 in 4 times. The other 3 out of 4 times, engineers created their own labyrinth of over-engineering, spent too much time building things as reusable frameworks instead of simply getting the job done, and over complicating the system with unnecessary "Wouldn't be cool if..." type features.

tracker1 6y ago
I find my sense of laziness keeps me from going too far down a rabbit hole most of the time.

user5994461 6y ago

When I was in a large organization, the upper management roadmap was based on quarters and year. Like Q1 2020 Q2 2020. That's a very large granularity of 3 months. This had the benefits of ignoring the usual variations of software planning. Any development task could take 1 week or 4 weeks (if it goes well or not). This stops being an issue when the planning is quarterly because few weeks of jitter doesn't matter. The question is then, do we have time to do this task next quarter, as well as the other 3 tasks we scheduled there? otherwise we'll plan it for the quarter afterward.