Being happily "bad at maths" is a thing. Some people boast about it. Some folks just glaze over. The same is true of tech literacy. Some people just shut down when programmers start speaking. So, how can you start a big tech business, if it's all ones and mostly noughts to you? The truth is that most tech companies are not founded by programmers.

So what do you need to know about software development?

Software development is NOT the process of writing computer code. It is the process of changing a vague idea into a detailed specification of what to do in each scenario.

80% of the work is answering the "What" questions. What is the problem? What are the users’ needs? What could the solution look like? What are the edge cases and variations? What are the potential problems and errors? What should we do in each error scenario? What are the regulatory requirements? And what are the business and user priorities?

Only 10% of the effort and time is solely in the domain of a programmer. How do we compose code that does what we want? How do we handle resource allocation? How do we ensure the solution is secure, resilient, and scalable?

This means that 80% of the development work is open to you. You can get involved. You should get involved.

I just said that you can do 80% of the software development. So, why don't we just do all the planning, answer all the “what” questions ourselves, then hand over a detailed requirements spec to a cheap offshore development team, give them a month, and expect a perfect implementation to pop out?

Technical term 'waterfall'

There is a snag.

Even if you are a certified genius it is unwise to assume you know everything. No one can answer all the “what” questions in advance. Donald Rumsfeld said it best — “there are the known unknowns and then there are the unknown unknowns.”

If you really know your domain and have lots of experience building applications, you will be able to come up with an answer to many of the "What" questions — your known unknowns. So, why is it wrong to jump in two footed and build as much as you can?

Firstly, you are still working on the assumption that there are users and customers who think and work exactly the way you presume. Not only does this perfect customer need to exist, but you need to be able to access and convert them from day one. Building a whole application based on this unvalidated assumption is an enormous risk.

Secondly, because you are trying to pre-empt all potential scenarios, or because your developers are trying to prove their skill, experience and intelligence. It is inevitable that effort is spent discussing, designing, building, testing and then maintaining implementations for events that never or very rarely occur.

The solution to these issues is simple and obvious. But it requires you to change your mindset and accept uncertainty in advance. For some, this can be a hard shift, especially if there are voices trying to influence you to commit to a large project.

Rather than planning a large all-in-one project and intelligently pre-empting issues. You wisely accept there are unknowns and that you don't know how far you will get or whether your ideas will work. Rather than over-committing, you take small steps constantly checking you are on the right path. Rather than working on everything everywhere all at once, you focus on what is most beneficial right now, what lands your first customer, what convinces your next investor, or what mitigates the largest risk.

Dear reader, I congratulate your attention to detail, 10% of effort was lost like a wraith to the ether. Imagine the consequence, if that missing 10% is you describing your idea to the development team.

Let's start small. In the simplest setup, how I imagine you and most founders start.

There are 2 main communication links. Your users/customers to you, and you to your development team. As you scale you need to bring in more people with different roles, Customer Relations, Product Owners, Sales, Marketing, Developers, Testers, etc.

At each link, there is opportunity for "errors" to creep in. Something can be missed out. Something can be misunderstood. Something can slip in. Something can be re-interpreted. But each person and each layer can also bring the opportunity for improvement, new ideas and interpretations, checks and balances. You want to avoid organising the team as a long chain of hierarchical top-down instruction as errors compound like Chinese whispers. Instead, you should aim to organize as spokes around a hub of shared understanding and ensure that there are no timid voices unable to break through. Get as close to the developers as possible, allow developers to talk directly with users.

Everyone on the team needs to appreciate that people bring different roles, skills, strengths, and abilities to the table. Communication only works when it's clear and accessible to everyone. Using technical terms or business jargon that others don’t understand isn’t clever — it’s counterproductive.As the Head of Engineering, I’ve experienced both sides of this dynamic. Junior developers have looked up to me, assuming I always have the answers. I’ve also had to prove myself in front of directors and leaders of large organisations. In either case, I’ve learned the value of saying, “I don’t understand. Can you break it down for me?”

If you don't understand something, it is not because it is too hard or too technical, and it is not okay to ignore it and move on.

When things don’t make sense to you, the reason is usually the explainer doing a poor job, assuming you know far more, or inadvertently missing things out or not setting the context enough. But quite often the reason something is not gelling in your brain is that you’re subconsciously detecting a hole, a conflict or some issue that has gone undetected or been glossed over. Simply asking the team to break it down often uncovers the friction point.

When it comes to collaborative problem-solving, nothing beats gathering your team around a whiteboard. It is fast, shortens all your comms chains and involves everyone's opinions. However, the output is ephemeral, easily forgotten and hard to interpret when looking back from some future event. And in today’s world of remote work, physical gatherings often aren’t practical or scalable.

Source code is the ultimate unambiguous concrete medium. However, it is slow to produce and inaccessible to a wider audience.

Modelling is the sweet spot between these extremes. A picture paints a thousand words, they are accessible to the whole team, can be shared and collaborated on remotely and can neatly balance capturing explicit concrete detail while being quick and easy to produce and maintain.

One sage rule of thumb I live by is, if the diagram looks messy, the design is poor.

It is very easy to get caught in the flow of your own work, or to be influenced to take on an idea by people trying to be helpful, or just doing what you think is right and necessary, all of these can divert you from your true aims and objectives or add unnecessary delay. You need to build an understanding of how even the smallest most trivial of tasks naturally grows and has consequences beyond its borders. To stay on track, you need to maintain control — both of yourself and your team. Recognise when your team has ferreted deep into the warren so that you can draw them out and refocus on your immediate goals.

A small idea grows with detailed elaboration. Dependencies are identified that themselves may need elaboration and have the potential to grow. Edge cases emerge where some subset of real scenarios don't quite fit the expected pattern and may need cajoling to conform, filtering out or even building their very own bespoke scenario. Failure modes and what-ifs are considered (be wary of over-engineering). Every change begets improvements, tweaks, related ideas, embellishments and user requests. And so, the snowball rolls – it picks up more and more, and continues to roll.

Engineers frequently overlook complexity and unknowns, or have a more constrained interpretation of the task therefore giving overly optimistic estimates. And when things do go wrong — as they inevitably will — the extra effort required is not a small fraction of the task time but a massive multiple. e.g. what starts as an afternoons work can easily snowball into a week-long task.

Managing the runaway snowball requires constantly bringing everyone's focus back to the current immediate goals with regular check-ins.

Is this task part of the original plan, or has it grown beyond the initial scope? Is it truly essential for the current goal, or can it be de-scoped, deferred, or split into smaller parts so that only some parts need immediate action?

Please do not underestimate how easy it is to follow the path laid at your feet and walk miles past the sign post to your destination.

This last section nicely rounds out this article as it circles us right back touching on Elaboration, the benefit of taking many small steps in an incremental iterative agile Approach and how your Communication Structure and Design Tools enable you to maintain control whilst unlocking your team's potential.