Ask HN: What do non-technical founders need to know about software dev? | Hacker News Reader

Ask HN: What do non-technical founders need to know about software dev?

41 pointsaosaigh57 comments

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

View on HN

Code is a liability. Anything you choose to build requires continuous maintenance and care. Fixing things in the design stage is 100x easier than in production. Vigorously debate whether you should build something at all. If you can get something off the shelf that is well maintained and well supported, that’s usually the best option. Old and boring technology is the safe bet. Don’t get distracted by shiny objects. Continually ask yourself what your customers want, and validate those assumptions. If you’re not 100% sure, it doesn’t get built until you are.

tl;dr: the best kind of software is no software at all.

With tools like zapier and fivetran, you can build out a mini backend and data pipeline without having to think about servers or software.

But... you do have to think about subscription fees and vendor lock-in.

I can boot a Ubuntu server for $6/mo for small sites/apps/data projects. No lock in.

For an early stage start-up I don't believe that matters. If you have success after the first couple of years, you have the luxury of time to decide what gets built to replace it. If you don't, well, at least you didn't waste time on code that wasn't the core of your business.

You’re always locked into your infrastructure at any type of scale. I’ve worked with large VM migrations that took a year to migrate and still had issues.

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.

And so begins an interesting philosophical conversation: is that actually less software, or is that more software pretending to be less software? I lean towards the latter, given past nightmares working with tools from the "we hide all the code behind a dank web UI" genre.

Case in point: Facebook, Instagram, TikTok, etc.

This. Software are there to solve problem. Not to create more problems. If there's a problem, try figuring out a way to solve it without software first. Only use software as the last resort.

I agree with all this. I would also add that you should avoid complexity. If you can't explain it to an engineer or you need a lot of arbitrary branching logic (the engineer will tell you), its probably not a wise decision. When engineers complain about complexity, it's not because they're lazy, it's because they know complexity is a liability and usually un-intuative in the UX. This is related to adding features as different features may interact with other features or add complexity as to what it is your product actually does.

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.

Yes totally agree with old & boring. Be very cautious if your developers keep suggesting new technology choices, which depending on your field is probably anything that has came out in the past 5-10 years.

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.

This is extremely accurate. Code is very similar to a loan for which you need to make periodic payments.

My advise is reading the comment above carefully ^^^^^

At the same time, "build vs buy" isn't always as straightforward as it sounds. You can easily end up doing a lot more work to integrate a bought component/service into your app and customize its functionality to do exactly what you want vs just building a much simpler version. I've seen companies blow many hundreds of engineer hours and thousands of lines of code on integrating with some SaaS, dealing with API changes that were out of their control, that could've just been a hundred lines of code written in an afternoon for a simpler version that handled everything they would need for years to come. You have to actually consider the tradeoffs and what you're getting for your money.

Software is open-ended in almost all practical scenarios. This means that it is never 'finished' or 'fixed', always prone to new vulnerabilities, performance issues and deprecations. There is no set-and-forget.

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.

This is very much what I wanted to say. Software and the cloud are never static or fixed in place. Never.

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.

Many non-technical people like to look at things that already exist and interpolate or extrapolate. "Well Facebook does this", "well I can buy GTA 5 on a shelf at Walmart for $60 (or something)", "people do this, I see it" and they have no idea of the level of effort and investment behind these things, they assume because it exists and is affordable you could erect something competitive or some similar feature set for marginal cost.

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.

"Facebook does this"

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.

- Software is usually more complex than you expect it to be.

- 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.

On the process note, I’d say your best process is automating processes. Any sort of process that requires active thought is a huge effort sink. This is why so many devs hate Jira. It’s process that can’t really be automated.

> 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.

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.

"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."

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.

SaaS isn’t consultancy and jumping through a million hoops for a single customer probably isn’t going to work when it comes to selling the software.

So very true. Now try arguing this point when there's a bird in the hand...

It’s particularly difficult if you’re in the place where your product isn’t well developed and you don’t have product-market fit.

Salesforce.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 built a successful SaaS business for 12 years (~2,000 customers). Never once did we do something for a single customer. User consensus should drive your roadmap.

