Ask HN: How can I get my co-founder to stop coding?

Instead of pointing out what is wrong with him, you could highlight his strengths - sales and ask him to build on that. You could tell him that it'd be beneficial for your startup if you both concentrate on each of your strengths. You - the technical aspect and your co-founder finds ways to bring in mullah.

You must have a sit down and make sure you are both on the same page with respect to the capabilities of the product. If you don't have relevant documentation for the product you've built, perhaps he can work on that. This way he would understand the product inside out and at the same time have some material when presenting to prospective clients. Going through the codebase with clients is a big nono. Alternatively, you could ask him to prepare a demo of the product that he can use when presenting to prospective clients.

Congrats on building a product and selling it without taking loans and giving away equity! Great going

Definitely, I wouldn't have partnered with him if he didn't have those strengths.

I am fully aware that I am not good at sales, etc, and he is very good.

Good point on the documentation, will work on that. Thanks

"I can hire someone else to help with the code. I'm not sure I can hire someone else who can sell as well as you can."

There is probably something else here that you need to talk to him about.

Why does he feel the need to code up a feature right now, without talking to you about it?

Why is he having trouble keeping everything about the product in his head, with looking in the code as the only fallback?

Why sort of gaps are there in the demo that looking at the code is the best way to address it?

This is not a problem with him, though it's also not a problem with you. It's a problem with the business where the founder who talks to customers feels he has to come back and bang out features. Worst case, he's just bad at his job, but the likely reason for this is that there's a mismatch between you two in terms of stability, urgency, or prioritization.

You're adults. Talk it out.

The hell is he taking out the code to explain it to customers? Are you sure he's "salsey"?

I second this, it sounds cringey on the face of it. Maybe it works for non-technical customers, but I imagine technical customers would immediately be taken aback.

The only exceptions might be cases where very specific behaviors or implementation details are in question.

My main issue here is that we have a technical product, and the people we are selling to are developers.

If they could build it themselves, they wouldn't be talking to us, but my co-founder doesn't seem to get this.

It reminds me of this Silicon Valley scene - https://www.youtube.com/watch?v=JlwwVuSUUfc

Hmmm...The evidence is: he's made one sale. Any person can talk the talk. He's clearly doing things a salesperson shouldn't be. You, a non-salesperson know this. But perhaps he will shine through when the product is released. But to iterate, thus far, he has made one sale, that doesn't make you a salesperson. Yet.

He may be showing people the code because he's proud of it...

Speak to him.

Require that a person besides the author has to review code changes before they are allowed into a code base. Do it under the guise of 'transparency' or 'being on the same page'. Don't let him see your post.

