Every time we find a stability issue & figure out a fix, he asks for LOE and if we don't say we can turn it around in a day or two he shoots it down and says we have too many features (which he just thought of in the last 2 weeks) to do.
On top of that, he is always promising to show current & potential customers new features next week - features that haven't even been started or thought out! So we scramble & cut corners to get them demo-ready.
A few months ago, we pushed back pretty hard and said after our next milestone, we need time to pause features & work on stability, and he said we would. Well, it's been a few months and now there are documents and documents of new features we Need to build in order to be Successful. It's getting harder to buy since half of the features we did build get little to no use.
So what can I do? Despite owning a large chunk of the company, it doesn't feel like I have any say when it comes to how I spend my time and energy. I'm trying to bake adding tests, refactoring, etc into my Definition of Done for feature work (thus slowing down those features too.) But it feels like a piecemeal bandage.
I've read these threads on HN before and half the responses tend to be "engineers obsess too much over quality - focus on delivering business value." Well, plenty of business value has been and is being delivered. And when this guy is also always complaining when thinks break in complicated ways, it feels like stability would provide business value.
I suggest you sit down with him and discuss his point of "focus on delivering value". Instead of blaming him or telling him that he is wrong, ask him why he believes that adding new features is the only way to add value. Is he worried that we won't get more sales without new features ? Try to understand his mentality on why he is so obsessed with features and may be then you can get somewhere.
If he doesn't listen, connect him with me (half joking :) and I will tell him that as a fellow founder (even though I am myself technical but don't write code anymore), features are not what we should focus on to get more revenue.
Do you have any customers? Are you (and the rest of the team) getting paid?
- If this is a new start up and you're just trying to get product market fit, then you don't need to spend time on making your systems stable to be able to support a big customer. First, you have to do whatever it takes to get a customer, and then a big customer. Plenty of really successful startups have ridiculously messy code under the hood, and that's OK because the job isn't to write clean code, the job is to create product that people love.
- If you are the CTO of this company, then it is your job to figure out what can be done under what time frames, and despite your cofounder needing more features, it is your responsibility to deliver them. Therefore, your cofounder needs to understand this, but since they are non-technical, they probably have no idea. This is on them to educate themselves, but you can help them. Of course, it is also on you to have a backbone and be able to tell your co-founder "No." It sucks, it doesn't feel good, but if you want to be a CTO, then being able to communicate is part of your job.
- What is your assessment and how you are doing financially with your customers? It sounds like your cofounder realized that you haven't achieved a product market fit yet, and they are trying new features to find what resonates with the customer the most. That is a good approach, but even better approach is to figure out what your customer needs before you build any of those features. It's hard to say exactly how to do given that we don't know anything about your application, but people who have figured out how to do it achieve great success. See my notes on [how Rahul started Superhuman](https://smashnotes.com/p/acquired/e/superhuman-with-ceo-rahu...), or how [Ramon made millions with a cheesy blog](https://smashnotes.com/p/my-first-million/e/blogging-his-way...). Those are just a couple of examples that come to mind immediately.
- Lastly, if your cofounder is asking for more features with little results, they are simply insecure and scared the company is about to fail, but instead of admitting what's happening to you and the team, they are hoping to find a way out of this before the collapse. They should talk to other "managers" in the company and find a way together, but they are scared, they are just a little mouse stuck in a dark-dark corner. If that's the case, see if you can figure out how to help them out, if it's possible.
Good luck!
These apps live in separate repositories and are loaded by the core. The core is tiny and most of the work is on the extensions. Similar to kernel vs. drivers.
Why we did that? We've been building custom enterprise data products for almost seven years. Many of these products were so custom we couldn't sell the same product to another client if we wanted. It is not just about code reuse on the function or library level, it's "functionality" refuse as in you plug in a forecast extension, you plug in a sentiment analysis extension, etc.
A couple of years ago, a college acquaintance came to me and asked if he could hire us to deliver a certain product. We practically had the product ready but the features were baked in the product.
So, now, we have features as independent applications that get loaded, displayed, and interacted with easily.
This allows you to decouple functionality and contain instability. It also allows you to add or remove features easily. You want to kill a feature? You don't even have to remove its code. Just don't load it. Maybe you'll need it in the future and you can work on it independently once you sell it.
This also simplifies hiring and is good for retention. The activation energy for a New contributor is dramatically lowered, since they don't have to understand the whole codebase, which takes more time. You can give them one extension to work on.
Retention is improved because there's a path to onboard code wise, and people can start working and be successful from day one and get acquainted with the codebase as they gain experience, extension by extension. They can also take ownership of that extension, which when the company grows can be a business unit or a company in and of itself.
That's in terms of code architecture. This is useful whether you change your sales/product strategy and tactics or not.
Now, there's a difference between a problem and a solution. People usually tell you about their problems in terms of solutions they imagined. Extracting that in terms of "job to be done" and in terms of "what's the underlying problem the client/user/prospect/customer is trying to solve for which they came up with that solution" comes naturally for some, but definitely can be learned.
The answer to "can we have integration with Kafka" is not "sure we'll get right to it" but further inquiring about the workflow and the problem they want to solve. What is the actual workflow, not the one the executive at some company has read in a McKinsey report during breakfast.
Second, did you sell the existing features or not? If not, adding more probably won't solve the problem.
One of the common remarks prospects say is: "solutions x, y, z have that feature" and you want to tell them "and yet here we are". A nicer elicitation question is "what's been your experience with x, y, z". The answer is invariably "we don't use them". A more naive person would have jumped on the occasion and make that feature top priority because the prospect large company has talked about it in the meeting. But that question makes it obvious that even that feature won't make thé sale. You develop it and perpetuate the cycle of wasting time on whimsical demands. The previous question can be followed up with "interesting, what are you using instead/why aren't you using x, y, or z ?"
The point is if that feature or set of feature was that important, they'd probably be no meeting.
One caveat is that certain features truly do matter, and having the above line of questioning will surface those because the answer will "we don't use them because (compliance/security/scalability/etc). For entreprise, it's rarely if ever about price.
Also, the meeting can be to gather more information about your product because they're weighing the pros and cons of developing it internally. They might even have started and are gathering how you did it, especially if they ask questions about your team, how long it took you to build that version of the software, etc.
Again, extract problems not the implementation of the client.
There is an effort to educate the CEO on product building, and on sales too. Ideally, they'd be selling what you already built and you would be prying open business use cases to find underlying problems to build for, and then sell that too.
Ideally, meetings should involve both sales and engineering. The decision to build is taken after the meeting, which is to gather information.
And ideally, the CEO should be selling your existing features of which state you are ashamed, and trying to get a price for them that almost no engineer would dare to ask.
> it doesn't feel like I have any say when it comes to how I spend my time and energy
and conclude that you are asking for advice on how you can both can do Executive Functions.
------------------------------------------------------------------------------------------------------------
Emotional advice:
1. Say to yourself, "This is hard. This is worth it. We will carry on through." or something in that spirit.
2. Embrace homeostasis.
A company is made of living humans responding to an environment. There is no "finally land and support a big customer". There is no big-bang refactor that cleans everything up. There is no "finally do the demo that gets things to be 'Good'". The company will always have endless series of problems until it dies.
Breathe in. Breathe out. There is no final destination. The path just goes on.
3. All paths have endless problems, but there are better and worse paths. Choose the path with the problems that are more rewarding (personally and financially) to be solving week-by-week.
4. Embrace the discomfort of risk with balance. Neither lose yourself in it nor try to escape from it. https://www.youtube.com/watch?v=7hx4gdlfamo
Oh, and both continually grow in the practice of setting boundaries and avoiding self-deception. (Warning: this can also be hard)
------------------------------------------------------------------------------------------------------------
Directly actionable advice:
1. Write "Q4 2020" at the top of a whiteboard.
2. Draw an X and Y axis. Label the Y axis "Impact" and the X axis "Effort"
3. Get a bunch of notecards and magnets/stickytack.
4. Write each business outcomes on one notecard. Phrase these as capabilities "User can do X" or "CFO can quickly report Y".
5. Get a huge number of Green and Blue dot stickers.
6. Every business person in the room puts a green dot on a notecard if they have a way they would observe the revenue/conversion/sales/risk impact within 2 weeks of the feature/outcome going life.
7. Every engineer in the room puts a blue dot on a notecard they feel confident in their ability to estimate the effort of doing it.
8. Plot the notecards on the Effort and Impact axis in comparison to one another.
Argue. Endure the discomfort of arguing. Do not agree to disagree unless you think you're only 20% out-of-alignment or agree to take the notecard off the board.