Acting in the face of unrealistic expectations

How do you act professionally in situations like this as a developer?

You point out how it could benefit the company to do it another way. Preferably, as with all discussions, when some time has passed, the current deadline is over and there is no specific promise already made. Also, don't stay abstract, make sure you suggest actionable next steps.

Very likely, you company is run by business and sales people, who only prioritise "getting the client" and don't care about "delivering a good product". That is one way to run a business, but not the only way.

If the company you work for is unwilling to change because that is their business model, you can always change which company you work for.

You don't have to work for clowns. There are plenty of good companies out there where structured planning exists and managers are actually competent.

Capitalism kinda depends on you not silently suffering through the bad companies, but flocking towards the good ones instead, so they will have a great workforce, produce great products and mop the floor with the competition of sleazy salespeople and leftover cowboy coders.

Figure out how you have to conduct interviews to find the good companies and then apply and see which one you like best. Good companies do not pressure you into anything untowards, give notice as contractually neccessary, wish everyone good luck, leave on a positive note.

But don't expect a company run by businesspeople to change because "one of the developers doesn't like how we conduct business". Not gonna happen.

1. Understand that there are limitations, and gently push back when you need to in a way that communicates these limitations. A former boss shared a notion with me - "Good (quality), fast (time to completion), or cheap? Pick two! If you want good and fast, it's not going to be cheap. If you want good and cheap, it's not going to be fast. If you want cheap and fast, it's not going to be good." These constraints apply to ALL real-world problems, and not just software development.


2. SURRENDER to the constraints above, and realize that if your management is in some fantasy that ignores those constraints, it's out of your control. You're striving for perfection and people-pleasing. Let those go until you're the boss. In the mean time, collect your pay, do what you can, and forgive yourself for what you cannot do.


3. Boundaries. You can't change the system, but you can change yourself. Work your daily eight hours and find some commitment that you need to leave work for each day at the same time, even if that commitment is to kick your feet up on your couch and watch Netflix. Take your vacations, water your plants, go to the gym, spend time with your family, and eat well. Work doesn't love you back. Resist pressure to working overtime and weekends in a work environment that is broken, because it will only lead to burnout. When you take time off, announce that the reason for time off is "personal matters", and decline giving management more information by which to convince you that working more hours is somehow always (as far as management is concerned) more important than your personal time.

Split your development team up into two parts and apply different processes to each one.

Team one concentrates on project work that will take longer than a few weeks to complete. These are the projects that are professionally planned, resourced and go through a thorough test and release cycle according to the usual project planning process.

Team two is fast-track. They take on those "quick win" work items that are simple to implement but also key in terms of business revenue. These changes typically get turned around within a week of dev time. They're also, by nature, easy to test. For these easy tasks, the business can do the QA work for you, saving your QA resources for the larger projects.

For each incoming request, you have a team who assesses the work needed for each request, how long it'll take and how it impacts current projects.

If they're deemed a quick win, they go to the fast-track team for rapid development.

This way, the business get the rapid turnaround, but on items that are bite sized. You also have the ability to push back and tell the business that requests will take more time and process to push through with a high standard of quality.

Essentially what you're doing here is setting expectations for each business request. Easy stuff is deployed quicker, harder stuff goes through the right processes.

I’ve been in a very similar situation, and as a developer it often feels like there’s little you can do directly. What helped me gain perspective was working in a different environment, where I realized that the root of the problem usually isn’t the developers or even the QA team, it’s how client expectations are managed.

In many cases, the issue comes from ambiguous contracts or from client-facing bosses/managers not pushing back when additional requirements are introduced. Without clear boundaries, clients will naturally try to “stretch” the scope, and the pressure gets passed down to developers.

The most professional way forward is to suggest changes that your bosses/managers see as added value to the company, not just the developers: stronger, clearer contracts that explicitly state scope, deliverables, and timelines, and that include a formal process for handling change requests. When new requirements come in, they should be addressed through contract extensions, with additional time and compensation built in. This protects both the company and the development team from endless scope creep and unrealistic expectations (also more $$$).

That said, if you raise this or other points and leadership refuses to act, even after similar issues continue to happen, it’s a sign to plan ahead for yourself. A company that consistently ignores professional standards and pushes all the risk onto its developers is unlikely to change unless forced to, and you’ll want to think carefully about whether staying there helps your career in the long run.

(This is, perhaps, a partial answer, to one aspect of the depicted situation.)

1. We deploy.

Great! Good job getting a product out there!

2. Then customers announce some additional requirements.

It sounds like those should have been part of the scope earlier.

Oh well, that's fine. Customers changing their mind is a thing that can happen. Their requests for something different should then be a new work request/project, or an adjustment to the existing project. Professional project management training specifies that adjustments to an existing project's scope should go through the "scope change procedure". That involves getting agreement with all stakeholders.

3. Then we're hustling to meet those requirements. Devs, like myself, get urgent requests: "Quick! Develop this feature ASAP! We need to close the contract!"

Scheduling resources, like your time, is a separate topic than changing scope. I know, they both seem to impact the same resource (you) in the same way, and may be based on decisions by management, and so they do feel related. But internal scheduling is a separate skill that management (a "project manager", salesperson, and/or dev team lead/manager) may need to implement in some different ways.

(A scope change might be negotiated with a customer. Internal schedule probably would not be.)

4. There's no time to develop it properly,

This is a resource issue.

Note tasks do not necessarily have a fixed scope, so providing an estimate is not really possible.

Improperly-scoped tasks can blow up, cause lots of stress, and make everybody involved less happy. All work should have a clear scope. For instance, a project's scope may consist of 14 tasks, and when each task is done, the project's scope is complete. Each of those tasks should be clearly scoped so that someone can verify whether those are done, or not.

If you don't have good scope, expect stress. Hpoefully you can convince whoever is relevant to improve scoping skill. Until that happens, as long as you keep working there, this type of stress will occur. There's no way you can work around that. The only way to improve that is... to scope better.

Note that while this answer does say there's quite a bit which is management's responsibility, many professionals with less experience may think they need more resources than they really do, and might prefer more time to be made available when management doesn't see that as necessary. And in at least some cases, management is right and the inexperienced professionals just need more experience showing how things are done successfully, and can then successfully deliver within tighter constraints (such as deadlines). So, regarding how much testing is really required, how much pre-planning is really required, what deadlines are actually realistic... it is management's job to determine these things. If they seem out of your reach, maybe the best solution is for your own skill to improve, or maybe it is to change employers so you can get into an organization with more reasonable demands. The truth may rely on a delicate balance which can be hard for an uninvolved unbiased and mostly uninformed person to really effectively take one side or the other.

But regarding things being unscoped, or scoped poorly (e.g. needing revision of clarifying completion without a good revision of resources like time), that's just plain bad. Maybe forgiveable, and hopefully improveable. But, still, bad.

Poor scopes just plain won't work out well, and will continue to not work out well until something significant changes, as you seem to have already noticed so far. Maybe try to have some conversations that demonstrate respect (regardless of how much respect actually exists in your inner feelings). See how you might be able to help improve. (e.g., provide clear data that can be used for making better scopes early on.) But don't expect management to make many changes (especially ones that seem focused on just reducing your stress level) if management is indeed satisfied enough with how things are.

The idea of just accepting such poor scoping, endlessly without any care, is just accepting tremendous stress because some people aren't doing better at handling the poor scoping. Don't plan to comfortable settle with an environment of routine, expected-to-continue loose/poor scoping.