Csdrhrt

I joined this small company a couple of years ago, of at the moment less than 10 employees. The main product is a SAAS-application where the customer base is growing steadily. The founder and CEO coded most of it himself from the ground up, with the help of the occasional hired hand. I do thoroughly respect what he's done so far with the business, I have not met that many as driven as he is.

Then I was hired as an experienced developer to be some kind of tech lead, with the goals to increase the level of quality and add to the organisational scalability codewise, so we could be able to take on more developers which we already have, and soon hopefully even more.
So far I have introduced version control, testing and tried to modernise and set some level of coding standards and guidelines together with my team which works fairly well, still with definite room of improvement sure but on the right track.
The issue for me is the CEO. He is self taught, not that it is a problem in itself, but he has not picked up any programming skills further than basically low level tutorials specific to the tech we use.
Because of reasons I would never challenge, he spends little time at the office, mostly executing managerial tasks as he definitely should. He leaves early or works some days fully away and then often spends time coding out of office hours. He mostly jumps on new ideas or specific features individual customers has requested and adds them straight to production going past our regular procedures as if he still were the sole developer, care free of the standards that he always sounds very positive about. His work sometimes leads to issues that lands on me and my teammates or just new functionality that we don't know how they should work because we don't have time to go through and when he's not around we spend unnecessary time on questions from customers about them.

I get that we are growing and need to reach higher profitability, but it definitely feels like he chase short term low balls to get cool or large customers which may or may not pay off, and says we (the developer employees) will fix and clean later on but instead becomes lots of small headaches we don't have time to work on anyway because there's always something more important.

I have tried lifting my issues with this to my boss and the co-founder product owner, and they do respond with acceptance and understanding. But at our last employee evaluation I actually got the feedback that I "should try to complete tasks faster sometimes, instead of trying to find the best way possible" but also that they are impressed by the quality of my work in general. I agree that you cannot spend so much time on every task and I accept the premise that I could have a narrow perspective, but at the same time I do believe that the CEO doesn't know about development methods, nor have a theoretical grasp of software architecture or even more than very basic object orientation which makes that feedback a bit hard to swallow.

I'm beginning to think I am not a good fit for this company. I know I have the technical skills, but I guess I miss the softer skills needed to be a tech lead in this type of organisation which I was supposed to and would like to be. I just don't see how I can approach this without being disparaging as i feel like I am already writing this. I'm probably a bit frustrated over feeling like I'm becoming a worse developer because of this situation.

Is it just time to move on and find an opportunity where I could grow those skills in a, for me, better environment? Or is there a better way to handle something like this?

This is a very common problem in small shops; I created the same kinds of issues myself running a software startup back in the day.

The key to solving it is education. Whether or not your CEO is interested in being a big-D Developer, if he's exposed to ideas around code quality, what unit testing is and why it matters, etc., he'll catch on, and ultimately will look to you for leadership.

One way to educate him is to get him to go to polyglot technical conferences like CodeMash or That Conference, and encourage him to 'come back with new ideas on how we can improve our code quality.' Even better: go with him, and raise the subject of how-not-to-release-bad-software with others at the conference while he's around.

Another good option is to invite a local technical consulting firm to come in and give a brown-bag luncheon on the topic. Most will do that kind of thing for free, and (bonus!) may insist the boss is there, as that's how they get sales. (You should drop that as a hint to the consulting firm in this case: 'Please make sure our CEO attends; he really needs to hear this.') A big advantage of consultants is they're an independent and credible third party that's paid to speak truth to power, which is what's needed in this case. (Disclaimer: I currently work for a consulting firm.)

As far as the feedback you've received about speed vs. 'the best way possible' goes, you might point out that there's a substantial difference between 'just ship it' with some features missing, and 'ship it NOW!' with bugs that make users frustrated and angry. If he learns the connection between software quality and delighted customers, he's more likely to support what you're trying to do.

If the CEO is at all approachable, he should be completely open to this feedback. He's brought you in as tech lead after all, so if you decide that certain standards need to be met and that his contributions aren't up to that standard, you need to let him know.

If you want the "softest" way to do this that doesn't make it seem like you're singling him out, I'd introduce mandatory code reviews for all code that's committed (if indeed you're not doing that already.) Make sure that all work is submitted via PR rather than to the main development branch directly, and then whenever anyone submits a PR (you, your junior, the CEO, etc.), assign someone else to check that code against the documented code quality & standards rules before approving. Many systems allow you to enforce this so that committing to the main branch directly is forbidden.

Of course, if the CEO says no to that, or takes offence at being told his code isn't up to scratch, you haven't really got too many options - he's the boss. If you do decide you should seek employment elsewhere, the good news is that you can do so on your own timescale. This sort of coding style is more likely to cause issues in the medium to long term (technical debt), so there's no immediate need to get out now like there might be with larger issues.