I feel like matching the expectations of your client or partner is crucial in the beginning of a project.
It’s important to lay out the groundwork, process & technologies while not including the tedious details. Communication is key etc etc
I’m keen to uncover my blind spots and see what other HNers with experience in similar circumstances think is most important when working with non technical business owners and founders
This then impacts everything else, from requirements to budgeting, from compliance to performance and everything in between.
So when you manage expectations, that would impact how you'd define something as 'done', and how you'd include contingency planning for example.
More often than not, because it is never really visible to the layperson, time and money stops flowing and software just 'sits there' until something goes really wrong. The responsibility of that lies with the business owner, not with the software engineering or technical departments (when money and time are not allocated by the business part, that is).
In a way, you'd need to be a marketeer, a PR person, a communications expert, do sales and financial risk advisor just to set the right expectations when time and money are traded for software. This is also something that almost never works out in reality, so that's a bummer.
… … …
For Non-Technical Founders:
- Cost and Time: Software isn’t built overnight. Both the timeline and budget are usually underestimated. Key is to control focus on priorities. (MoSCoW method of classifying work as Must/Should/Could/Won't plus kanban of ToDo/Doing/Done with a parking lot for Someday/Maybe items is simple but beats most other project management methods.)
- Scalability: While a quick MVP (Minimum Viable Product) is important, consider whether the tech stack used will allow for growth.
- Quality Matters: Bad code can work in the short term but can lead to expensive fixes later. It’s like building a house on a shaky foundation.
- Updates and Maintenance: Software isn’t a ‘build and forget’ entity. It needs regular updates and potentially costly maintenance.
… … …
For Technical Founders:
- Business Goals: Keep in sight why you’re building what you’re building. Tech is a means to an end, not the end itself.
- Speak the Language: Get good at translating technical jargon into plain English. Don’t assume the non-tech founder understands your lingo.
- Flexibility: Non-tech founders may change course based on customer feedback. Be prepared to pivot without getting too attached to your code.
- Validation: Always validate assumptions with real-world data. And wrap all systems with Observability. Think of it as Test Driven Ops. You can only safely "move fast and break things" if you know exactly what you're breaking when, so you can resolve it before your customers experience the breakage.
… … …
Mutual Blind Spots:
- Minimum Desirable Product: Shipping that MVP is fun, but make sure someone will pay for what you’re making. A powerful technique is to survey customers for whether they can make do without the product. More than 40% need to say they can't operate without it.
- Communication: Both parties usually think they are communicating enough. They’re usually not. Set regular check-ins.
- Documentation: Neither side loves it, but both will need it. Clear documentation can prevent a lot of misunderstandings.
- Roles and Boundaries: Establish who has the final say in what domain, and even more importantly, practice accountability. Power struggles can kill startups.
- Prenup / Exit Strategy: Think about what happens if one of you wants to leave the startup. It’s not fun to consider, but essential.
Under managing expectations, you need to have a little heart on heart and try to bring some reality to the ideas. People don't come up with ideas in a vacuum, they look at inspiration from examples, connect things, add/remove them, and mutate them.
I've also worked with a lot of engineering disciplines outside of software and people think because something is virtual in nature (it is "just software") it's significantly easier or cheaper than doing things with real physical capital. That isn't always the case. They also assume it's significantly easier in general, it's not civil engineering and you're not building bridges. Sure, you're not, and software isn't as commited as concrete in some senses but that doesn't mean erecting it or changing it is free, as designing and altering design for a bridge isn't free either. In the past year I've has someone handwave a theoretical issue as "it's just math" to some underpinning needed that has essentially remained an unsolved problem in mathematics for 60+ years...
I could go on... but the most important aspect is to talk through the ideas and try to find any empirical evidence you can to get people to understand the level of complexity, scale, and amount of capital groups commited to make something they think is trivial and only need a handful of SWEs and a few months to throw together as if it were a PowerPoint that can handwave reality away.
Here's how a conversation – that could turn into a huge argument – can go if you're candid with each other. I chose this conversation because it happens all the time and if handled incorrectly can be nuclear.
CEO: "Board says we need to launch by the 1st."
CTO: "That's an unreasonable timeline given our current resources – but here's the ways we COULD hit that deadline."
CEO: "Okay, so either you need a) more time, b) a deeper bench, or c) expectations adjusted with the board."
Note how they both provide possible solutions to the conundrum they're in, and neither is about who said what or who fucked up planning or whatever. Solution oriented, we're both in this together, here's how we get out of it. The only way you get to that pragmatic, candid level of conversation is if you both trust each other and know that the mission is bigger than either of you.
When you have a small team, those after-work drinks or lunchtime xbox sessions or that #dankmemes Slack channel become super important in building that rapport and subsequent trust.
Push for move fast and be understanding when things break, especially early on.
Every feature you add will add a ton of future maintenance, so don't do custom work for every new customer, it will bury you over time. Do proper customer development and include your technical co-founder when you want to consider a new feature.
If they're nontechnical, they may not care about how it's done at all, but they will care about timelines. They may have agreements with others that depend on the product, or may have stakeholders they need to communicate with.
As developers we usually focus on our direct communication with the business owner, but I think it's helpful to imagine the second order communications that will result from how we communicate progress on our technical solutions.
For example, if we convey confidence to get a certain piece done by x date, the founder may in turn pass on that confidence to shareholders. But if we later backtrack after realizing that it will be a bigger lift than expected, the founder may have to walk back those expectations.
- Software complexity is proportional to the number of engineers working on it. Hiring more people will increase complexity. So, hire as few engineers as you can get away with to solve the problem.
- There will be bugs. It’s inevitable. Blaming people will only make things worse. It’s possible to mitigate the problem with process (and that process assumes that there will be more bugs but streamlines how you resolve them).
- Programming languages, tech stacks, and other areas of engineer preference largely don’t matter. Let engineers pick what they want. Remember that the good solutions are often free and have stupid sounding names.
My favourite: "It takes nine months to have a baby no matter how many women you put on the job."
His failure on the OS for the IBM 360 mainframe led him to believe software is like that. It's worth the read.
2. Anything is possible, but there are always tradeoffs, so make it very clear what is important - "what does success look like".
3. There are 10000 small decisions to make. These do not need assistance or discussion, simply clear direction. See #2.
4. To increase speed, removing friction is better than adding power.
It’s easier because humans tend to overcomplicate matters, when usually the simplest thing will probably suffice until you have serious demand for something more complicated.
It’s harder because once you decide to do something simple, humans have a strong impulse to overestimate what they can do in a day, a week, or a month. I call this the sandwich principle.
Making a sandwich is easy - you probably know the steps by heart. So, how long would it take to make 500 sandwiches?
Using your gut, you might not think an answer like 2 hours is off. But if you do the math, you realize you’re probably way off. This is because the simplicity of the task fools us into thinking it will also go quickly.
Focus hardcore on outcomes, and define your metrics of success early (and redefine them over time). Hand these things to your product owners and engineers, and ask them to deliver a new version of value as often as possible. Listen to your tech leaders when they start talking about rebuilding and refactoring, and ask them if there’s a way to do it Little by little.
Take everything in small increments, even if you have big vision. You can still do it little by little, and you’ll learn more and get the value curve going much faster that way.
Also, have some indirection between "what I want" and "how to build it." Let software people manage the software.
My last non-technical cofounder did neither of these things. He always wanted to-the-hour estimates, granular checklists so he could "see progress," and he would prescribe implementation and write pseudo-logic instead of focusing on business need.
Part of that last part was he was kind of a control freak. If things didn't turn out as he expected, he would complain and it would take a whole debate to convince him the minutiae he wanted weren't worth the cost.
I left that startup several years in. Well before we really got anywhere. That's the other thing about software developers. You are managing them and telling them what to do, but turnover of the wrong people at the wrong time hurts.
- There is no one-time investment. Some clients think they only need to pay once, and it will work indefinitely. However, things break all the time, and clients sometimes forget that tech companies have software developers with regular salaries to continuously fix things.
- Adding features is not easy; devs must get accustomed to providing an overview of the investment required to bring a feature to life
- Contractors are not partners. Contractors bring the client's idea to life, they are not responsible for the business success.
- Contractors are temporary; documentation is forever. Client's need to understand the value of good documentation and onboarding material. They need to compensate you for that. When you conclude the contract, client's require these documents to onboard the next person. Developers are not wizards; they need guidance to comprehend someone else's code.
- There are numerous variable factors, such as hosting, version updates, policies, etc., that regularly cause things to break. Software is not written in stone; metaphorically, it is written on a long sheet of paper with the other end on fire.
- Get used to drawing diagrams and explainer docs. You need to break down your ideas and process to the client. They need to know why they are paying for, or else they might chose a riskier proxy variable "the financial success of the project".
- Get super good at writing contracts. Most of my fuckups happened due to me not having a good contract.
- Free consultancy to attract a client is good and all, but if you are required to "birth an idea from the client" charge an initial consultancy fee.
Last but not least, all these points are good and all, but sometimes when projects are far and in between, you might have to compromise on some of them. That is just the sad truth.
Fred Brooks was a project manager on IBM's project to launch the System/360 from 1961 to 1964. He took on the responsibility to do the operating system software for the System/360 - OS/360. There were problems during the project of writing the OS software and lessons learned. Ultimately the System/360 (and OS/360) launch was successful, and the product sold well.
Brooks wrote a book on the experience in 1975 called "The Mythical Man Month". One of the things the book covers is how a software development project can differ from other kinds of projects, so business should have different expectations.
One lesson is if a project is running late, adding additional programmers to the project tends to make the project even later.
Another is the second-system effect - that a follow-up to a successful project can be an attempt to reinvent the wheel, which is too complex and with too many features (just keeping to the operating system example, Windows Vista and Hurd could be seen as two examples of this).
Another is to "design one to throw away, you will any how". Inevitably for any good product, the software will be refactored or even rewritten.
Some ideas from the book are almost universally accepted. Some are debated, such as whether it is good to have a technical team divided into a leader/architect/"surgeon" and assistants (something Brooks favored) or whether other approaches work. If you read over past comments on this forum, or read other programmers and PM's thoughts, the book is considered to have had a lot of valuable lessons for people over the past half century or so. However, I know for certain that despite it generally being considered a source of a lot of wisdom on software development, many of the lessons are ignored nowadays in companies large and small.
One of the main takeaways though is 60 years ago, Brooks realized software development projects worked differently than other kinds of projects. He put his lessons into a digestible form in his book almost 48 years ago. But even half a century later, many businesses large and small blithely ignore a lot of these lessons.
* avoid hype trains: it is a trap
* avoid complexity unless there is business based justification: it is another trap
* understand that every thing you build needs maintenance
* understand that the integrations you build for something you don't build also need maintenance
* software has many layers: choose where to be disruptive and where to be conservative
* avoid superficial cultural assumptions like "smart good people junior that hug trees will do wonders": you need a couple of pragmatic engineers to impose common sense in the operations
* avoid bogus metrics like "I deployed to production 20 times last month" and embrace sound metrics like "we delivered the features on time with few or none bugs found in production"
* foster an engineering culture: ensure people understand context, tradeofs and relevant metrics
This is because unfinished software and finished software often look/feel identical to non-technicals right up until customers discover the true state of the software and disengage.
If the above is true, then figuring out true customer needs is critically important because creating software that no customer wants is one of the fastest ways to burn money.
Similarly, I'd expect the technical co-founder to stay up to date on non-technical issues and bed-time read relevant marketing (or design) books and get some exposure to these things. Even more so then the reverse I'd expect a technical co-founder to jump in and do non-technical (sales) tasks if required.
Or in other words, roughly speaking...the technical co-founder should be able to make sales and the non-technical co-founder should be able to talk about the product to technical people without sounding like a fool.