The author should have jumped to the end immediately: follow the rats off the sinking ship. There's no winning on one of these projects, and if you find yourself in one, run away immediately. Knowing it was a doomed project and still accepting any sort of responsibility for it is dazzlingly naive; the ship will not make port, and you will all drown.
Story: “It would be career limiting..."
221–230 of 342 posts
Re: Story: “It would be career limiting..."
#222Earlier quoted context omitted.
I think the confusion is, if their job is to execute a $60M contract successfully, and you tell them that it’s going to require an extra 12 months, you’re almost literally telling them they aren’t doing their job. Because arguably they weren’t. Their job was to guide the project successfully, which they didn’t do. In a situation like that, you can recover, but it requires tact. The end of this story was that they lef…
You just tell them it will take 12 months more. Your the development team. Let them rewrite contracts or lose business. You do not get a bonus for contracts sold or kept. If necessary someone else will tell them they are not doing there job. Stick to your role.
I prefer to work for companies where this is the case. I get enough equity compensation that finding creative solution to deliver business value _is_ my job and thus am indirectly compensated with the success of the company (even if the overall success is still dependent on other areas of the company succeeding too).
Re: Story: “It would be career limiting..."
#223This is just not a great way to go about things and this is exactly the problem Agile is supposed be solving. When you deliver value incrementally, it becomes painfully obvious to everyone where the gaps are and what's at risk of not being delivered. It also puts the onus on the customer to TELL you what they want instead of you having to guess.
What a lot of young developers don't get is that you can't just solve every problem with deep analysis. Nobody gives a shit if you can find all the gaps in requirements because a day after you finish your analysis the requirements will change.
There's requirements you need to define early. Who is using the system, expected availability, the different levels of access and the entities involved. Performance requirements, data security/tenancy requirements and some idea of how many users will be using the system concurrently are extremely important to understand up front.
There are a ton of companies, particularly the ones that build custom software for public/private sector that are incredibly happy to have customers submit junk requirements and nickel and dime them on every single change request.
Re: Story: “It would be career limiting..."
#224For all the very justifiable shit "Agile" gets, this is what the original "Agile manifesto" agile was supposed to prevent, right? Deliver something early, so you (customer and devs both) learn more quickly what's missing and what will never actually be needed.
No post body was provided.
Re: Story: “It would be career limiting..."
#225Earlier quoted context omitted.
> The people around me were trying to hint that things aren't quite as clear cut as it seems, but it took a swift kick in my backside to reboot my worldview. Was your rebooted worldview that you had been factually incorrect (i.e. the senior dev actually did do his work) or was it that you were factually correct, but hierarchy and office culture demanded that everyone pretend you weren't?
I wanted to touch on that: one of the things you learn is that it’s better to be liked than right. We devs often fixate on whether we’re right and the other person is wrong. One specific incident comes to mind. I was working on Heroes of Newerth, a DotA clone. We achieved a bit of popularity in those days, and we reached around 50k concurrent users. So our servers tended to melt. One day, the servers went south, and…
HoN kicked ass back in the day. Thanks for the anecdote.
Re: Story: “It would be career limiting..."
#226Earlier quoted context omitted.
Your take is exactly what is wrong with the culture. An existential problem is not a problem because you didn't sell it correctly. You first need to "massage" the individuals to create some kind of coalition. A coalition willing to accept basic facts or responsibility. If a CEO were to be a fly on the wall in this room and overhear it all, they ought to fire every single manager in the room. Quite obviously they are…
Any anecdotes of a company that was successfully split up as you suggest?
No, but companies internally re-org all the time. And one of the big motivating factors is to re-align incentives so that internal responsibilities are split into discrete, measurable areas. It seems like re-org success has mixed results - often due to Goodhart's law problems.
Re: Story: “It would be career limiting..."
#227Earlier quoted context omitted.
It sounds like you were working on the project without enough contact with users to understand the value of the thing you were building. That doesn't sound like it's your fault!
The only people worse at knowing what the customer wants than management/sales is the customers themselves. It's really strange the first time you experience it.
Agree, never ask a user what they want
But you can't go wrong with talking to users to understand the problems they are dealing with
Re: Story: “It would be career limiting..."
#228Earlier quoted context omitted.
> concoct a plan to stage the product development and release such that it gets done and you don't cost a giant contract Yes, always showing up with a solution to problems that you've surfaced is a good idea and good for your career, ... BUT: isn't coming up with a solution to this problem literally the job of the management team that they presented to? If management hears "the thing you think will happen will absolu…
Suppose you were a junior engineer working with a senior engineer. They gave you a task, and you came to a similar conclusion: it was their job to do X, but they weren't doing it. Would you simply tell them they're not doing their job, or would you ask questions, talk in private, and try to dig in tactfully? When I was 22 or so, I did go around telling a certain senior engineer that they weren't doing their job. I st…
I was hired on as a full-stack developer to help a 2 person team (dev and designer) get a year-long project over the finish line. This was a November and the project was slated to go live on January 1. My first week was getting my PC configured, orientations, onboarding meetings with various external departments and perusing the project to get familiar.
Week 2 I was supposed to get assignments from the lead developer, but they were holding things close to their chest. I was given very, very menial things to do, or just told to continue to study the code. When we'd have project meetings and they'd ask how things were going overall, the lead developer would assure them we were on target - even in the face of ongoing bugs, missing features and incorrect functionality during QA testing. I'd offer the Lead my help, but they hadn't found the right task yet.
By the end of week 2, beginning of week 3, I was fairly confident the code I was researching was not lining up with the status reports in the project meetings. I started to speak up and ask questions to surface concerns in attempt to get something thrown my way. Again, the Lead Dev continued to assure management we were on target and that seemingly huge TODO items were trivial and would be handled in short order. I was kept on standby.
As things continued to progress in this direction, management finally bypassed the Lead and came directly to me to my feel for where were at. At this point I had only been with the company 3 to 4 weeks, but I had been a developer for 11 years. I told them in not so uncertain terms, "this project is doomed". The Lead dev is wildly overpromising deliverables, minimizing outstanding work and shielding the management team from truly understanding how behind he was. I honestly had no idea what his plan was to meet the deadline, but based on my estimates we were easily 4 to 6 months out. They were flabbergasted.
I continued to provide direct status reports at management's request. It felt like politics, but what else could I do? By the 2nd week in December, 6 weeks into my employment, the writing was on the wall. The project was canned, the Lead Dev was fired and I was wondering if I had still had a job myself as the only developer and no projects on the timeline.
By the end of the following year, I had been promoted to management overseeing a team of 3 and still developing myself. We rebuilt the project from scratch and implemented it exactly 1 year after its initial planned release.
I never wanted management and certainly never wanted to get anyone fired, but sometimes you have to put it all out there in black and white.
Re: Story: “It would be career limiting..."
#229Earlier quoted context omitted.
I wasn't in the room, and a lot of it depends on the vibe, facial expression, atmosphere, personalities, etc. But agreed - as read , my initial interpretation was not even remotely as one of the threat. Perhaps advice, or conclusion, or discussion. It depends hugely what else was said though - I doubt it was truly "and that was the end of that" in the sense that those words were the only ones spoken at that meeting,…
I'd put it in the category of "Will no one rid me of this meddlesome priest?" [0]. There is no way for somebody with authority to express a preference without it coming across as a request. The same words that from a trusted coworker would be advice to keep your head down become an implied threat when given from an executive. [0] https://en.wikipedia.org/wiki/Will_no_one_rid_me_of_this_tur...
Yeah, that's fair enough. I have been lucky to have had some managers in the past who were great mentors, very transparent, and have several times during my career actively coached me on what are "Career limiting moves". It is a phrase I have heard without it being sent or received as a threat. I have over-extrapolated and under-empathized though, and realize that in majority of situations for majority of involved folks, that would not be the case. (relatedly, I've also tried to internalize and implement the notion that I can no longer joke with any variation of "don't you know that's a fireable offence? :D" etc. )
Re: Story: “It would be career limiting..."
#230Earlier quoted context omitted.
For what it’s worth, I don’t think they could have done more. But the conclusion of the story is to heroically drive off a cliff, and say “it’s all I could do.” That’s where I disagree. If it were me, I would have privately (emphasis on private) worked my way up the chain of command, trying to alert more and more people that there was a serious problem brewing. The meeting in the story was obviously going to be a fai…
Your solution to a dumpster fire is to play a very risky game of hero, navigating an environment where at any point you could step on someone's toes, in hopes of salvaging a project for which there is absolutely no guarantee you'll get credit, let alone a sizeable reward, while the market is rife with opportunities. For a bunch of capitalists, not some noble goal. Forgive me, but playing hero (really just martyr) sou…
I have to agree. When the risk is greater than the reward, you have to ask if the project is worth sacrificing for. I find the answer is generally no. Even noble projects are set into situations where it isn't worth the sacrifice. From a purely pragmatic view, you can do better for the world by skipping the sacrifice and finding a similar noble project to keep working at.
It is a sort of prisoner's dilemma. Society is worse off because people tend to operate this way, not just in IT but all over. But we aren't going to fix society, so build a small kingdom in your life you can control and try to make things nice within it.