Save over 40% when you secure your tickets today to TNW Conference 💥 Prices will increase on November 22 →

This article was published on October 19, 2020

4 common mistakes people make when scaling their HR and finance systems

Scaling your business presents exciting opportunities, but you need to do it carefully to avoid burning up resources and crushing employee morale. Here are four lessons on scaling that I learned the hard way.


4 common mistakes people make when scaling their HR and finance systems

This article was originally published by Built In.

Rapid growth in a startup or small business is both exciting and daunting. Your team’s ability to bring a bit of order to the chaos can be the difference between flaming out or effectively scaling to become a household name. You will face decisions about whether to build, borrow, or buy your way to the next level. If your organization is like my last company, then you want to remain laser-focused on your customers and delivering them a high-quality product or service. That’s why we decided to buy off-the-shelf products to meet the needs of our back office, and we ended up learning a lot of lessons along the way.

I spent two years sifting through white papers and product demos for just about every HR and finance SaaS tool marketed to early stage startups. We were disrupting the laundry and dry cleaning industry through a convenient pick-up and delivery service. We had raised several rounds of venture investment, launched several markets, and scaled our team to over 120 people. Our rapidly growing headcount and geographic expansion pushed our beginner-level, “startup friendly” tools to their limits, and it was soon time for us to professionalize our HR and finance systems.

Although we believed that technology was going to give us a competitive advantage over our rivals and enable us to scale quickly, we made a lot of mistakes in implementation that distracted our team and burned key resources, neutralizing much of our advantage. We implemented an expensive HR platform, and everyone hated it, so we scraped it before our first annual renewal. We spent way too much money on consultants to help us restructure our finances only to revert back to the same process we had before. These missteps added up and we were soon spending an inordinate amount of time exploring new software instead of focusing on our customers and growth.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

An old saying observes that “Smart people learn from their own mistakes. Wise people learn from the mistakes of others.” Hopefully, you can learn from my example and avoid these four big mistakes when you’re thinking of scaling your back office.

We let urgent problems crowd out important planning

At first, we were able to get by with some tools that are fairly common among seed-stage startups. As we grew, though, we started to hit the limits of either the system itself or our specific pricing plans. These urgent fires required quick action, and so we set off to find the best SaaS solution for our new problem. Our process was quick but fragmented, and we always seemed to chase just one more feature or tool that would really unlock everything. We had no broader strategy guiding our choices other than fixing the immediate problem so we could move on to extinguishing the next fire.

Solution: First things first: Assess the business’ needs and determine whether you want to use an all-in-one platform or custom-build a suite of SaaS products. If your organization is complex, and you have specialized needs, you can build an elegant Rube Goldberg machine, but only if you deeply research and plan first. If the company’s organizational structure is simple and headcount is low, I would recommend prioritizing simplicity and keeping the budget small. The key here is to not let the urgent get in the way of the important, and remember to be thorough in assessing your business’ needs. Doing so will prevent more emergencies over the long term.

We lacked a coherent data strategy

We fashioned ourselves a disruptive band of innovators taking on an industry that hadn’t updated in a generation or more. As such, we believed that adoption of technology and data-driven decision-making was our competitive advantage. Yet we didn’t have a comprehensive data strategy that detailed the types of data we should collect, its sources, or how it would be leveraged to inform decisions. We ended up with software that either didn’t capture the types of data we needed or couldn’t connect to our business intelligence tools.

Solution: Build your data strategy as a required subcomponent of your overall business model. At a minimum, your data strategy should include a detailed description of your KPIs and their component pieces as well as a corresponding data dictionary explaining the common definition, source, and the use case for the major pieces of data you plan to collect. This should be a living, cross-functional document that serves as a reference for any team that is looking to add new software. You will also need to include any requirements from the engineering team relating to APIs, webhooks, and SDKs.

We didn’t have a structured decision-making process

We based our decisions on pretty standard criteria like budget, value propositions, and features. Our diligence was thorough and deliberative, but our decision-making lacked structure. Some people on the team pushed for an all-in-one platform while others preferred to cobble together a custom solution out of many apps. Our discussions became anchored on this one facet of the decision, and we accidentally de-emphasized the importance of APIs and integrations. We didn’t stay true to our initial business needs assessments and ended up with software that wasn’t doing the job.

Solution: Build an evaluation scorecard based on the value you want delivered and be specific. Your evaluation criteria should be attached to a simple scoring system (1-5 or A-F) for quick comparisons. Next, you need to get creative and build different variants of your back office tech stack and then compare them. Your goal is to build options that are distinct based on your scoring system. For instance, you might prioritize the value of APIs in one course of action whereas budget takes precedence in another. Once you have three to five options, you should present the choices to a broader group to elicit feedback and ensure you’re not missing a key point. Then the process is as simple as scoring the different courses of action and selecting the software that scores best.

We didn’t have enough executive oversight 

We signed a year-long contract with a big “all-in-one” HR platform that had a massive impact on our engineering, ops, and HR teams. Despite its integration into so many areas, the transition to the new platform wasn’t in the top five priorities for any executive at the company. Everyone had higher priorities within their own functional areas, and no one was assigned the responsibility to ensure that the acquisition and implementation were successful. Without that oversight, the roll-out date caught everyone by surprise, so we rushed the rollout of a clunky piece of software that everyone despised. We spent a lot of time and money doing little more than hurting the morale of the company; within months we began searching for a replacement, but the damage was done.

Solution: Assign an executive sponsor for any major new system implementation and hold them accountable for the selection, integration, and team training for the new software. If the system touches multiple departments like HR, finance, or business intelligence, the responsible executive needs to put emphasis on collecting requirements from each department and then making sure the integrations work smoothly.

Final thoughts

Hyper-growth companies are exciting! The constant change and evolution present an endless stream of challenges and opportunities. Selecting back office technology is often an afterthought in a hyper-growth company, and that’s understandable. There will come a time to focus on scaling, however, and at that moment a founder or executive should prioritize the successful implementation of new software. Heed the advice of John Wooden, who won 10 NCAA titles as the head basketball coach at the University of California–Los Angeles:

If you don’t have time to do it right, when will you have time to do it over?

Whether you are building, borrowing, or buying back office software to support rapid growth, I encourage you to take it seriously, invest time in analyzing your business needs, and maintain focus until the new software is fully integrated into your company. You won’t regret solving this problem right the first time. I hope these lessons will allow you to build a plan for scaling your back office software with minimal distraction to your company so that you can continue to focus on your customers, products, and growth.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Also tagged with