Ask HN: What do non-technical founders need to know about software dev?
I myself am a freelance developer and I regularly work with non-technical founders to bring their ideas to life.
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
59 comments
[ 212 ms ] story [ 2548 ms ] threadSalesforce.com is a great case study, they executed with great discipline, fot a huge amount of funding in the first year
https://www.crunchbase.com/organization/salesforce/company_f...
and they’re famous for resisting customer demands to change the way they do things. Instead they developed a model for customers to run their own code inside their platform, access it through an API, etc.
There’s another idea which fascinates me that I’ve rarely seen executed well which is to develop something that is a hybrid of custom and prepackaged software. I worked at a place that had developed in the early 2000’s a packaged web site for wineries to sell wine online and when I went driving around the finger lakes (where I live) I would always see the signs of wineries who were our customers. Despite having a few things like that the company struggled financially and collapse under the weight of technical debt. (For one thing they depended on a proprietary language called Tango which let you build web sites with an interface like Scratch. I told them they ought to hire a CS intern to help write their own Tango implementation but they weren’t ready to do so.)
The authors of this book
https://www.amazon.com/Software-Factories-Assembling-Applica...
wanted to make this happen. They were in charge of the enterprise version of Visual Studio and unfortunately it turned out nowhere near as cool as what they speculate about in that book.
I'm reminded how the Airbnb guys would fly to New York and personally take photos for customers trying to rent out their location.
I remember at work someone said they wanted a way to arbitrarily update a SQL table and clobber old values. After some digging I realized they just needed a task to scrape a particular page and throw it in a structured format. Of course when they did it manually they made mistakes and mismapped a bunch of fields
… … …
For Non-Technical Founders:
- Cost, Time, Value: Software isn’t built overnight. Both the timeline and budget are usually underestimated. Key is to control focus on priorities. The MoSCoW method of classifying work as Must/Should/Could/Won't plus a Kanban of ToDo/Doing/Done with a parking lot for Someday/Maybe items is simple but beats most other project management methods. For the iron triangle of Need, Budget, Timeframe, control RoE by fixing team size to the appropriate burn, and adjust throughput by adjusting focus on need.
- 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. Your user has a job to be done. Enable it and get out of their way.
- 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.
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 be a 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.
Software must be maintained:
- The languages it is written in have bugs and vulnerabilities discovered, which means that there are new updated releases.
- The libraries, modules, and dependencies are updated as they too have their issues remediated.
- The cloud infrastructure on which the software runs are also updated continually.
- Therefore you must have people dedicated to maintaining the software.
- The software must be written so it can be updated and maintained.
- The software development practices and tools must also be updated as they also depend upon software that gets updated.
- A significant amount of effort must be dedicated to maintaining the software. If you assign it a lower priority than new features, then you will slip further and further behind. Until a critical vulnerability cannot be fixed due to your software depending on things that are too old, and upgrading would break your application.
- Open source software is used in a vast amount of applications these days. Many corporations just use this software and don't contribute back into it. Just remember that you get what you pay for, and you can't demand that an open source project fix a vulnerability or bug unless you are donating money to the authors and they've agreed to a service contract.
- If someone tells you that you don't need to do these things, they are incorrect for whatever reason.
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.
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.
This is an important point. Don't try to do what Facebook/Google/etc do because you are not Facebook or Google and you don't have a team to support the same complexity levels nor the budget to invest until that point of maturity. Trying to be like the big ones is a classic trap.
I can boot a Ubuntu server for $6/mo for small sites/apps/data projects. No lock in.
That being said, I’m not going to base my entire company’s infrastructure on a small vendor that may not be around or for that matter anything that Google says is the next big thing.
Also something engineers should know: no one cares about your stack. Apply the minimum technology required to perform the task. No customer will go with a product just because it has a particular stack. Make it as simple as possible, but no simpler. Sometimes engineers push over-complicated technologies they are passionate about or want to learn for their own sake. You should be somewhat aware of the technology being proposed and get the input of other engineers when its something that is non-standard.
Also, small teams are WAY more effective than larger teams. Software dev does not scale well at all with people in my experience. If you're constantly adding people to try and increase velocity if you've got it the wrong way round.
Obviously exceptions to this; but a good, well managed small team of 5 people can often out deliver teams many times that size.
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.
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.
- 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.
You haven’t heard of resume driven development?
Or better yet - “we need to use K8s from day one”
> Programming languages, tech stacks, and other areas of engineer preference largely don’t matter
It very much does matter. I can easily and cheaply find a developer who knows and would be glad to work with React on the front end and Node on the back end to replace a developer who leaves.
Some obscure front end framework and Elixer on the back end - not so much.
This is a dangerous statement. Some tech stacks are way more complex (and therefore more expensive) than others. You need to choose wisely what you use, because whatever you put in production will stay with you for at least 5 years (thumb rule...) and rewriting is a pain.
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.
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.
- 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.
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.