Rome wasn’t built in a day and neither were the tech products we have all come to know and love. At the turn of the 2000s tech was still in its infancy; it wasn’t unheard of for apps to crash constantly, to suffer from severe lag time and have very little compatibility across operating systems. Over two decades later, we are lightyears ahead in terms of the usability and durability of tech software.

Today, it’s easy to get caught up with perfecting any product, and it’s something we see at Skillwork every day working alongside founders, executive teams and development teams. 

We all know that there is no such thing as perfect, however expectations from customers and end users are at an all time high, leaving little room for mistakes, especially in both healthtech and fintech. Now, this is understandable, you are dealing with people’s health and finances - two areas we can all be assured will exist no matter who we are and where we live - but what this does is create a sometimes untenable environment within teams. The reason for this - a miscommunication and misalignment on the intended goals.

So how can you make your working environment during periods of intense work, much more effective with communication right from the start of the project, all the way to the end?

First principles

Schedule in your first meeting, invite everyone who needs to be there and ensure that each person understands the reason for their attendance and what expertise, materials or data they might need to bring to the initial kick-off meeting.

Before this meeting takes place you will also share your one-pager around. Although we will get into why you shouldn’t over-document later in this piece, it is important everyone knows what is going to happen. A one-pager outlining the following is very helpful: 

1. What are you building;

2. Why are you building this;

3. Who is it for;

4. Your current competitors;

5. What you hope the outcome will be for the business - in short, why should we spend money on this?

This will not encompass everything and that is okay. This is to encourage questions and brainstorming at this initial stage. By the end of the meeting, what you will hopefully have is a clearer idea as to what the expectations are. Even if you have pivoted slightly from the original idea, or you need to have further meetings to get everyone working in tandem, you’re on the right track.

Why a one-pager?

Every word counts and each sentence needs to be useful. 

The concept of a one-pager, also known as an executive summary/one-pager, is worthy of its own section for so many reasons. It’s similar to an editor telling a writer that there is not enough space to include the whole story in a physical paper – you only need to include what is necessary to ensure that the story is told in a compelling, factual and comprehensive way.

First, if you cannot simplify the project down to one page, then do you really know what it is that is being asked of you? Yes, you will need a lot more space to go into competitive analysis, the tech stack and how to go to market, but at this stage, the goal is to get everyone on the same (one) page(r). Everyone needs to be able to concisely explain what is expected of the team and what the benefit is to the company and the end-user.

Secondly, executives, founders, and just teams in general are time-poor and do not need more work to read or go through. If you wanted, or if asked, you could include more information at a later stage.

Set some rules in place

Big tech companies have many quirks when it comes to meetings, documentation and communication. 

Your project should be no different. 

Some ideas include, meetings that are 25 minutes instead of 30 minutes (or 50 minutes instead of an hour), no meeting-(insert day here) to encourage deep work and a one-pager to be shared around 24 hours prior to a meeting. Other ideas include, an allowance for meetings to be rejected if there is no agenda in place, or if a person feels they will not be useful in this particular meeting, and no calls or texts on personal/work phones after 6pm unless in an emergency -- and define emergency.

These rules should be outlined and understood by everyone from the beginning. Even if there are slip-ups in the first week or so (totally understandable), this should be ingrained into everyone by the end of the first month.

Streamline the tools you are using to communicate

Here’s something we can all empathise with: more tools does not necessarily equate to increased productivity. In fact, it can be a killer especially when you’re trying to collaborate with executives who are already bombarded with information.

The key is to streamline your communication tools by only choosing one primary communication tool (your single source of truth), two at a push. If there are technical reasons to do so (Jira may have more engineering-focused functionality, an area that email, Slack or WhatsApp lack), make sure it’s integrated with your main communication platform.

Make sure everyone uses the desired tool consistently, and avoid cross-communication over several different platforms. The goal is to reduce friction and make it easy for everyone—especially the busy execs—to stay in the loop without needing a treasure map to find information.

Accepting that emotions will arise

Entrepreneurs, engineering teams and just about anyone working in tech will know that although very difficult, to work effectively as a team, you will have to kill your ego.

When you start out building anything new, no matter how level-headed an individual you are, emotions start to emerge; think of it as a tech-induced emotional rollercoaster. 

Right at the start, excitement kicks off this new wave of feelings, there will be anxiety about the unknown, defensiveness if someone tells you something is not possible, disappointment when you realise they might be right, and then hope and determination kicks in to find new solutions to fix any hurdles. All of this, and we haven’t even begun building!

Understanding that your emotions might lead your decisions, and others opinions too, is healthy to recognise right at the start. It will help you come back to a few simple questions each time: why am I making this decision right now? Do I need to have an answer this minute or shall I sleep on it? What is leading this decision - data, our clients, our end-customers or is it my own opinion?

Working with senior members of the team

When navigating complex discussions with leaders, boiling things down to the most basic truths and building up from there will work in everyone’s favour. When you’re working with executives and founders, they’re often juggling big-picture visions with the nitty-gritty details of execution. By breaking down challenges into first principles, you can cut through the noise and get to the heart of the matter quickly.

For example, if the CEO is pushing for a feature that seems technically impractical, instead of simply saying, "It’s not possible," start by identifying the core problem they’re trying to solve. Maybe there’s a simpler, more efficient solution that aligns with both the technical capabilities and the company’s goals.

Kill your need to over-document everything

Documentation is important, no doubt. But let’s be honest—there’s such a thing as too much of a good thing. When you’re working with executives and founders, they’re looking for high-level insights, not a novel-length exposition on the backend architecture. Over-documentation can bog down decision-making and waste time.

Instead, focus on creating concise, actionable documents that highlight key points. Use bullet points, summaries, and visuals to convey complex information quickly. Reserve detailed documentation for the technical team, where it belongs. When you present, think of it like serving a tasting menu—just enough to get the point across, without overwhelming them with unnecessary details. It’s about being thorough, not verbose.

Speak up

Last but by no means least, speak up. If something is not understandable, it doesn’t matter what position you’re in, you should ask your question. You should live by the rule - there is no such thing as a stupid question. You don’t know if others may feel the same way until you do. You may also have misunderstood a point (meaning that it is potentially not as clear as the project manager/author would have hoped). Think of it this way: you’re the specialist in your domain, and the executives are looking to you for guidance. Your input can steer the project in the right direction or prevent costly mistakes. So, step up with confidence and share your insights—after all, you’re in that room for a reason.