I worked at what was supposed to be a "SaaS", and the founder was always promising custom features. He sold the product to one customer where it was not a fit at all and had to cancel the contract. (Their use case would've required an entirely different product.)

Isn't this contradicted by "do things that don't scale"? If you have a product and product market fit, I agree. But when you start out you should basically be a consultancy and build the product around the actual needs of the customer.

I'm reminded how the Airbnb guys would fly to New York and personally take photos for customers trying to rent out their location.

They did the same thing for everyone though (until they figured out how to scale that thing). It's not wrong to do whatever you got to do to get your first couple customers but you should also be thoughtful on how it's going to impact your company. For example, our second customer wanted us to do a deep integration into their erp system to sign on for $2k/mo, instead we did an audit of their current process and saw they were doing manual imports and exports. We gave them import/export capabilities which still greatly reduced their daily manual work and has been a longstanding, heavily used feature. They're still with us and both their revenue and the account has grown over 4x.

100% agree. Don't ask customers for solutions, ask them for problems. If they knew the solution to their problems, they wouldn't have problems. They would often suggest solutions that are round-about or overly complicated.

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

Bugs happen, it doesn't mean incompetence. letting your team know the impact of the bugs in production is helpful but breathing over their necks or throwing a tantrum when you have an impactful bug is not. Tell the team, make sure they're working on it and give them space to breathe.

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.

You need to maintain some slack to be able to react to change quickly. Driving your developers at max capacity will bite you. You want them to have some spare energy and time.

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.

I worked as a freelance Python dev and worked on developing a few MVPs.

- 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.

If you work in the same office, telling them about "the zone" is a must: https://softwareengineering.stackexchange.com/questions/4625...

I recommend reading Fred Brook's Mythical Man Month. It's old but still has relevance and has been republished this century.

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.

But one woman can have 9 babies in 9 months!

I don't follow. What species of females are you hanging with? :-)

Maybe an unpopular opinion but I think it's reasonable to ask a non-technical founder in a software startup to learn to program (basics) by going through one of the online courses and roughly understand the stack. So if the product is based on Django...either go through a Python tutorial or even better a Django one. Yes it will be strange and uncomfortable but I think it's a good idea to have this level of understanding. Understand how your technology works in general terms but specific to your product. For example if it's a web app with an API, roughly understand what happens when someone surfs to the website (request-response model, how do REST APIs work, what is a database and why is it used).

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.

Most people have no appreciation for just how much work it takes to actually finish software.

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.

On a higher level, software development is a process of converting unknowns to knowns. We can't estimate or act upon what we don't know; as we uncover details, we can more accurately gauge level of effort and what the best solution is for the problem at hand.

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.

A successful team is a team, with roles, not a random collection. Obviously any project will involve different technical specialties. Some people are better at early design and core coding, others at filling out that skeleton, still others at debugging or testing or things that enable either. Your most productive programmer is very unlikely to be great at leadership or even mentoring - which are themselves not quite the same thing. You need people who are enthusiastic about every new technology and people who would rather stick with the tried and true. You need all sorts of balance along with the psychological safety that allows people to be different and have disagreements without losing trust in one another. I've seen "superstar" teams absolutely fail, and "journeyman" teams absolutely fly, strongly correlated with whether management understood what "team" means.

Almost all complexity is hidden under the surface. If X was easy, and Y looks like X, that does not mean Y will be easy.

My recommendations:

* 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 junior people 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

I wrote a bit about this as well:

https://logical.li/blog/team-capacity/

https://logical.li/blog/hype-trains/

https://logical.li/blog/seven-traits/

The notion of "non-technical" for the "non-technical" cofounder of a technology company is dramatically more technical than the notion of "non-technical" for the general population. A useful non-technical co-founder is at least a technology power user, and probably actually someone who could write code that will kind of work most of the time in a language designed for encouraging children to program such as python. https://www.python.org/doc/essays/everybody/

Some lessons on software development were learned a long time ago, but have not really sunk in everywhere.

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.

If you're doing something novel, it is more or less impossible to estimate when it will be done. Progress will usually be slow, with bursts of extreme productivity after a breakthrough.

Without a sales and marketing budget your product is doomed. There are very few exceptions and very few companies with the funds to burn on a product that is not marketed.

* Not all software dev is the same; if you're building something new then that's much more risky. * Track the risk as well as any dates - a section that still has the same date but has suddenly got less certain needs watching. * You split it into separate parts - good; now make sure you leave plenty of time for integration and testing as you bring the parts together. Do it regularly. It always goes wrong.

Cost increases exponentially with complexity. Things like React/reactive programming are there to slow the slope down, but don't aim to make a "superapp" or "platform" unless you really have to. There's a reason why startups do so well vs companies like Google who hire the best engineers on the market - they just focus on a really narrow scope.

You touched on an important one: managing expectations. Secondarily, this also means being a good communicator with non-technical people; i.e. being able to translate technical concepts (and their importance on the work being done) in ways the stakeholders will understand, and help to adjust any ideas they have over the work ("why isn't this easy?").

I'm a senior full stack dev, freelancer. I'm switching to AI consulting and bot development and building sites using tools like framer because it feels like a lot of the time we over engineer things and the future is embracing AI especially for lead based business like real estate, insurance, home service pros, etc.

Everything is easier and harder than you think it will be.

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.

“Build it custom,” should always be the last resort, when off the shelf tools have failed. Don’t be penny wise and pound foolish: $200/mo for some tool or service may sound like a lot at first, but that’s 1-2 hours of developer time.

For this topic I recommend book called Shipping Greatness. The book has different sections for non technical people on how to work with engineers and how to work with designers.

A few things both sides often overlook:

… … …

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.

I'm an experienced nontechnical cofounder. Good advice in this thread so far but I wanted to weigh in with a verrrry clichéd pointer: that a lot of friction around expectation management, program management, resource management, etc. gets a hell of a lot easier if you have rapport and can be candid with each other.

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.

Reply on news.ycombinator.com