I’m super excited about my startup company, love the product, the team, everything … running as the CEO. I have a super talented cofounder as CTO, but lately I’m starting to get tired of him. I’m asking him to define the timeline of the functionalities’s development, and in the end, he’s not delivering on time. Have you been in a situation like this? Is hiring a CPO the solution?
CEO ~ CTO // Love ~ Hate
12 answers from the community
What's your experience with coding and product development? How many other technology startups or products have you worked on?
I've founded 4 startups, and the last one together with him too. We were going through more or less the same situation.
Hiring a CPO (Chief product officer?) is not the solution this early on....you're the CEO/CPO/CMO/CFO etc.
Better to get to the bottom of why he's not delivering on time. Are you giving him unclear projects that end up being out of scope? Are you taking the time to break large projects into smaller manageable chunks with properly prioritized tasks?
"Are you giving him unclear projects that end up being out of scope? Are you taking the time to break large projects into smaller manageable chunks with properly prioritized tasks?"
That's the thing I guess, I'm not good at this, I provide a vision for the company, manage the team and work on the product strategy and evolution for the long term. Should I really go into these kind of details? Should I educate myself on how to manage this process or break large projects into smaller prioritized tasks? As far as I know, that's CPO's value, right?
I hate buzzwords but look into "Agile" development. The key is you define short use cases (called stories) that both you and the CTO can agree on which can be done in short cycles (sprints). Since both of you understand the scope of the deliverable if he still fails on it, you need a new CTO not a CPO.
Agree completely with the comment "I hate buzzwords but look into Agile. . ." . This method will provide insight fairly quickly as to where the breakdown is happening.
However, don't be surprised if it is more a personal problem than a technical one. Perhaps a direct conversation is required behind closed doors (even if it gets heated) - as opposed to changing up the development methodology and exposing juniors (and the budget) to both the learning curve of something new and the overt demonstration that the founders are at odds with each other.
Just a side note - your wording is packed with subtleties that will prevent constructive dialogue with the CTO. " I have a super talented cofounder as CTO, but lately I’m starting to get tired of him" -> if he is the cofounder, he deserves the respect of not being addressed with "have" (as in yours - implying ownership) - if you founded the company then hired a CTO, then "have" would be acceptable. Also, "tired of him" indicates that you are in power to dispose of him, again as CTO perhaps, cofounder no. Either way, if your undertone of superiority is seeping into everyday discussions then expect malicious obedience. Depending on the stage of your product, it would be financially worth it to humor everyone until you solidify an exit strategy for either you or the cofounder.
+1
Completely agree on the subtleties of language and how this might seep into your behaviour without realising.
Any practical source of information for creating these 'stories'? Would appreciate it.
I agree with the 2nd reply about implanting new methodologies, I'm totally oposite to that.
About the side note:
I didn't realise about that before. But reading again your comment, you're right. He's cofounder, but not on a 50 50 basis. It's interesting, but anyway, I guess it's only a matter of wording, since I respect him and what's more, admire him for his work and skills.
Check out "Pragmatic Thinking & Learning" by Andy Hunt
pg. 122
I've been through that, and in the end I figured my co-founder (and CTO) was not motivated enough as he wasn't feeling challenged any more. So we agreed on a few changes, he took more control over the product, and now we are happy again. Talk to him or her, and open up to listen to what he or she has to say, and you will be able to work things out. But don't get annoyed, as that is a recipe for disaster.
All the devs out there are overly optimistic, few people can estimate well. Take it from me, I've been doing it for 6 years and I'm definitely not perfect in it.
Does it matter? You can just multiply his estimate by 3 or something and go with that.
What matters:
1) Is he working hard enough?
2) Is he productive? Is he working on the important stuff?
If you reply 'yes' to both of those questions, then it's just about managing (your) expectations, nothing else.
Obviously, as a non-technical, you probably don't have a clue whether he's working on the important stuff, but that's a different question.
I know the x3 technique, that's the one that has worked better for me so far.
About working in the important stuff, effectively, what's the important stuff? For me it's seeing the product evolve and see the new features go through at the same time that the platform is performing well. But on performance, specially on an early stage, where CTO and System administrator is merged in one person, that's what use to happen, a lot of work is behind the scenes and difficult to perceive from a non-technical profile.
Answer to both questions is yes, so will keep up with the x3 manage-my-expectations thing.
Thanks a lot for all your replies guys!