Scaling up a Developer Team with Confidence
How We Are Using the MeteorJS Platform to Grow with Low Friction
Typically when you start a new tech business you will sooner than later have to make a decision about your technology stack for building solutions to solve your customer’s pain points. No matter if you are starting an agency or a SaaS business you have to find solutions for the following challenges:
- How are you going to handle authorization/user management?
- How is data stored in the backend?
- How do you handle frontend/backend communication?
Of course there are a plethora of choices to answer each question and they all come with a certain degree of technical debt. Therefore it is important to validate your options as early as possible. At kromit, we made a decision early on and are still using it to this day while keeping up with the latest industry best practices. It is important to find a platform which is open and allows you to scale — I have summarized my experience and learnings of bootstrapping a company from zero to ten employees below.
Too Small to Fail?
I started my business as a one-man-show and scaled it to 10 full time employees and would like to summarize my startup keys to success. Of course your mileage might vary depending on what you are working on or what you are trying to build. The most important advice I can give is to keep costs low in the beginning. This might be obvious, but there are many areas where you can save costs in the beginning — most importantly office space, but also infrastructure and salaries.
Next it is important to grow organically. For us that meant very slow growth in the beginning because I was also aiming for a 1–1 ratio between senior and junior developers, this is an approach that worked very well for us.
In order to be able to grow organically, it is, of course, important to start selling something. This can be a product or service. Ideally you have some expertise in the area so you understand your customer’s requirements and only build what you know (or at least think) you can sell.
In retrospect, it was crucial for our success to decide on one technology and stick with it. This decision helped us to keep our technical debt and onboarding efforts low while focusing on quality and delivering solutions in time and budget. The MeteorJS platform turned out to be the perfect fit for our use cases because it is extensible by default (you can use any npm package) and the MeteorJS project team — both now and then — are always trying to keep the platform up to date with recent best practices. Besides the technical benefits, we are able to set very specific requirements for our recruiting process which helps us to find new talent to grow our team on demand. Using different technologies and stacks would prevent us from optimizing and streamlining our processes further and would be a limiting factor for reaching our strategic goals.
If you reach the point where demand from your customer’s exceeds what you can supply with your team, you have to switch gears and invest to keep growing.
Keeping it Simple
Everyone looking for employees will probably agree that finding talent is hard. When it used to be job applicants who had to try to stand out, this has shifted to companies these days. Firms need to demonstrate what makes them a different and attractive place to work versus the competition.
You can of course always compete through salary but that’s not everything people are looking for. Work-life balance and developer experience are becoming just as important. These and other attributes should not be neglected, both for finding talented developers and even more, for keeping them happy in your company.
After several years of trial and error I have concluded that keeping it simple (not stupid) is key to a great developer experience and a happy developer team. There is always room for improving performance, tooling and adopting the latest hyped technologies but at the end of the day the more complexity you add to your platform the more difficult it becomes to onboard new developers.
Onboarding New Team Members
As mentioned before we have made certain technology decisions very early on. This is definitely not a one-size-fits-all approach, but it works great for us. On the one hand we are fully invested in the Apple ecosystem where we recently moved all developer laptops to the latest Macbook Air — Apple silicon is a real game changer in terms of performance. On top of MacOS, we build all our applications with the MeteorJS platform. Unlike many in the community, we still use BlazeJS for the frontend and are very happy with its capabilities. To put this into perspective it is worth mentioning that we are building tools which are used by hundreds of concurrent users and not thousands so we are rarely facing performance issues in the frontend.
With this setup we have basically eliminated the “but it works for me” phenomenon because everyone is using the same hardware and software. The biggest advantage of this environment is that we can do end-to-end on-boarding of new employees until the first LOCs can be written and committed in less than half a day. This already includes the provisioning of all accounts, basic setups and everything else needed getting up and running.
Dealing with Seniority Levels and Engineering Bias
If you are heavily invested in a technology stack it is important to get everyone in your team on board. As a leader you are expected to make decisions and have a vision for the long term. Adding senior talent to a team can be challenging if they do not support your decision and/or vision for the future. It is easy to get side tracked in technical discussions about alternative technologies or solutions. This does not mean you should be ignoring constructive feedback, you should always be open to criticism and improve your processes but discussions about decisions made are not going to move you forward. Depending on the problems you are trying to solve it might be more productive to hire junior talent and train them according to your validated processes and best practices. If you have great processes, onboarding and tooling in place it is even worth considering hiring according to business requirements background rather than technical expertise.
So far, my experience showed that everyone can learn platform specific skills or best practices if they are documented well. Besides documentation, it is important to put some kind of mentoring in place where junior developers always have the opportunity to reach out to clarify questions. We started this process rather informally, but have formalized it earlier this year to be able to better plan the necessary workload on senior engineers by organizing weekly dedicated review meetings in addition to ad-hoc support. These review meetings have to be prepared by the junior developers before every meeting. This has provided a couple of benefits for everyone involved:
- The mentoring workload for seniors can be planned and measured more effectively
- New hires can be sure they always get dedicated and focused time from their mentor because it is blocked in their calendars
- Junior developers get an early sense of responsibility by preparing an agenda and questions for a time-boxed meeting
- Having an agenda and questions prepared beforehand reduces the overhead for senior developers
We will continue to grow our team by hiring junior developers based on the positive experience with our current onboarding process and I can only recommend at least evaluating this approach before putting that “10x developer” requirement on your next job posting. Yes, it is true that junior developers require more time and investment in terms of training but it might very well be worth putting that into perspective when compared with a senior developer’s salary.
How the Platform Influences Team Organization
In a team no matter what size, everyone has different levels of expertise in different areas. Even a full stack developer who is firm in frontend and backend development might not always have a specific knowledge of certain business processes.
We found speaking the same language from a technical perspective — in our case JavaScript — helps level out and supports interdisciplinary teams. Since the MeteorJS platform is opinionated it also removes some of the burden of making technology decisions. For example, the backend database pre-couples MongoDB to MeteorJS, so it unburdens the developer from having to make the decision about what storage technology to use. The whole stack, from front-end to back-end queries, is written in one language: JavaScript.
Probably the biggest advantage from a business perspective is that using a unified, single-language stack allows us to make very accurate effort estimations for our implementation projects. Very recently we introduced an internal effort calculator which will hopefully help our junior developers to make more sophisticated estimations early on. The calculation logic is based on years of experience building applications of different complexity levels.
Beyond Seven Figure Revenue
Today, we are a team of ten and will meet our milestone of seven figure annual revenues by the end of this year. It was a rocky road to get there but we are not stopping here. With a solid foundation of processes, guidelines and a capable technical platform we are working to extend our current services portfolio with SaaS offerings to expand our customer base. Despite the expected economic downturn we believe that we can keep our current growth and extend the team further next year. We are also planning to increase our investment in the open source space by dedicating a full-time employee to our open source projects. While this might not yield an immediate return on investment I believe this is a long-term investment in the open source future of the global economy.
Going All-in on the MeteorJS Platform
Committing can be tough especially when you are just getting started and feel like you have to justify everything you do. The truth is however, you don’t have to — at least not if you are running your own business or managing your own team. People are actually expecting you to make decisions and deal with the consequences (both good and bad). Usually you will know sooner than later if a technology works for you and your team.
The MeteorJS platform was the obvious choice to meet all our needs when we started off back in 2015. Many other platforms and frameworks have appeared (and vanished) since then but we stuck to our decision. MeteorJS allows us to ship quality code to our customers on time and on budget. To put it frankly that’s probably all that matters if you run a business and want to be successful in the long run.
One of the main lessons we learned over the years is that no successful project stays unchanged. This is why we are using MeteorJS even for the smallest customer projects because you simply never know what might come next.
What really helped us validate MeteorJS as a platform was our choosing to write all internal tooling with it. This has multiple benefits, especially in the beginning. Most importantly, it helps to keep costs low while increasing your whole team’s platform expertise. Don’t get me wrong, there is no point in reinventing the wheel — if there are already tools out there which work for you then go ahead and use them!
As a practical example, here are some of the tools we use internally which are all using MeteorJS under the hood. For all internal communication we use a self-hosted Rocket.Chat instance. It addresses all our requirements for chat and notifications while keeping our data on-premise and GDPR compliant! For the management of our agile implementation projects we use Wekan, also developed using MeteorJS and offering everything you can expect from a modern kanban board. Again we are running it in our own infrastructure to keep customer data safe.
One of the most critical requirements we have as an agency is project time tracking because this is how we make money at the end of the day. We could not find any existing solution which met all of our requirements so we decided to build our own and make it open source and available for everyone on GitHub. This is how titra started back in the days in 2015. Today the titra repository has 311 stars on GitHub and 533k pulls on Docker hub.
Using other tools and solutions can be really inspiring for all the things you build yourself so it is only fair to give back to the open source community.
Guidelines and Processes
Once you plan to scale up your business and increase the number of employees you should already have validated guidelines and processes in place. In the beginning processes may feel like a slowdown or limiting factor. But down the road, if applied correctly, they act as a productivity multiplier.
For us, a low-barrier internal wiki was key in establishing these processes and keeping guidelines and examples up to date. The best content does not help if it’s not kept up to date and this can only be achieved in collaboration with the whole team. Since not everyone is familiar or comfortable with markdown, I highly recommend a WYSIWYG editor. Our future perspective in this regard is to take it one step further and move to an interactive wiki like runme.dev which allows you to execute commands on your local machine. This could be yet another game changer for our already efficient onboarding process — just imagine you can send someone the link to such a wiki and they can just run individual snippets like ‘npm install’ step by step on their development environment until it is fully set up. As an alternative, we are also exploring the introduction of GitHub Codespaces, but this has the downside of not working offline which is a problem especially if you are traveling.
The key learning for me was that it is of utmost importance to document everything — never make any assumptions about other people’s knowledge and always start from zero. More experienced developers will just skip the introductory part and continue with what matters for them. But it is really valuable to have your workflows well-described so there is a consistent reference to share knowledge and minimize finger-pointing later.
While documenting as much as possible is important, it is also worth mentioning that there needs to be a distinction between a process and guidelines or examples. You have to identify must-do tasks and only these make up a process, otherwise you are putting a straitjacket on your team which really limits its performance. As a consequence, everything else in your day-to-day business documentation shall be considered as guidelines and/or examples. It should be well understood by all team members that processes must be followed whereas guidelines are only recommendations or proven best practices to help execute a certain task.
Benefits of Interdisciplinary Teams
Our unique selling point at kromit is that we don’t hand off between different (customer-facing) roles. If we start a new customer implementation project, the customer will always work with the same person from the concept phase until the go-live and beyond.
To be able to support this whole lifecycle, everyone on our team needs to be capable of handling requirement analysis, project management and development. Our internal guidelines cover all these different areas to get new hires up to speed quickly. With such interdisciplinary teams it is important for us to be able to focus on building sophisticated solutions and this is where MeteorJS as a platform really helps us to stay on top of our technical debt. The platform has been battle-tested over a decade and is easily extensible to fit any customer requirements thanks to the support of every NPM package in the JavaScript ecosystem.
If you are making a technology decision, it is important to validate if it is a good fit for your specific requirements. The questions you should at least try to answer are:
- Is the technology/framework/platform capable of meeting all currently known requirements? If not, how much do you need to invest to “make it fit”?
- How well is the technology suited to meet future (unknown) requirements i.e. does it scale?
- How long is your time to market when using the given technology? (The shorter, the better — try to be honest with yourself and include all incurred efforts)
- How much technical debt (e.g. vendor lock-in) do you introduce?
Answering this simple questionnaire might provide a new perspective on your next technology decision. The latest hype technology might not always be the best fit, especially if you are planning to support an application for the long-term. On the other hand it is also worthwhile to continuously validate existing technology decisions to make sure they can keep up with the latest best practices in the industry.
Open Source and Open Core
As mentioned above, not only is our technology stack based on open source software, but also most of our internal tooling as well. Needless to say that we embrace open source as a company and try to give back to the community wherever possible. Unfortunately we cannot share everything due to intellectual property (IP), but we can always extract our learnings and best practices and build them into our open source projects. I strongly believe that open source is the future of software development as a whole and we will keep investing into this direction in the future.
TLDR;
By using the MeteorJS platform inside and out, we provide high quality services in the area of project portfolio management to our customers. With a mature platform, we have reliable tools for building sophisticated and secure business applications with different levels of complexity. Our fullstack interdisciplinary experts have the whole view of the applications built rather than silo expertise. This enables us to focus on delivering solutions rather than making technology decisions and fighting technical debt over and over again.
About the Author
Fabian Kromer started his consulting agency kromit in 2015, mainly to be able to call his coffee breaks executive meetings. Today Fabian is managing a team of 10 at work and 3 at home with passion and perseverance.