We had problems similar to this, but we were all technical and we were all opinionated about the ways we code. We solved it by having a code review process. Setting up a review board (https://www.reviewboard.org) is a good start. To create code co-ownership and keeping all the people on the same page, code review helps you communicate better, and get familiar with the code base. You, as the more technical one, can ask your co-founder to review your code as well.

If he is smart enough to code, spend an hour with him walking through each folder of the source code and then draw a diagram of your stack and also walk him through it. He can use the drawing to walk your clients through so it is prettier than the code. So, you have to go to "sales side" and put yourself in his position and then help him there (maybe even pretend to be a client by role-playing) so you can see what he is trying to do. I'm assuming showing code is not the end goal but something else.

Here's an important thing to think about, and to find a way to address in your team, on an individual and interpersonal level.

Founders/leaders have a far greater chance of success if they have the ability to be completely honest with themselves, and teams have a far greater chance of success if they can be completely honest with each other.

I can't find any links to specific excerpts now, but it's worth reading Ben Horowitz's "The Hard Thing About Hard Things" for insights about this alone; about the degree to which he and Marc Andreessen have an honest relationship with one another, and about how much value they place on self-honesty in the founders they back.

The thing is, it's very rare and very slow and difficult to accomplish.

Most of us have some ego fragility, and find it very hard to confront the truth about ourselves, and for that reason most of us generally avoid making fully honest comments to our friends, colleagues, partners, etc, until things get to breaking point, by which time it's often too late.

But it can be accomplished with a lot of commitment and personal development work over a long enough period of time (different methods work for different people, but practices that focus on ego detachment are the right approach), and if/when you can do it, you should see power-law improvements in your outcomes.

It sounds like what you really have is a code management process problem. Remove him from commit access the repo, force him to submit PRs, review his PRs, provide feedback so he gets better but can't break things. Tell him this is "best practices" which is basically is. You could also take a less draconian approach and tell him that PRs and code reviews are required before merging. If he doesn't do that, then you can remove his commit access.

Also if your co-founder doesn't know he's, at least, a jr developer and you guys can't even talk about that, you have other major problems that if they aren't biting you in the ass in other ways now, they will.

This would work (albeit in a demoralizing way) in corporate America. I don't think it's going to work when his cofounder also owns the code base and the OP doesn't really have a right to restrict him. This is a communication problem, not a technology one.

Get a copy of the book "Getting to Yes." It's a quick read and should help you figure out how to approach him.

My guess is that since he is "salesy," he is the kind of person who values social capital and he thinks the way to get your respect is to prove he is good at code. One of the takeaways from negotiating studies is that value lies in your differences. If you were both good at the same thing, you wouldn't really need him as a cofounder.

So, maybe get better at praising him for the things he is good at and making him feel like you are awed by the things he can do that you can't.

Also, you need to make sure he understands the product better. His lack of understanding of the product is a serious issue, even if you can get him to stay out of the code base.

Do try to approach this diplomatically, but also recognize that this is a make or break moment. Either the two of you will hash this out and your ability to communicate and your trust in each other will grow, making the company better in every way, or it will break you two up. And it is better to lose him early so you can go find someone else than to keep this limping along out of fear that any confrontation will be a dealbreaker.

Cofounders need to be able to hash things out in a serious way. This is one of the reasons it gets compared a lot to marriage. If you can't "fight it out" so to speak and come up with a real solution, the two of you do not have what it takes to grow a company together. (You should try hard to not be too fighty about this, but you also need to make sure you aren't erring on the side of being too much of a conflict avoider. That is actually worse.)

Will check out that book, thanks

A thing about long lasting relations is, both parties are comfortable discussing anything under the sun. So you must open up a channel around this and express your concerns.

In my first startup , my cofounder was interested in design and would spend needless amount of time on it while his core job was to go out and sell. Honestly I couldn't get my thoughts across to him and left the startup. Probably a noob move now I think about it.

Have a discussion about mutual exclusivity to get most done as a team. Tell him you believe in MECE and what his thoughts are about it.

Also sometimes you can be more accepting to his coding interest and let him do a few stuff. But you must remain gate keeper for the final version of product. Have processes setup for this. You could mention that you are not comfortable having more than one person handling releases.

I have learned from my experience that it's important to have most difficult discussion early on with your cofounder.

I think you need to be honest. Do a 'shit sandwich': complement, air grievances, complement again. ex.`

Hey, I think you scoring our first customer is probably the most important thing either of us has done, and I'm really excited about sales starting to roll in. I know that I'm not very good at that kind of thing, and so I should focus on the codebase. Because you're much more effective at it than me, I wonder if you should allocate a higher proportion of your time into sales and business development.

As a two-person company, we need to be as smart as possible with our most limited resource: time. I appreciate that you're making an effort to contribute to our codebase, but I have a few small concerns:

- Your commits have introduced a number of bugs. It takes me twice+ as long to fix a bug you wrote than one I did because I need to understand what you did. I think we both agree that we want to make sure that X and Y features are done as soon as possible, so please be very cautious about committing any code that could introduce bugs that will block progress. Once we get better unit testing, it will be easier for you to contribute code more safely, so lets think about improving testing after X and Y.

- It was disappointing that we didn't land Z customer because of an internal communication failure on what features had been implemented. I think we need some documentation about what the product is capable of. If you could take this on, that'd be awesome. I'll try to do better at communicating what I've implemented with changelists or 'new feature' emails.

- I know you like to show customers the codebase when walking them through the product. I'm worried this is too technical, and perhaps documentation or a pared down marketing 'fact-sheet', or 'user stories', or something like that could be a more effective visual aid for these meetings.

I really appreciate your spirit and effort in everything we've built together. Your code has been helpful, but we have SO much to do that isn't purely code that I think we should 'divide and conquer' for the next few months: I'll try to finish X and Y features, and you get another couple of customers. I think if we accomplish that, our company would be in a really strong position.

What do you think?`

Make it clear that his bugs are introducing operational costs, and that you want to mitigate that cost.

Don't use the 'stick' to keep him away from the code, but rather dangle 'carrots' in all of the other parts of the business that need work.

