Introduction

It’s well known that the primary reason an employee leaves an organisation is poor management and a lack of growth opportunities. Numerous studies, like this, highlight the significant impact managers have on employee health and career development.

Especially after COVID, with remote work becoming the norm, traditional management styles no longer suffice.

So how does HighLevel, being remote-first, manage engineering and product development?

And how do we ensure that engineers are effective in their work?

How do we provide the necessary support and direction to enable our teams to move quickly and release the required features for customers?

Let’s talk about it.

It starts from the top

From the beginning, our co-founders worked remotely, and they couldn’t have done it without trust and accountability. These qualities became foundational at HighLevel and set a model for everyone to follow.

This drives individuals to self-manage their work. Each team member focuses on improving the product. Once the vision and goals are defined, the team divides the tasks, aligns them with key deliverables, and assigns work among themselves.

The principle that the product serves the customer first sets the priority for feature releases. We engage with early adopters and power users, gather feedback through the ideas board and support tickets, and use this information to shape the roadmap.

In short, this process sets a cadence for gathering feedback, understanding customer needs, and defining roadmap priorities. We refer to this approach as the "Skateboard Model," which we’ll explain in detail in later sections.

From 10s to 100s of engineers

The philosophy of self management might work with a handful of engineers, but does it scale?

As our team expanded, staying aligned with the right objectives became even more critical. Traditional work-tracking methods often don’t scale well and can make teams feel micro-managed.

We grew by working on new initiatives and products. However, we kept our team size small (typically around 2-3 engineers) to preserve the self-management model. The team’s output remained focused on enhancing customer experience and delivering the right features our users requested.

Early engineers who learned from the founders set the right cadence for the teams, providing a guiding light for newer members. This helped replicate the model across the organisation as we scaled.

💡 The Skateboard Model—launching products with small teams that understand their users and competitors, releasing frequently, and gathering feedback—helps keep the process agile and scalable.

Goals and Ownership

Skateboard Model

Let’s dive deeper into the Skateboard Model.

Let’s understand it by an example. Say a person wants to commute from A to B.

Imagine someone needs to commute from point A to point B. Ideally, they would like a car, but building one takes time. While we work on the car, the person can’t travel.

Instead, we focus on solving the core problem: Getting from A to B.

We build a skateboard—a much quicker and cheaper solution. While users aren’t thrilled, it solves their immediate problem. As they use the skateboard, they request improvements like more speed. So, we build a bicycle.

Over time, we gather feedback, like requests for protection from dust or a music system, and ultimately build the car. But this time, it’s based on what the user actually wants—not what we think they want.

This iterative process lets us build products with the customer’s feedback in mind, constantly improving while ensuring adoption and growth.

Why this model for Product Development?

Skateboard Model solves two key challenges in product development.

1. Achieving Product-Market Fit (PMF)

2. Driving Growth

Let’s look at an example. In March 2020, when COVID-19 hit, there was a sudden shift toward online learning. This presented an opportunity to create a platform for online creators to share their work and make money.

Here’s how we approached it:

1. We spoke to multiple existing customers to understand their needs.

2. We researched competitors and the market.

3. After identifying core features, we developed a roadmap.

4. Using a familiar tech stack, we built an MVP (minimum viable product) in two months, including:

   1. A Course Creator App for products, lessons, and sales

   2. A Course Learners App for signing up and accessing course material

We launched quickly, gathered adoption, and received tons of feedback, which allowed us to release enhancements in the following weeks. Our customers saw that we listened to their feedback, and that engagement drove more suggestions.

This helped us align the roadmap with customer needs, which led to both adoption and growth.

With continuous iterations, we added more features and onboarded more users, all while ensuring a smooth user experience at every stage—whether it’s the skateboard, bicycle, or car.

You can read more about the Skateboard model here:

https://medium.com/@byrnereese/the-skateboard-mindset-in-product-development-ddf3409d5e98

💡 Skateboard Model → Build with the customer, not in isolation!

While this model sounds cool for a MVP, how do we plan further once we have adoption?

