My boss says I over complicate things. What should I do?

Some perspective. Working alone means no second set of eyes to catch errors. No one to waste time BS’ing while ideas have time to percolate.

Working alone means that dumb mistakes happen, they are yours completely. Fixing them is also yours completely.

Working alone means there is no slack in the system. It’s as lean as it’s possible to be lean.

No matter how much time you spend on QA, it’s not independent QA. It’s done with your assumptions, biases, and blind spots. The same that are baked into the code.

Being professional is being cautious. Because you know all these things. You know them because you live them. You live them because there’s an inadequate budget for QA. There’s no being professional on the cheap. Good work takes time and money. Professional work takes professional budgets. Good luck.

Get another job, you need other people to bounce stuff off especially in the early years. How does your boss know this stuff if he's none technical, you're going to get seriously stressed out being the only person he has to offload stuff on.

First, I'd look at what devops you can implement. I'd imagine testing and automated deployments are a bare minimum. Testing may slow you down, but if most of your work is maintenance, you'll see longer term gains. Automated deployments will prevent any manual errors from occurring and instead of taking hours to deploy, it'll take minutes. Both together will give you some confidence in what you're pushing out.

Second, I'd talk with your boss more about "communicating too much". Especially if you're already having problems, you'll want to keep an open line of communication with your boss to let him know where you're succeeding and struggling. I'd try to figure out what kind of communication they're looking for and develop a plan around that.

Third, over complicating solutions is a tough problem to overcome, especially alone. Is your boss technical? Was he a developer? Who's your mentor in all of this? Can you give an example on how you've over complicated something? Without knowing anything, I'd encourage you to spend more time designing and less coding. Design the solution first and take time to look for ways to simplify it.

Fourth, timeframes are always hard. I agree with agile and would encourage you to read up on it. Even splitting a project into milestones could help.

What he said, combined with what you said:

Low budget operation

and the fact that you've been there 3 years indicates that you should probably just find another job. These disconnects happen all the time (and I've been subject similar criticisms many times myself) and ultimately there's just not much you can do about it. People are people, they have different perspectives (and experience gaps) that's they just the way they are.

Meanwhile - since you're pretty much forced to "milk" them for a paycheck until you can find a job under non-sweatshop conditions - consider:

(1) doing a few keyword searches on "strategies for surviving dead-end / underfunded projects" (like ways to deliver "just enough" value to meet a deadline - now that you no longer need to care about the long-term, now do you?) and

(2) engaging a friend (if you have one) or if not, seriously considering hiring a therapist for 5-10 hours to bounce your frustrations off. Really, there's no need to run your health into the ground (and job-related stress can be very toxic) just because you have a weak manager or their business isn't doing very well.

Finally, you might want to look into this classic:

https://en.wikipedia.org/wiki/Death_march_(project_managemen...

Plan. Write things down. Be precise but use as few words as possible. It should be clear from reading your few tiny bullet points you know exactly what you are about to accomplish in an aggressive manner.

Secondly, know your liabilities. Specify these in your plan as a separate set of bullet points.

Finally give the plan to your boss. When you have completed your task according to the plan the boss will have less room to complain.

Ask your boss where they identify complexity. Refactor early to eliminate effort later.

Trying to offer a different opinion from the other commenters.

It sounds like your boss wants more outages. That is what less communication and projects delivered faster gets you.

I think it is probably a case of imposter syndrome and your boss having unreasonable expectations (you are probably perfectly capable and he is pushing/pressuring you to do as much as possible).

The fact that you have no CICD or QA makes me believe that you are trying to work around this by 'over complicating solutions' to reduce risk (which is a good move btw if your boss is the kind to place the blame on you for rushed deployments).

I could be reading this totally wrong, and you will know immediately if I am. Flexible working is great, but just as bad for your mental health if your boss is a dick. Maybe it is time to look for a new gig.

Create a delivery budget. For any feature, ask ‘what are 4 critical things this thing must do to be deployable’. Then ask for 3 ‘nice to have but not critical’ things they need.

Always, always, deliver the mvp - critical things. Then negotiate your timelines for nice to haves. Keep your communication lines limited unless to clarify something critical, or make clear that part of the feature is not feasible.

Follow this process and you’ll start to align quickly with what they want, while building credit towards negotiating auxiliary timelines (nice-to-have’s).

It’s a process, don’t be too weirded out by the feedback. Systematically solve it.

