It’s not you, it’s them: 10 signs your technical cofounder is struggling

As a startup founder who doesn’t code, you’re dependent on your technical cofounder. (They need you too, but that’s for another post.) Even in larger Silicon Valley, engineers often run companies and cultures, and the rest of us often need support from them on a day-to-day basis, especially those of us in marketing and nontechnical leadership.

This dynamic leads to a familiar but conflicting mix of feelings you may have observed during a disagreement with your technical cofounder or development partner that can include:

• “They’re smarter than I am.”
• “I don’t know much about their field. I should listen to them.”
• “Something doesn’t feel right about this response.”
• “The business needs this now. Why do we keep missing deadlines and why do I feel like I never find out until the last minute?”
• “If I fire them, how will we survive?”

How we got here

Silicon Valley’s reverence for developers often stops nontechnical founders and employees from considering an engineer’s technical or social incompetence as cause for any problems they experience. Only after much time has passed do nontechnical leaders come to understand that missed deadlines and communication errors were attributable to a developer’s shortcomings. But by the time a nontechnical cofounder or a marketer allow themselves to wonder if it’s time to discuss performance issues with their developer, things may have soured to the point where the relationship is permanently damaged. In a startup, this puts the entire company at risk.

Since I’m a nontechnical founder, and I have spent nearly 15 years working in highly technical environments, I’m often asked by other nontechnical founders, “How do I know when it’s them and not me?” Even within established companies, non-developers, such as marketers, will often find themselves at odds with underperforming developers and wonder why. While this post is targeted at startup founders, these behaviors can crop up even in larger companies and are warning signs that you shouldn’t ignore. In other words, sometimes it really is the developer’s problem.

Assuming you are doing your job and providing clear requirements, expectations, deadlines, and any other resources required, why might a developer perform poorly at your startup? There are many reasons, and it’s important to understand exactly what is going on with your development partner before drawing any conclusions.

Regardless of the cause, when you see more than a few of these behaviors regularly from your technical cofounder or development team, it’s time to consider the possibility that it’s not you, it’s them.

1. Broken promises. You have a nagging, growing uncertainty about your cofounder. The project is always just one week away, week after week. No real explanations are offered for the delay. When pressed, the developer gets angry. How dare you question their process? Meanwhile, you’re running out of money and you have no product. You might also feel like development is a black box, in that you have no idea when projects will be shipped and don’t know if you can trust your developer to deliver on time — or with appropriate communication about delays. You might hear, for example: “Why do deadlines matter? We don’t have any customers anyway.” Then, something might ship in the middle of the night with no warning or preparation. In essence, you simply feel you can’t trust the person to do what they say they are going to do.

2. Deflecting or refusing to answer your questions. If a developer experiences a delay or problem, he or she should be able to explain why. If a developer can’t explain themselves or redirects the conversation to another topic, that should set off alarm bells. Good developers can teach you a lot about why something isn’t possible, and that exchange often creates a better solution. A developer in trouble might respond to direct questions with answers that are off topic either because they don’t know the answer, they lack communication skills, or they are unable to understand what you are saying.

3. Excessive use of jargon. Jargon is sometimes in the eye of the beholder. Just because you don’t understand it, doesn’t make it jargon. And let’s face it, sometimes developers don’t have the best communication skills. But, like deflecting, the overuse of jargon, even after repeated requests to simplify or clarify, might be camouflage for a lack of knowledge. In this case, you might feel like jargon is being used to flood you with terminology designed to intimidate you and get you to stop asking questions. If a developer cannot explain the meaning of a term in language you understand after you’ve asked them to clarify or explain, you must consider the possibility that either they don’t understand it themselves or they may not be a good fit for a role that requires a lot of interaction with nondevelopers. If you don’t feel like the developer is hiding something, but their overuse of jargon is impacting productivity within your team, take time to work with your developer on communication.

4. Missing deadlines without communication. Estimating completion dates for code is very hard, and you can expect missed deadlines even from the best developers — that’s the nature of technology. But when launching a new product, nontechnical cofounders are entirely at the mercy of their developer. Weeks, sometimes months, go by with no product and no revenue. Daily and weekly status meetings don’t resolve the communication problem, and you’re constantly surprised about a project’s status. When a good developer commits to a date that they have chosen, they should keep you apprised of the situation regularly. And if they run into snags, they should alert you immediately. They won’t always be able to tell you how long it will take to fix, but they should give you their best guess. Communication about the nature and timing of the delays is a fundamental job requirement for a good developer, so a lack of transparency is a serious red flag.

