5 learnings when building and scaling a service-based tech company
- Gregor Ojstersek and Ales Cadez from Engineering Leadership <gregorojstersek@substack.com>
- Hidden Recipient <hidden@emailshot.io>
5 learnings when building and scaling a service-based tech companyBuilding and scaling a service-based company is totally different than a product-based one, here are the main learnings!
Senior Engineer to Lead: Grow and thrive in the role (2 days left to enroll)It’s getting close to the start of the January’s cohort-based course. It’s going to start in 2 days. In the course, we particularly focus on the development of much needed people / communication and leadership skills in order to grow from engineer to leader. If you are not enrolled yet, you have 2 days left! Looking forward to seeing some of you there. Let’s get back to this week’s thought! IntroI’ve done a lot of freelance projects for clients over the years, from building web, mobile and all the way to desktop apps. That has enabled me to gain a lot of experience in a short amount of time. I thought about scaling the operations and actually go from me, working on such projects to expanding and creating a service-based company. But haven’t made that jump and rather focused on progressing in my full-time roles. For everyone thinking about potentially doing that or you already have a (service-based) tech company, this article is going to be a great read for you! I recently met with Aleš Čadež for a coffee and we talked about many different things, especially regarding the challenges a company and also engineering teams face when scaling. I’m happy to have him on as a guest author today. I’ve asked him to share his 5 main learnings on scaling a tech company with us. Aleš is a fellow Slovene and the Co-founder & CEO of Kaldi → a service-based tech company that builds digital products from discovery to scale. Let me say a few words about the company before we dive into Aleš’s learnings. Kaldi went from 5 to 35 people in 5 yearsAs mentioned above, Kaldi is a service-based tech company from Slovenia and they particularly focus on building products for clients (mostly startups & scaleups). The company was founded by two engineers, who dealt with the pain points of scaling and in recent years went from 5 to 35 people altogether in the company. People in the company are in the fields of engineering, product design and project management. This enables them to have all the necessary experts to build products based on the client’s needs. And building + scaling a service-based company is quite different than a product-based one. It’s a lot less predictable and you can’t just quickly expand the operations. Now that we know a bit more about the company, let’s get into particular learnings. Aleš, over to you! Learning #1: Focus on vision and align strategy to itImagine a scene where two engineers who like working on interesting and challenging projects start a business. The only “vision” is to “work on such projects”. Soon, they have too much work and they hire a couple of colleagues/friends. Everyone is working hard, coding and building fancy features on projects that “come around”. Recipe for the happy life of a bunch of engineers right? Not so much. Soon these questions start comming up:
Through the mixture of pure luck and reading a lot of books, we stumbled upon a book “Traction: Get A Grip On Your Business” by Gino Wickman and it’s Vision Traction Organizer (aka VTO) → A canvas for setting the company vision, strategy and short term goals. It has helped us to make a step forward and finally start thinking about what we’re actually building. We (two co-founders) spent evenings and weekends thinking and talking about what kind of company we actually want to build. Once we aligned and wrote it down, it became so much easier to make decisions (still a lot of wrong ones). Learning #2: Understand & align business goals with clients
That’s why it’s important to find the alignment between you and the client. You can do that in 3 steps:
Use the initial alignment meetings to really understand the client and ask the right questions. Try to thoroughly understand their pain points and motivation behind their needs. That will position you as a business partner that understands the business at the high level.
Make sure that the client understands why you’re going into this relationship and what particular things are you offering. Make sure that the expectations are clear.
When architecting the business relationship, try to find common goals when preparing the proposal. What outcomes are a success for both parties? Book recommendation for negotiations and finding common goals: “Getting to Yes” by Roger Fisher and William Ury. Learning #3: Understand what you’re sellingThere are a lot of service-based companies out there. But are they all selling the same thing? In general I believe there are four types offerings:
This model works well if the client is only looking for additional people, doesn't need any outsourcing particular expertise and has people management under control.
There's a full-stack team and there's a project that needs to be delivered from start to finish. It has a fixed budget, fixed timeline and what needs to be delivered is clear (or at least management & team are under the illusion that it's clear). This fixed-price model works best for software projects that repeat the existing, predictable functionality (e.g. rewrite of the in-house accounting system).
Usually consists of a team of engineers and project manager(s), but other roles (design, product management, budget management, etc.) are either outsourced from other companies or internal. Roadmap prioritization, process analysis and improvements and everything else is managed by the vendor.
There's a full stack engineering and product design team available, but the key difference to the software development team is that the product management & project management are part of the offering. More specifically, the company provides two core team members that dictate the direction and tempo of product development. As a service-based company, your client portfolio will probably consist of all these four types of engagements.
For us, it was the love for being at the heart of designing & building new products, so we’re all in Product Development. It’s rewarding but also probably the hardest type of engagement to build as it requires in-depth relationship and trust with the client. Learning #4: Product before EngineeringHere’s a hard truth for all hard-core engineers → I spent years thinking that everything starts and stops at scalable, reliable and secure code. It doesn’t.
We spent the last five years building a strong product design team and combined it with the well defined development process. The added value it gives to the products we help build for our clients is amazing and it has helped us to actually become a business partner (and not just an outsourcing agency with great development capabilities). There really are countless book recommendations regarding product design, but one that stuck with me is “Inspired: How to Create Tech Products Customers Love” by Marty Cagan. Learning #5: Trust your gut feelingHere’s a controversial opinion based on so many decisions I made that were “right” on paper. Consultants, books & managers will also often tell you that you should base your decision making on analysis, excel spreadsheets, interviews, data, etc. But when you do that and the decision on paper looks dead set, but you just don’t “feel it”, trust your gut instinct.
So, in what cases you should apply that gut feeling? I don’t know for sure, but I do it for hiring, deciding which client to work with and especially for all decisions that are urgent but not mission critical (check the Eisenhower Matrix to understand the importance and urgency of tasks/decisions). I have no book recommendation for this one. If any of the readers has any good ones, please share it in the comments below. I would love to read more about that. My takeaways from Aleš’s learningsGregor here again. Thanks to Aleš for sharing his learnings with us! Here are my 3 takeaways from Aleš’s insights:
Spending time to really understand the wants and needs of clients and making sure to map them to your solutions will provide great outcomes. You’re not just providing a service, you’re building a partnership.
This is what I always advocate for and it’s great that Aleš has also mentioned it. Great and scalable codebase alone will not provide success.
You can’t just “be the best in everything”, picking your focus ensures that you create the best outcomes and develop expertise. Last wordsThanks again to Aleš. Make sure to check him out on LinkedIn and also check out Kaldi. If you’re looking for a partner in developing your next/current product, definitely reach out to them! We are not over yet! What’s next after Senior Engineer?Together with Caleb Mellas, we wrote an article for his newsletter Level Up Software Engineering 🚀 It’s about what’s available out there after you hit Senior Engineer level (Hint: your career has just started!) Liked this article? Make sure to 💙 click the like button. Feedback or addition? Make sure to 💬 comment. Know someone that would find this helpful? Make sure to 🔁 share this post. Whenever you are ready, here is how I can help you further
Get in touchYou can find me on LinkedIn or X or Bluesky. If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com. This newsletter is funded by paid subscriptions from readers like yourself. If you aren’t already, consider becoming a paid subscriber to receive the full experience! You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc. You're currently a free subscriber to Engineering Leadership. For the full experience, upgrade your subscription. |
Similar newsletters
There are other similar shared emails that you might be interested in: