4 ms·

A few years ago I was brought in lead a team in a division of a public company. Our mandate was to replace a major component of an enterprise system that you c

A few years ago I was brought in lead a team in a division of a public company. Our mandate was to replace a major component of an enterprise system that you couldn't quite call legacy because they'd never actually gotten around to replacing the real legacy system with it. My initial proposal was to build it incrementally: tackle the obviously critical functionality to get something working and ship it, then define and implement additional features on an ongoing basis. I had hoped this would fly, since the company talked a big game about being agile. But no dice. We had to have a complete plan for all the features currently supported (some of them of dubious value, many of them incomplete and inconsistent in specification), and it had to come with a specific timetable. Under protest, the team and I worked hard to produce high-level estimates, and ended up basically guessing that the thing would take six months. No dice, it had to be delivered in three. I made a suggestion along the lines of the strategy suggested in the article -- we could identify a subset of features that the team would be comfortable could be delivered within the deadline. It would probably be stronger, I argued, since it wasn't clear that all the added weight added much value. No dice: everything was priority one. I pointed out something like, "you can't fight the laws of physics". I apparently gave the impression that we'd get it done anyway, though my memory of the conversation was that I was sternly disagreeable. Our team goes ahead and starts implementing items from a value-prioritized backlog. Fast forward three months, and we have a working system that supports the most important use-cases. We considered it past ready to ship, knowing we'd need to keep iterating. The response from management, predictably, was frustration at the missing features, despite the advance warnings. Management goes into "high-pressure" mode, and for the next three months I do my best to keep the team insulated. After more or less six months of total development time, we finally replace the prior component. All the users agree that it has far fewer bugs. I and many of my team members grumble that it has far too many, on account of the fact that we weren't given the chance to ship the minimum viable product when it was ready. I'm not really sure what the moral of the story is.

tmikaeld 7y ago
"I'm not really sure what the moral of the story is. " To me, it's - never waiver from your experience/gut estimates and a no is a no.
- sjogress 7y ago
  Incredibly hard to do when you have the full weight of management on your shoulders. Especially if they back you into a corner in a meeting where you are the only technologist facing a whole hierarchy of management types.
  - marapuru 7y ago
    I completely agree on how hard this is. However, I've built the best relationships with managers where I kept my foot down once in a while. I guess they like the struggle and the honesty in the end.
  - tmikaeld 7y ago
    I've run a business longer than a decade so I know how hard it is and I've burned out several times over. But I just don't give up and a no has certainly become a NO.
  - nautilus12 7y ago
    I feel like this is why lead technologists turn over so often. Because they say the harsh reality that no one wants to hear, and no one cares that they are right, they just care that they are not delivering to their expectations. Maybe the issue is the expectation.
serpix 7y ago
Did it result in burnouts? I was part of such a mess and two out of four team members got burnout, myself one of them. It did teach me to get the fuck out early the next time I feel the same emotions of inadequacy and pressure on me. And in the very next project after a very sudden ramp up of backlog and increased pressure I looked in the mirror and got out, cleanly and without burnout or bad feelings.
- papito 7y ago
  Helps to be on one death march project in your life to know what it looks like. Don't do more than one. It can damage you, give you long-term health problems, lead to substance abuse, etc. When I see a thing like that 10 miles out, I go "Nope, nah-ah - I am out of here".
koonsolo 7y ago
The moral of the story is that hard-to-please idiot customers/employers don't want to pay more than realistic, normal-to-please customers/employers. So there is absolutely no reason why anyone would work for the first when the second is available. And believe me, the second is out there. I've seen plenty of (experienced) businesses and individuals that refuse to work for toxic clients, because there is plenty of other work that pays exactly the same but without all the shit. P.S.: According to your story, you sound like a good manager :).
brianmcc 7y ago
Thanks for sharing; to me it sounds like a successful project which management/customer made feel like an unsuccessful one due to unreasonable demands. Way to ruin morale! Well done for at least attempting to introduce some flexibility. One lesson for the future might be: how to more forcefully stand up for what you believe is the right way to go - but of course this is easier said than done!
friendlybus 7y ago
A lot of managers think it's their job to decide what the quantity of things is. Like in an assembly line, we need 30 turbo encabulators at X price and it's your job to make it. Software has an infinite quantity of numbers to use as tools to build an end product. A programmer's job is to decide what general ideas end up as what specific quantities. A manager cannot decide this, lest he do the programming job himself. Money is a great tool for measuring quantities of material goods, or the value of material properties. But electricity provides infinite quantities, exchanging money for programmer time is closer to exchanging two forms of currency (binary numbers and dollars) for one another. Code is a constantly transforming river of numbers that we make a draw-down into a bucket that we call an end product. That is not a quantity of material good like iron ore, at all. The factory model simply doesn't work and producing code should be treated closer to the stock market than the factory model. Early access/kickstarter/pay-over-time business models in video games represent an example of the constant transformation model working successfully. Business apps should be built by crazy people who will build them anyway and money holders should bet & invest in them like stocks that raise and lower value over time, rather than as promised end goods.

tmikaeld 7y ago

"I'm not really sure what the moral of the story is. " To me, it's - never waiver from your experience/gut estimates and a no is a no.

sjogress 7y ago
Incredibly hard to do when you have the full weight of management on your shoulders. Especially if they back you into a corner in a meeting where you are the only technologist facing a whole hierarchy of management types.
- marapuru 7y ago
  I completely agree on how hard this is. However, I've built the best relationships with managers where I kept my foot down once in a while. I guess they like the struggle and the honesty in the end.
- tmikaeld 7y ago
  I've run a business longer than a decade so I know how hard it is and I've burned out several times over. But I just don't give up and a no has certainly become a NO.
- nautilus12 7y ago
  I feel like this is why lead technologists turn over so often. Because they say the harsh reality that no one wants to hear, and no one cares that they are right, they just care that they are not delivering to their expectations. Maybe the issue is the expectation.

serpix 7y ago

Did it result in burnouts? I was part of such a mess and two out of four team members got burnout, myself one of them. It did teach me to get the fuck out early the next time I feel the same emotions of inadequacy and pressure on me. And in the very next project after a very sudden ramp up of backlog and increased pressure I looked in the mirror and got out, cleanly and without burnout or bad feelings.

papito 7y ago
Helps to be on one death march project in your life to know what it looks like. Don't do more than one. It can damage you, give you long-term health problems, lead to substance abuse, etc. When I see a thing like that 10 miles out, I go "Nope, nah-ah - I am out of here".

koonsolo 7y ago

The moral of the story is that hard-to-please idiot customers/employers don't want to pay more than realistic, normal-to-please customers/employers. So there is absolutely no reason why anyone would work for the first when the second is available. And believe me, the second is out there. I've seen plenty of (experienced) businesses and individuals that refuse to work for toxic clients, because there is plenty of other work that pays exactly the same but without all the shit. P.S.: According to your story, you sound like a good manager :).

brianmcc 7y ago

Thanks for sharing; to me it sounds like a successful project which management/customer made feel like an unsuccessful one due to unreasonable demands. Way to ruin morale! Well done for at least attempting to introduce some flexibility. One lesson for the future might be: how to more forcefully stand up for what you believe is the right way to go - but of course this is easier said than done!

friendlybus 7y ago

A lot of managers think it's their job to decide what the quantity of things is. Like in an assembly line, we need 30 turbo encabulators at X price and it's your job to make it. Software has an infinite quantity of numbers to use as tools to build an end product. A programmer's job is to decide what general ideas end up as what specific quantities. A manager cannot decide this, lest he do the programming job himself. Money is a great tool for measuring quantities of material goods, or the value of material properties. But electricity provides infinite quantities, exchanging money for programmer time is closer to exchanging two forms of currency (binary numbers and dollars) for one another. Code is a constantly transforming river of numbers that we make a draw-down into a bucket that we call an end product. That is not a quantity of material good like iron ore, at all. The factory model simply doesn't work and producing code should be treated closer to the stock market than the factory model. Early access/kickstarter/pay-over-time business models in video games represent an example of the constant transformation model working successfully. Business apps should be built by crazy people who will build them anyway and money holders should bet & invest in them like stocks that raise and lower value over time, rather than as promised end goods.