A shareholder wrote bad software, I started from scratch. How to bring the news?

Question

I'm a software developer and interaction designer. In late 2015 I was approached by a startup for some UX work. Long story short, in late 2016 I became a co-owner/shareholder.

The product has a lot of potential. But as of yet, we haven't made any money. Our business model is a subscription-based SaaS-application. That application is exactly our main problem.

One of our shareholders (let's call him David) owns a software development business. Two of his employees have been working part-time on the application for about five years now. There are a lot of major issues:

• The application is still not in production, we haven't shipped anything in five years.
• The application is buggy, fragile, untested, unmaintainable, hard to change and overall poorly made. A big ball of mud, so to say.
• David and his employees are mostly unable to meet deadlines.
• David knows the intricacies of the product quite well. The same cannot be said for his employees. They repeatedly make poor design decisions based on incorrect assumptions.
• Since David and his team is very busy working on other projects, they can spend eight man-hours a week on the application.

The success of our business greatly depends on having a functioning application that meets current and future requirements. As you can imagine, all shareholders are disappointed with David's results.

Clearly, something needed to happen. Two months ago, without discussing it with any of the co-owners, I started developing the application myself. From scratch. I'm already about 15% towards a shippable application at this point. Thanks to David's efforts, I know exactly what I need to build. I have the luxury to start from a clean slate and being able to work 20 to 30 hours a week on developing the application.

Two weeks ago, I informed the founder of our company. He was very surprised but also happy and satisfied with my decision and results so far. He told me we would need to break the news to David (and the rest) as soon as possible. We have arranged a meeting with David which is scheduled for next week.

What's the best way to inform David? How should I break the news to him?

My intuition tells me to emphasize on the positive effects for David and the rest of our team. After all, David will benefit from a functioning application too, even if he didn't write the code. He also doesn't have to spend his already limited resources on it. So, it is good news for him on multiple levels.

On the other hand, it might hurt his ego. He might see himself as a loser (which he isn't). He might feel betrayed. He might feel that he will lose control, which is of course true.

So, he has a lot of reasons to be happy, but it wouldn't surprise me if he would be angry or disappointed or <insert negative emotion>.

I think it's good to also emphasize on the extent in which he stays involved with the company in the future. He could be a valuable sparring partner, code reviewer or something else.

Also, I'm not going to take the credit he earned away from him. Again, thanks to him the product is well-defined and I can sail smoothly because I know exactly what needs to be built.

Again, what's the best way to approach this? Are there things I need to be aware about?

Answer 1

What's the best way to inform David? How should I break the news to him?

Call a meeting between you and the founder and David. Explain that you started coding it as a proof of concept and it's proven to be a good idea. Then start discussing it in the open.

The fact that you're still working on something after 5 years without shipping should be justification enough to move in a different direction.

He could be a valuable sparring partner, code reviewer or something else.

I think the role you're looking for is "Architect" and that's how I would treat his role going forward. An architect doesn't sound like a diminished role, because it's not. And he can continue in that role going forward.

Answer 2

From that I have seen multiple times, these collisions know no mercy. One of you will leave the startup. It makes no sense to offer David a senior architect position over you, or a right to review everything, because it is just handing him additional weapons he may use either to disprove your initiative or create such a big chaos there that you would not be able to continue development. He may theoretically join exactly your project with you staying an architect, but I have never seen such a miracle happening.

I assume, it have already been discussions. There were ideas, criticism, rewrite proposals from your side. Either the architect does not see the problem, or otherwise he does not see your proposal as solution. He may be either right or wrong, but if the conflict escalated till developing the complete rewrite without approval, one of you (also either him or you) seems not capable of constructive discussion.

I do not say your implementation is better. Beware you may also fail, and not by chance but due some objective problems with your software you do not foresee. This I have also seen happening.

The CEO will get a difficult task to make sure the better architect and developer stays, not the better intrigant.

Answer 3

First, I would caution moving too quickly based on one conversation. A change like this impacts the company at a high level and needs proper review. Sounds like everyone is an owner there. Does "co-owner" mean anything?

If you don't have an Architecture Review Board function, it may be a good time to implement one. They might have asked why it has taken 5-Years. With or without a formal group you will be communicating your vision with multiple people - you need things in writing.

Remove the people from the conversation and focus on results. The desired result is the highest quality software. This includes maintainability. Ask yourself a few things - Is my software functionally better? If your software is better, a technology case goes a long way. Put an architecture presentation together on the technical benefits of your version. Compare the two versions and give specifics. Be careful not to bash the other version. - Is my solution as complete? By this I mean less about the code, and more about support and documentation. How much non-code must change to move to your vision? Determine the impact and cost of change. Even building on David's work 2-months is nothing - the bugs are still larva, they'll be coming soon. - Is this a good business decision? Are you close to shipping the old code? How does that change the timeline? Even if it is better in all other ways, will it add two more years to the release date? Can the organization support it? - new technologies, libraries, or skills required?

If David is in the software business and can't deliver software, that is a problem. What is the relationship? Is there a formal agreement between the companies? Two guys from another company working part time is risky.

I would start by drafting the presentations. Schedule a meeting with the founder and David. Let David know what you have been working on and give him your presentations. This will help gage his response. If things go well, present to the larger set of co-owners and stakeholders. Have a change plan.

Remember there are two issues here - keep them separate. One is the product, and one is business relationship with David's company. David is more likely to resist if you put both his code and company in a bad light.

Answer 4

What went mostly unnoticed is that we have two shareholders here: One of them believes that he is a good software developer, and can produce much better software than the second shareholder.

Assuming your assessment is right you don’t know how the other shareholder will react. I’d have a frank private conversation with them. Best case, they are happy with it and you can go on. (If the other shareholders agree). Worst case, they take it as a personal insult. Then you have the choice: Fighting him or writing that software off. That would be up to you then.