Your expectations are neither unreasonable, nor reasonable, without the context and environment of the business and market it operates in.
For some products, companies and their markets, the expectation from the users/customers could be so low that the mere existence of the product can be quite disruptive.
In fact, (most) startups exist to pursue an idea of disruption.
As the product, company, market and customers evolve, the expectations begin shifting.
This leads to an inevitable choice across a spectrum from leaving things as they are to rewriting entire stacks.
If the leadership can do a good job hiring the right people to both navigate the chaos and know how to get to a better place, things would then evolve, in whatever pace that can be allowed by the business, given calculated risks on engineering practices or lack thereof.
The key here is the "right people", rather than just "more people".
Based on the information shared, you sound like you are the right person to lead an engineering quality and reliability initiative.
Although, I do assume that you may not be the right person because you are failing to cope with the current chaos.
That being said, the mere fact that you're seeking counsel here tells me you are willing to manage this. I think that's a great start.
At this point, I belive there are two (and possibly more) things you can do:
- Talk to the key people in leadership to understand how they perceive the current situation and whether they are willing, if not even intent on, improving the status quo.
- Ask yourself for how long more you can navigate the chaos and whether that takes away from your mental and even physical well being.
Perhaps shifting your perspective and being intentional about it can help. This could even be the best thing that happened to you. Fast forward a few years, you'll perhaps have become an engineering leader who has had the opportunity to have experienced a huge paradigm shift and worked on solving its challenges.
With all due respect, I do find work - just as anywhere else - to be a place for meaningful discussions.
I usually work as an engineer and manager/mentor and prefer being vulnerable with the people I support. That leads to them often choosing to be themselves.
This only requires some honesty and sincerity. Once we and everyone else who choose to do the same connect on that level, such meaning shows itself in not only one on ones, but also in online chat.
I also find it a boost in productivity because it allows distilling work discussions into pure work because people have to worry less about what they say/write or how they express it.
One huge and rewarding benefit is also that people begin looking behind misconstruable messages, reading the discussion in positive light and helping each other communicate better, too.
I've had a similar experience from a different angle; I'm not over anyone, but I have engaged in conversations that cover politics, religion, philosophy, etc.. I avoid politicianX vs politicianY types of conversations for obvious reasons, but I think the restrictions are good for conversation - not so dissimilar from the restrictions on HN vs FB or Twitter. It forces me to find common ground, to listen to what people want and how they think things should work. I have found that people wildly diverge from party politics in this scenario. When we focus on the issue and hypothetical ways forward, we tend to agree on the big points - or agree in spirit, at least.
When we remove the labels and the expectations that come with those labels, we can have a conversation where both sides operate in good faith. Of course, we can still have those conversations with the labels, but, in practice, we tend to get distracted by them.
I had someone ask me what I thought about the riots (this was within the first couple days), and based on his background and other conversations I had with him, I knew his POV was very different from mine, but we are on friendly terms, so I engaged. Tone is important. My focus was on what we could do so that things don't reach that point, and I was empathetic toward the people he felt the worst for - business owners who lost things to the riots. And, in turn, he was empathetic to the people who suffer systematic abuses. In these scenarios, I just try to focus on understanding where the other person is coming from and to make my thoughts clear. I don't get frustrated when someone doesn't say, 'Gee, never thought of it that way, but you're absolutely right.'
I think a lot of people - all over the map on the big issues - are tired of conversations that center around your mob vs my mob. They're ready to have real conversations about real issues. The depth will depend upon what each person brings to the table, but on a basic level, depth is almost beside the point. It's enough to listen to an on-paper enemy and have them listen to you and walk away understanding that you're not enemies at all, that you both want what's best for your community, city, state, country, and world. We can disagree on how to get there, but if we trust the motivations of others, we can work together. We can't work toward progress with people we don't trust, which is one of the underlying issues with starting with labels.
Of course, there are people to distrust for various reasons, but if I find people who are willing to honesty discuss why they believe what they do about anything (and what they know and don't, etc.), I want to hear what they have to say. And even as I cringe at a conclusion, I want to show them respect and that I took the time to understand how they arrived. Just like anything, angle/perspective makes all the difference.
This is just where I'm at - not meant to tell people how they should behave or how well my perspective meshes with their personality and experiences.
So you write some piece of code that looks like it can be used elsewhere, perhaps as a library. What happens in that case? Can you not use it without your client's permission?
I think the developer should own the code but the client should also be given all rights to use, copy, distribute, resell, or both parties could be given exclusive rights.
And then there is the matter of by-products which are pieces of code you develop during your contract time but not necessarily used within that project because somewhere along the line you've discovered that it is something you can use elsewhere and does not make much use for that specific project.
Who owns those? From your contract's perspective, the client owns them and you are obliged to deliver them whether or not they end up in the final product.
I'm not trying to be dismissive of your lawyer's knowledge in the area, and neither am I a lawyer, but I think it is kind of hard to write down a standard contract that can be applicable to all projects. Contracts should be negotiable and license/IP is something as negotiable as the contract fee. And your contract sounds too protective of the client at your cost.
I understand where you are coming from. However, you have to be careful of who is paying you when you are writing specific code. For example, I have written libraries that I have used for multiple clients. In this case, I have placed the library under an open source license (and on at least one occasion not an open source license, and the client had to pay a licensing fee), and then used it with the client. However, I DID NOT charge my client for the hours I spent writing the library that I was keeping or open sourcing. Now that code does not belong to them, and they should not have to pay me to write code that does not belong to them.
I DID charge my client to implement the library within their project. This implementation belongs to them immediately.
Now I, of course like many engineers, use similar ideas across clients. However, these are rewrites in one form or another. Frankly I have never read a line of code (my own included) that I did not hate and think I could do better. So I don't have any issue with rewriting code for a client that does something similar to another client I had previously. They own that code and I charge them (quite a bit) for it.
Negotiation can take a very long time and that time is unpaid. I would prefer to have a good solid pipeline of clients who use a standard contract and a shorter time from negotiation to signing then having to renegotiation every contract that I come into contact with. And yes my contract protects my clients quite well. Which is why I have a lot of repeat business and get paid regularly, without fights, and on time.
For some products, companies and their markets, the expectation from the users/customers could be so low that the mere existence of the product can be quite disruptive.
In fact, (most) startups exist to pursue an idea of disruption.
As the product, company, market and customers evolve, the expectations begin shifting.
This leads to an inevitable choice across a spectrum from leaving things as they are to rewriting entire stacks.
If the leadership can do a good job hiring the right people to both navigate the chaos and know how to get to a better place, things would then evolve, in whatever pace that can be allowed by the business, given calculated risks on engineering practices or lack thereof.
The key here is the "right people", rather than just "more people".
Based on the information shared, you sound like you are the right person to lead an engineering quality and reliability initiative.
Although, I do assume that you may not be the right person because you are failing to cope with the current chaos.
That being said, the mere fact that you're seeking counsel here tells me you are willing to manage this. I think that's a great start.
At this point, I belive there are two (and possibly more) things you can do:
- Talk to the key people in leadership to understand how they perceive the current situation and whether they are willing, if not even intent on, improving the status quo.
- Ask yourself for how long more you can navigate the chaos and whether that takes away from your mental and even physical well being.
Perhaps shifting your perspective and being intentional about it can help. This could even be the best thing that happened to you. Fast forward a few years, you'll perhaps have become an engineering leader who has had the opportunity to have experienced a huge paradigm shift and worked on solving its challenges.