Instead of avoiding mistakes, spend that effort on work that can be easily reverted when mistakes happen. This will let you move faster with confidence your services will survive when they (inevitably) fail. Generally a short outage is preferable to slow development velocity.

Examples:

- Bad deploy: rollback to previous version

- Launching features: guard new behavior with a flag you can control and quickly disable

Can you take a view of what is the least or easiest way to deliver functionality? Then compare to your intended solution to see why your design is good or whether you need to adopt ideas from the simpler solution?

Can you imagine telling a doctor how to do their job? Or a carpenter? You wouldn't have a clue. Your boss doesn't have a clue :)

Learn agile. Deliver small sprints with exact requirements.

Tradeoffs are an intrinsic part of engineering. One part of your job is to propose solutions and tradeoffs. For example, "if we want to ship this fast, we can do it in a day, but here's what could go wrong, and how much negative impact this could have on how many users/bottom line, on the other hand, this is the upside". "If we want reliable, we'll have to solve X issue before shipping it but it'll take about Y days because we still haven't resolved incompatibility with third party tool Z"

Do you frame your decision making and the set of options in terms your manager understands and can base their decisions on?

Why this matters? It avoids you spending days or weeks working to solve an issue because you think it'll save $X, when in fact $X may not be what matters most to your manager, but the ability to ship before a competitor, for example, especially given the fact that if the price to pay if that feature falls flat is not that high.

One problem members might have is not knowing what matters and why it matters, and that effort must be done by management to make it clear through what lens team members should look at problems so that they themselves will be able to make decisions.

If this effort is not done systematically by management, members can help management with eliciting questions explaining why they're asking these questions so it doesn't come off as an interrogation. You're asking questions to know what matters most so you could optimize for that and work to solve the right problem.

One other problem is that some team members cannot discern situations where they can make a call, and situations that warrant getting the green light to do something. This leads either to members requiring the attention of the manager for everything, even things that the manager doesn't care about, or members making a decision and going through an action where the cost of a mistake is too high but they didn't know what the cost of that mistake would be.

True positives, false positives, true negatives, false negatives.

This why members who can tell which situation is which are not common and appreciated by management, because they relieve the pressure and reduce the number of interventions management has to make. This builds trust in that member's judgement, and they gain more latitude to do what they want because the manager knows that "Alice only calls me when it really matters and when the situation is tricky and she needs confirmation."

One great habit to have is to enable management and executives to do what they do best: make corrections, green light things, shut down things.

I used to go to my former CTO with prototypes of different approaches in different branches. He'd look at them and pick one or ask if I could do corrections to one of them and ship it. "Do you care about this aspect or is that good enough?" "Nope, we'll merge as is" or "All is okay except this and this must change because X, Y, Z.". Things move really fast that way.

I also showed the CEO different versions, and he'd ask "Nice. I prefer that one because I'll present it to [type of client] and it's more relevant".

In other words, instead of asking what the next step is, proposing alternative approaches: We can do A, B, C, D and here are pros and cons for each and how they relate to the objectives with tradeoffs and optimizations.

The manager then has a "menu" they can pick and choose from, and will either say "We'll go with A" or "Just change this aspect in B and go for it". This saves enormous time and makes their job easier, and makes your job easier too.

There's effort to be made by the two parties. Management must train members to know what matters and expose how they view things. "Our priority is this, if you need to spin up VMs to test something, you can do it as long as you don't blow up the budget. Say you have a budget of $300. What we want is X and we know we got it if W, Y, Z".

The team members ought to do the effort to frame their decision making process, their options/solutions, their problems, in terms stakeholders can understand, reason about, and make a decision about. When you do this, you'll get extremely useful input from other stakeholders and you can enable people who make decisions to make informed decisions because they have clear information they can digest.

The excuse that manager/CEO/advisor/investor is not technical is a bit easy to have. How do you frame problems to get the best out of that manager/CEO/advisor/investor's minds or executive authority? How do you give solid arguments to your manager to advocate on your behalf, say to increase budget or to hire talent by framing things in terms they understand and can work with, but also in terms that their boss can understand and work with.

You: This [engineering/technical problem] is [framed in terms boss can understand]. One way to do that is CEO doing [thing in terms boss understands] with arguments [boss can understand, and then again in terms of CEO can understand].

There are things that matter and you know why they matter, and one part of your job is to make other people understand why they matter. The ability to connect the dots and take someone by the hand from the [business] objective all the way down to how inability to do multiprocessing is hindering that objective, and how what you're doing is solving the problem is valuable.