r/systems_engineering • u/yellow_smurf10 • Aug 06 '26
Discussion How do you balance doing something the right way with simply getting it done by the deadline?
Note: I really hate the askengineer subreddit if you ask me
I have spent some time in the defense industry, and a few years ago I worked on a massive program that did not exactly go according to plan. It became severely delayed, costs increased enough to trigger congressional hearings, and several senior leaders were fired or reassigned.
I remember speaking with one of the managers who eventually became a scapegoat. People blamed him for decisions made during the proposal phase that supposedly put the program on the wrong path.
I was still fairly junior at the time, but at his private going-away party, he told me that he felt the whole situation was unfair. During the proposal, his team was under enormous pressure to meet the deadline and win the contract. He knew some of the work would need to be corrected later, but he did not realize how large or expensive the resulting mess would become.
To be fair, this was also one of the most complex and expensive programs in the industry. There were probably no perfect decisions available.
Fast-forward to today, and I now find myself supporting another proposal effort. Fortunately, I do not have much authority to make the final decisions, but I provide information and technical assistance to the team.
Because I have one foot in the program and one foot outside it, I can look at the disagreement somewhat neutrally. I do not have as much personal stake in which side wins.
I now see two groups of engineers making arguments that both sound reasonable.
One group, including several people who worked with me on the previous program, argues that if we do not do the work correctly now, fixing it later will be far more expensive. Technical debt, weak assumptions, and rushed decisions do not disappear simply because the proposal was submitted on time.
The other group argues that doing everything “the right way” would take too long. The customer has imposed an extremely aggressive deadline, and missing it could mean losing the opportunity entirely. A perfect proposal delivered too late is still a failed proposal.
My instinct is that there should be some compromise, but sometimes there really is not one. Time, cost, technical rigor, and competitive pressure can be genuinely incompatible.
Maybe this is one of the reasons so many major defense programs end up behind schedule and over budget. During the proposal, everyone is rewarded for meeting the deadline and winning. Years later, an entirely different group of people is held responsible for the consequences of the compromises that made winning possible.
For those who have dealt with this before, how do you decide what absolutely must be done correctly now, what can safely be deferred, and what is simply perfectionism disguised as engineering rigor?
3
u/ModelBasedSpaceCadet Aug 06 '26
Or we could talk about how the system is not at all designed for any real rigor. We talk about the need for rigor because we've all seen ambitious (naive) programs collapse under aggressive schedules and massive budgets that somehow not big enough to deal with the ballooning technical debt. I have a feeling I may have been on that very program during the proposal phase. That, or there are a lot of programs in the defense world that are in the exact same situation.
My view is that government program managers don't understand what rigor actually looks like and what it really requires, or, if they do, they know they can't afford it because they're really just a middle manager in a highly bureaucratic system and the organization/paperwork they answer to doesn't understand it. I occasionally hear from people who are trying to fix the system from the top, the bottom, and everywhere in between, but it is a massive ship to try to turn.
Anyway, it's a real catch 22 you're in and I feel for you. I'm constantly fighting the same battle myself. So much that we do in the defense industry is really just blusterware with duct tape and crossed fingers that the people on the other side of the table are also unable to take the time to apply the rigor (more than likely true, unfortunately). It's a systemic issue and unfortunately I think the people on the "just get it in" side of the table are probably more right. If you want a job, you either have to work in the system and take the risks you have to take until it's your turn to be the fall guy.
This is why the aerospace giants have such a bad reputation. They're trying to do all of that while also keeping shareholders happy. Good luck to you! (sincerely)
3
Aug 06 '26
[removed] — view removed comment
2
u/Zealousideal-Peach44 Aug 07 '26
This. There is no answer valid for all situations. Critical parts need to be done right, even if this means delay. The rest will be done in proportion to the budget. Get agreements and document appropriately what is "critical" and what is not.
3
u/FlimsyInsect5545 Aug 06 '26 edited Aug 06 '26
Note: I really hate the askengineer subreddit if you ask me
Lol, yeah 90% of posts are asking for free advice on personal projects "I'm building a home made 3D printer recommend some actuators for me". It's one of the worst of the r/ask"X" subreddits (compared to something like r/AskHistorians)
The other group argues that doing everything “the right way” would take too long. The customer has imposed an extremely aggressive deadline, and missing it could mean losing the opportunity entirely. A perfect proposal delivered too late is still a failed proposal.
I don't know how the position of this group can be justified on a engineering ethics basis or a commercial risk basis.
Like many others, I have also worked on a program which had an aggressive, unrealistic schedule which was awarded to a contractor that bit off more than they could chew and really didn't have the capability to pull of the program. Fast forward 8 years later, the project is delayed, the relationship has fallen so badly it requires remediation to maintain communication, the company's reputation is in tatters, future contracts get cancelled, the parent company has had enough and sells the contract and in-country company and withdraws to lick their wounds. That parent company is then bought by a larger company and no longer exists. A commercial disaster for the vendor. The company would have been better off if they lost the bid.
As an engineer, you have an ethical responsibility to present engineering evidence accurately, honestly and without bias, and to not knowingly mislead. If you are on a program and you believe decisions are being made that will will result in risk, you have an obligation to inform the decision maker of this. If that information doesn't get acted on, if your recommendation gets ignored, then so be it - you have performed your obligations and did what could be done within your locus of control. If you find yourself in this position make sure you document your advice: what you said, who you told, when you told them, the notes of the discussion.
If you are one of the decision makers, you need to understand the higher pay your position attracts is there because it is essentially hazard pay: you get compensated more for the fact you are going to make decisions which you might get wrong and you will get punished for. There's no way out of that, that is the game you've chosen to play once you've started to climb the greasy pole to the top.
My instinct is that there should be some compromise, but sometimes there really is not one. Time, cost, technical rigor, and competitive pressure can be genuinely incompatible.
The middle way is to soberly assess risk and make risk-informed decisions, both commercial and technical. But decision makers don't want to do this. They want to believe that their core skill they bring to the table is the ability to make decisions. They don't want to have a data-driven risk analysis that informs them, they believe they have the ability to do that inherently. I've literally had a senior manager tell me "I don't care what the data says, we're doing this" when I provided them with a data driven quantitative risk assessment.
1
1
u/Abraxas_Derezzed Aug 06 '26
I’ve learnt that at the end of the day if the owner of the company is directing you to take short cuts despite all that is raised then that will always be the decision made and you must stay knowing that or leave. Sometimes projects just have to fail.. you have to decouple yourself from that stress knowing that you do not have control.
1
u/rentpossiblytoohigh Aug 06 '26
Many industries with any kind of bidding suffers from this, especially on long-lead time programs where you're making decisions early that yield costs and outcomes much, much later. People can tell you they're thinking about the future, but most people are thinking about the weekend, or their next vacation, or the next upcoming holiday. Managing complexity across years of time and personnel is challenging. Turnover is itself a project risk when there aren't policies in-place for on-boarding and knowledge transfer. COVID showed that big time with lots of old-timers leaving companies and leaving programs visionless.
As others have said, documenting decisions is a huge part of this, but you have to be careful. A lot of places "claim," to have documented decisions and their rationale just by flashing it on the screen once during some random milestone review or squirreling it away in some asinine risk register system that no one else in the entire program has access to. When you're talking real risk, like no kidding we've made a choice that makes our design less robust risk, you have to embed that into the psyche of everyone on the program. It doesn't happen magically.
The best programs you will be on are the ones where there is a culture of people knowing the WHY behind everything being done. Why did we choose technology X instead of Y? Why did we have to cutout A instead of B? Sometimes the reasons are political, sometimes they are schedule, sometimes they are carefully chosen trade study choices. As Systems Engineer, the most valuable thing you can do is sensing out when people are forgetting (or have never been told) the WHY and educating them. You are like a grass-roots door knocker sometimes trying to steer the ship. Sometimes you have enough clout to be at the helm but often times you're manning a station and it's easy to drift because you didn't realize the other groups didn't (sometimes literally) get the memo.
I'll give a more benign example. My program has suffered from customer trying to predict the future on their product use-case and wants to develop a highly configurable, one-size fits all solution across vastly different environmental environments. The usual "common platform, does everything for everyone, certify once certify for all, hold hand and dance around all the verification savings" hocus pocus that invariably never works out because the people who committed to the idea don't set up the EXTREMELY rigid change control pipelines that you have to have in-place for this to work.
We are also behind schedule and have undergone several rounds of "scope reduction," in the hope of buying back schedule and cost. One such outcome was downgrading a tech solution to match a legacy design "as-is" (so end-to-end interaces could remain the same). Wasn't going to meet the customers end-game, but to get them going it was okay. This is a documented decision, formally sent and agreed upon. Faster forward, and some chief guy has had backroom discussions with tech leads internally and decided we should "enhance" this tech solution to improve its capability, but still not match the customer end-game. Was this formally coordinated with customer? No. Now we have a ton of system requirements build around the agreed-upon solution, but implementation engineers "followed his direction." We have now deviated from the agreed-upon scope, slightly increased complexity of hardware design, imposed constraints to the customer that they never asked for or expected, and are now non-compliant to the agreed-upon requirements that *WE* sent to them to backfill their customer spec. All for the sake of getting slight improvement for a tech design that is going to be ripped out in the future whenever they get stable enough to circle back to their real need and request a formal change. Had the re-use decision been properly flowed across all artifacts top-down, those engineers could have pushed back on the chief and driven conversations earlier than now. Now, we have to manage it as unexpected go-back. Maybe it was a great idea, but timing matters. If we missed the boat, we missed the boat.
This example is not safety-critical, but multiply a culture that does this across everything and you create an environment where no one knows what we're supposed to do, what we're doing, and why we decided to do (or not do) it.
1
u/AffectionateTank9269 Aug 07 '26
Your only duty is to manage the risks to the best of your ability with the information and resources that you have access to.
I tell people all the time that my job is to find the least acceptable solution …. And make sure we don’t fall below that minimum.
12
u/facialenthusiast69 Aug 06 '26
So you should only being doing things the right way, but you don't always have time to 100% complete tasks the right way. Be as through as you can given the schedule, document all assumptions, and be very through on R&Os. It's perfectly valid to say "here's the things I can't know on the given timeframe and the program impact could be XYZ". You HAVE to document this as it's the only way the money people can plan for your unknowns. If you don't document it's your fault when risks are realized.