How do I tell our CEO to step back from development processes?

Question

We don't have such titles, but I am basically the CTO.

Our CEO/Founder is a passionate developer himself, but due to his management tasks, his skills are a bit outdated.

We are good friends, know each other for years and never had any discrepancy.

Anyway, now and then he starts his own projects with some developers and acts as a lead there. This makes it hard for me, to see "the big picture", manage resources and also hinders our juniors learning process.

I'd prefer to have him delegate the projects to me, where I can manage all processes, choose technology, assign developers and basically get this thing done at a high quality.

I want him to acknowledge that he is not a developer anymore, but a CEO of a growing company. He doesn't need to care how something is done, but rather that it will be done by the right people.

How can I tell him to take a step back?

Answer 1

You need to have a conversation making the points you made in your question clearly.

If you have been friends that long, you should be able to do that dispassionately, professionally and kindly.

He should also be able to understand the situation and the issues it can cause.

Answer 2

TL;DR: You can't. He's your boss, it's his company he can do what he wants.

The best you can do is ask him if he can take you in on the new projects right from the start so you can give advice (note: not dictate) which technology is best suited for what he wants to do. That way, you can have the required overview of the project as well so you can steer it later on if/when it has shown useful enough to go through with it.

By doing so you can show him how much knowledge he's lacking already without directly telling him he should give up on his initial passion (he's still a programmer in his heart). With some luck he catches up quickly on what he's lacking with your guidance and can actually keep starting up new side projects the way he likes to do.

Finally I want to point out that it could still be considered his job to decide which main technologies should be used. He has to take informed guesses on how long the current ones will still be officially supported, if there are new ones to consider that allign better with the companies vision. For example: in my current company it's the big boss that decided that we're going to transition from java to go in a couple of years and has now put together a team that is starting some initial go project to set a baseline for everyone. It's his responsibility to notice right now whether or not java would be fit for the job in 5 or 10 years from now. If that isn't the case, than it's right now that we have to start transitioning into something else, or we get into trouble 7 years from now at which point it becomes impossible to quickly transition our entire codebase.

Note that I said here the "major" technologies. Our big chief doesn't need to know which version of java we should currently use, or how we automate our build proces. Not even whether we should use subversion or git (those are the things you could tell him when/if he takes you on from the start). He does decide that we're programming in java and will transition into go in the future. Or that we're going to look into a more scalable database since the current one is reaching it's limit and is ending support in 2025.