tthflssy

Don't loose faith. With a single company giving feedback, you probably got already 50% of all feedbacks you can get. Your effort for asking all the others was already worth it.

On top of that, most of the feedback will reflect what state the company is in or what kind of people they are looking for, and not necessarily you or your skills. Eg. they want a deeply technical person, or a good communicator. In one year, for the same position, they will want a different set of skills.

If you know a lot of prospective companies, experiment with your CV / introduction and try to A/B test what is working. This is totally under your control.

Without knowing your context, it is hard to give advice, that is ready to be applied. As a manager, you will need to collect and produce data about what is really happening and what is the root cause.

Clear up first what is the charter of your team, what should be in your team's ownership? Do you have to do everything you are doing today? Can you say no to production feature development for some time? Who do you need to convince: your team, your manager or the whole company?

Figure out how to measure / assign value to opex improvements eg you will have only 1-2 on-call issues per week instead of 4-5, and that is savings in engineering time, measurable in reliability (SLA/SLO as mentioned in another comment) - then you will understand how much time it is worth to spend on those fixes and which opex ideas worth pursuing.

Improving the efficiency of your team: are they making the right decisions and taking the right initiatives / tickets?

Argue for headcount and you will have more bandwidth after some time. Or split 2 people off and they should only work on opex improvements. You give administratively priority to these initiatives (if the rest of the team can handle on-call).

I'd love to see something like this work! At the same time, I used a tag-based system to track services before, it worked at some level for resource tracking, and identifying machines running that nobody knew what they are for. I am also interested in the exact use-case you would like to solve and what size of infrastructure / company you are aiming for.

A couple of questions:

- Tag-based diagram creation: what information would you put into a tag and how are tags managed (manually? automatically assigned in some way?)

- Resource tracking: what is a resource? are they machines / nodes? or do you plan to track database/cache/queues/etc? How do you define waste? We used the simple definition that a machine with no tag, though that is relatively simple and useful at the beginning when you are mapping out the infra you do not know, but might not be great on an ongoing basis.

- High-level overview: how do you know if serviceA is interacting with serviceB? Many cases it would also be great to know if services are interacting with 3rd parties and that is also a big part of the infrastructure. Knowing that serviceA and serviceB is interacting is only the first step, though knowing why they are interacting (is it a critical part of serviceA? what is the business value of that connection? how is the customer affected if it gets broken?) and why was it implemented in a given way? (sync/async, retries and timeouts, what matters to the customer). Communicating this type of context of the architecture seems hard and auto-generated diagrams usually fail to do.

- Infrastructure management: I am not that averse about giving some delete rights for the infrastructure, maybe you can get partial rights, though I assume a lot of companies are already using something for upscale/downscale and might have strict processes for deleting things. What if a delete needs an approval or code review like step?