Roadmaps and Sprint Planning

Detailed view of SDLC at HighLevel

Once we have adoption, we need to focus on long-term growth.

The product milestones are planned into quarterly roadmaps.

The product milestones are planned into quarterly roadmaps. Product Managers develop these by considering various sources:

1. Ideas List https://ideas.gohighlevel.com/

2. Competitor Analysis

3. Support Feedback

4. Backlog

These tasks are then divided into sprints. We follow two-week sprints, focusing on priority tasks while also tackling technical debt and support tickets.

During sprint planning, the engineering lead works with the team to assign tasks and ensure everyone has a balanced workload.

Here’s a breakdown of sprint points:

Sprint Points Time

1 <2 hours

2 4 hours

3 1 day

5 2 days

8 3 days

13 1 week

Sprint planning involves collaboration between PMs, engineers, and other stakeholders to ensure accountability and ownership of deliverables.

Manager of 1 and Bias to Action

At HighLevel, every team member has a say in the sprint planning process, fostering a sense of ownership. Engineers manage their own work, ask questions, and collaborate with their leads to make informed decisions about architecture and priorities.

This creates ownership, as engineers are responsible for ensuring their work adds value to the user. HighLevel encourages a bias toward action—small, continuous releases followed by feedback—and lets results guide the next steps.

💡 Build accountability and ownership.

HighLevel is Action Biased. We can plan all day but if we aren’t delivering something or working on the problem at hand then there’s no meaning to planning. Rather than anticipating what’s going to work or not, we incline towards action and put out the smallest piece of work out and then take in the feedback. This helps keep the ball rolling and with iteration we are bound to find success. Rather than having long meetings and discussions around the best way possible, we tend to move forward and then let the results decide the next move.

Reviews and Retrospectives

At the end of each sprint, the team conducts a retrospective to evaluate:

1. How the time was spent during the sprint

2. Any spillovers

3. Whether sprint points were over- or underestimated

4. Key learnings from completed tasks

This reflection helps the team adjust strategies, plan future sprints, and ensure they are improving with each iteration.

Pointers considered during retrospectives.

Do we have lot of adhoc tasks coming?

A lot of tickets reported lately?

Are we underestimating the amount of work involved?

Feedback and 1-1s

Even though our engineers excel at self-management, regular feedback and one-on-one meetings with managers are essential to align with the overall roadmap, company vision, and to address any concerns.

Most teams schedule 1-1s every two weeks, although some may do them weekly or monthly depending on the need. Regularly scheduled calls ensure they aren’t missed, and notes are documented in a shared space for future reference. This provides a safe space to discuss concerns, potential red flags, and performance issues before they escalate.

If performance starts to slip, managers discuss it early and provide constructive feedback to resolve the issue. Timely feedback prevents situations from snowballing into performance problems that are difficult to reverse. These conversations also help align long-term career growth with organisational goals.

💡 1-1s form a critical piece of managing performance, career development, and creating a feedback loop with the team.

Growth and Learning

Continuous learning and growth are key to ensuring each team member expands their skills and advances in their career.

At HighLevel, every team member is allocated an annual $400 learning fund, which they can use for courses, certifications, or other learning materials.

We have partnered with MongoDB and Google Cloud to provide regular training sessions and online courses for ongoing up-skilling. Additionally, we host monthly internal “LevelUp Dev” sessions where different teams share their experiences and challenges. These presentations allow knowledge sharing and offer insights into different architectures across the team.

Final Thoughts

Empathy, empowerment, collaboration, and equity are key principles at HighLevel. These values keep us moving forward, building products with our customers, and scaling efficiently. Instead of guessing what the market needs, we let our customers drive our product roadmap.

One of our core missions is to become a $10 billion company, with $9 billion of that going into our customers’ pockets.

HighLevel empowers every team member to innovate, iterate, and deliver products that make a real impact.

If you’re ready to join a team that’s redefining software development, check out our open positions at https://jobs.lever.co/gohighlevel