Great advice!

Bring it up as a discussion topic, not a criticism. Ask how showing code to clients is beneficial if they don't understand or care, but in a more diplomatic way.

You could also ask him to develop in branches and give you time to look at it before pulling into master so you can get up to speed on changes and help catch any bugs. Offer to do the same yourself in reverse.

It also sounds like as the developer, you need to better at communicating what you're building and what it features. If your cofounder isn't even sure what all it does, you can be sure your customers don't.

You guys need to sit down and have an honest talk. Just don't tell him you slept with his wife.

Talk more. You guys should both be giving honest feedback to each other. Figure out how you can do more of that in a way that strengthens the relationship, by communicating both respect (you clearly believe he can be valuable in areas other than coding) and your needs (you think the company would benefit more from him focusing on testing the value proposition and growing sales than on directly implementing features).

Cut off his access to version control and set him up with one on a "fake" vc. Demand he make big changes to the underlying structure and give him a unrealistic deadline. Constantly ask him if it is complete, and when he says no, ask why. Then task him with even bigger changes with tighter time frames.

He should tap out within a couple of weeks and resort to selling.

Problem solved.

There's a lot here...

* He doesn't understand the stack well... If you can't get him to stop coding, Get him on source control and branching, but do peer reviews into master, by which I guess I mean keep that power for yourself, or, if that's contentious, keep a separate branch for yourself, and if you see bugs discuss them with your partner. Dialogue is the way to help here, unless he's willing to defer to your expertise, but good code management and practices will help, and keep him engaged. If he's set on it, he may as well contribute properly.

* Re: not seeing features in the code This is an odd one. What is the proper way for you all to discuss features? If you're not both power users or both completely familiar with the code base then how should he know about a particular feature? Is your documentation air tight? Probably best to agree to a stick-to-it answer, if he doesn't know or thinks a feature doesn't exist... this is true for all salespeople who, as you grow, will grow increasingly unaware of features. Something like "let me take that back to our developers -- if we don't have something that precisely does what you want, we can add it as a feature request" or even "they're constantly adding capability and I may have even missed it in our latest version" or any variation. Again, discuss it, though.

*re: taking out his laptop... If he's the sales guy, and this helps him sell it, then I don't see the problem. If this is costing you sales, and you're sure that's the reason, then that's a different discussion. While this isn't an approach I'd take, I'm not "salesy". Again, discussion is your best option, but if you're asking him to stay in his swim lane, then consider whether or not this is wading into his. Better you're both on the same page, I agree -- if the issue is letting clients see trade secrets then, as before, agree with your partner on a party line: "if we can get an NDA in place, maybe a developer and I can sit and walk you through the code if you have a question about a particular piece, if that will help make the sale".

re: damaging the relationship.... just talk to him about it. Raise concerns -- point out bugs and use that to justify asking him to be more diligent, or pass code by you; point out lost sales and discuss what you think may improve. Approach it as a collaborative effort to solve problems, and hopefully he will take it well.

> Re: not seeing features in the code

The issue here is that we will discuss this in advance, I will say Yes we have this feature and then afterwards he will tell me that he told the prospect that we don't, because he couldn't see it in the code.

> re: taking out his laptop

The problem I have with this is that we have quite a technical product, and are selling it to other developers. If they could build this themselves, then they wouldn't be buying it off us, so I don't want them poking around our code in a sales meeting! It reminds me too much of this Silicon Valley scene - https://www.youtube.com/watch?v=JlwwVuSUUfc

Thankyou for the advice, much appreciated.

If a founder and a co-founder can't communicate with each other and agree on goals and processes, you will not succeed.

You need make sure you're both on the same page. One way to do this is for you to list out the features in a presentation or deck. He can "sell" from that, not the code.

Real question, how is he able to introduce new code with bugs in it? How do you know the bugs weren’t yours and they were waiting to be awakened?

WTF?!? What kind of co-founder is this where you can't sit down and have a honest talk? You two should be able to tell each other this kind of things directly in the eye, without thinking about it twice. Just imagine when you start having real problems o.O

Second this. Advice: if you don't have the ability to tell your co-founder exactly what you just wrote here then you're in for a very stressful time ahead.

Most conversations never end well and no matter how many different approaches you take, they can't see the error of their ways.

Talk to him, not HN.

The problem may be you. He closed the first customer.