5. Never willing to go above and beyond. A good developer who is fully engaged will occasionally show up with surprises. This isn’t about over-delivering or sucking up; it’s because he or she loves what they do, takes pride in it, and wants to fix things that aren’t right. That might be a re-engineered process, or an automation, or a fix of a nagging CSS issue. Developers who lack professional experience or who aren’t in love with your project or who have some other kind of issue just don’t seem to care about anything other than what you tell them to do.

6. Loves meetings. Few people like meetings. Good developers especially hate meetings that do not require their substantial input or that are poorly planned. Great developers resist poor meetings with every fiber of their being. Underperforming developers or developers in over their heads love meetings. They can talk for hours about the new Mac OS, their standup comedy hobby, their next vacation … anything but the project at hand. They’re charming. But they still aren’t delivering.

7. All requests are met with “That’s easy to do.” No matter who suggests the idea or how challenging it is, a developer in trouble thinks the task at hand will be “easy” to complete. It’s never a big deal. Except, when you find out later that the thing you were told was easy wasn’t done, and when you ask why, there’s no good reason at all. You don’t want your developer to be trying to please you; you want them to be delivering on your expectations — and communicating about why they can’t. Another example: The prototype is easy, but they haven’t considered actual interaction with other parts of the product, or what doors are closed down the road due to the choices that were made. You might start to feel snowed. Time and again you’re made to feel that the thing you know the business needs is easy, only to find out later that it’s not.

8. Poor listener. One example: You explain to your cofounder why the navigation needs to be revised based on user feedback, but that is dismissed as “irrelevant.” Or perhaps you’ve explained, multiple times, how important it is that every redirect be a 301 for SEO purposes, but for the third time this year, they’ve shipped 302s. You consistently feel “less than” when working with this person, as though they don’t respect you, or your profession. You feel patronized, ignored, or dismissed. And even if you aren’t dismissed, your requests are not happening and the business is suffering.

9. Good people leaving the developer’s team. The adage that “B players hire C players” very much holds true in engineering. The best developers want their hires to be better than them. So if your technical cofounder’s team members seem to quit frequently, you might want to dig into the underlying causes. One possible explanation is that insecure developers get good developers to quit, then replace them with developers who don’t challenge them. To sidestep this issue, get a second opinion about a developer’s expertise, ideally from a neutral third party, and do so again periodically. This is especially important in interviews and prior to hiring.

10. Your gut. If you, as a nontechnical founder, don’t feel right about your technical cofounder or development lead, or you think they’re dismissive, rude, or don’t take you seriously, believe that feeling. If they keep missing deadlines and won’t explain it to you, your business could fail. Trust your instincts.

Then what?

If your technical cofounder displays enough of these behaviors to concern you, don’t wait to address the problem; it will not get better on its own. Start by observing and documenting your cofounder’s behavior objectively. Take good notes and be as specific as you can about the issues you are encountering. Rely on your board and advisors to help shape this document, which in a startup can be as simple as a Google Doc that clarifies your expectations of him or her.

When you’re ready, talk in person with your technical cofounder about the problem, ask about their perspective, then communicate your expected behaviors and share this document.

Based on that conversation, you may discover that your cofounder is basically fine but needs some help, or you may come to the unfortunate conclusion that your cofounder is not going to work out. Either way, you need to resolve this situation immediately and work hard to understand how it happened so you don’t repeat it. As painful and uncomfortable as this situation might be, it’s on you as a founder to lead your team through this issue, for the good of the company.

Have you ever run into these kinds of issues with your technical cofounder or with engineers in your company? How did you handle them?

One final note: Thank you to every amazing developer I have worked with over the years. You have spoiled me for working with anyone less than the best.

Thank you to Bethanye McKinney Blount, Jeff Luan, IdaRose Sylvester, Shane Johnson, Rachel Chalmers, Kamil Rexton, Debbie Levitt, Scott Meehan, and Holden Page for reviewing this piece. You made it better.

Melinda Byerley is founder of TimeShareCMO, where she sells picks and shovels to growth Miners and Prospectors. She was previously a Miner-style growth hacker at eBay, PayPal, Linden Lab(Second Life), Check Point Software and Poll Everywhere. She has been a Prospector-style growth hacker for nearly a dozen startups including her last venture and current clients. You can follow her on Twitter: @mjb_sf.