
Ask HN: How can I get my co-founder to stop coding? - scoobilydoobily
I run a small startup with my co-founder.<p>Things are going pretty well, I built the product myself and my co-founder has found a customer and sold it to them. We haven&#x27;t taken any loans, accepted any funding or given away any equity.<p>We are currently preparing to launch in the new year.<p>My co-founder has <i>some</i> experience coding, and sometimes takes it upon himself to dive in the code and make changes.<p>This causes a couple of problems:<p>* He doesn&#x27;t understand the stack well, and has introduced bugs<p>* We have lost potential opportunities because he has told customers that the product doesn&#x27;t have features it actually does. When asked why, he will say things like <i>I didn&#x27;t see it in the code</i><p>* He has a tendency to take out his laptop when meeting potential customers, bring up the codebase, and try to talk them through it<p>On the plus side, he has found us our first customer, and I have no doubt that he can find more (he&#x27;s very salesy, and well connected) but I really need him to step away from the code!<p>I&#x27;m just not sure how to raise this with him without damaging the relationship. Any advice, HN?
======
maplesirupfan
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

~~~
AnimalMuppet
"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."

------
trjordan
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.

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

~~~
rl3
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.

~~~
scoobilydoobily
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](https://www.youtube.com/watch?v=JlwwVuSUUfc)

~~~
LifeQuestioner
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.

------
mmclar
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.

------
rock3m
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](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.

------
chrisgoman
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.

------
tomhoward
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.

------
eagsalazar2
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.

~~~
whamlastxmas
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.

------
Mz
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.)

~~~
scoobilydoobily
Will check out that book, thanks

------
mindhash
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.

------
cwkoss
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.

~~~
scoobilydoobily
Great advice!

------
whamlastxmas
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.

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

------
fuzzcode
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.

------
shimon
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).

------
chipmonkey75
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.

~~~
scoobilydoobily
> 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](https://www.youtube.com/watch?v=JlwwVuSUUfc)

Thankyou for the advice, much appreciated.

------
drumttocs8
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.

------
cvaidya1986
Make official titles today complete with business cards. You are CTO and VP of
Product Management. He is VP of Sales. Communicate and agree upon these roles
clearly.

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

------
whb07
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?

------
loxs
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

~~~
dxhdr
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.

------
kobeya
Talk to him, not HN.

