Hey there 👋 I would love to learn more about your thoughts on onboarding software engineers and the challenges you're facing in your company. If you can spare 30 minutes of your time, I'd love to chat with you! Just send me an email!
How many SaaS applications do you use frequently? If you're working for a medium-sized company, chances are, that your number of subscriptions ranges from tens to hundreds. So many, that you wouldn't know which tools people on the other end of your org are using, with dozens of inactive subscriptions that drain budgets.
This situation has gone from novel to normal in the past couple of years. Combined with a steady trend of choosing specialized tools that do one job very well (e.g. Linear) over suites that offer everything but end up unable to provide the best experience in any special use case, this led to increasing fragmentation of services used.
The average company uses more than 100 different SaaS applications, so we're not talking about a hypothetical anymore, in fact, to remedy this situation we've seen a whole new category of SaaS spend management / budgeting products emerging (ironically adding more SaaS tools to your stack).
Do you know where to find your service logs? Metrics on system health? Documentation on one of your internal services? The design draft presented for an upcoming feature? The one bug a customer reported and a team member notified you about? In short, a lot is happening in your organization, and if this is extended by another dimension of tools you are using, you can quickly lose track of what goes where.
For most tasks you'll work on, there are a lot of services to choose from. Deciding if you should use standalone services for monitoring or use the integrated systems of your cloud provider isn't trivial. I mean, if we're using Slack all day, couldn't we just pipe all alerts and errors into there?
While this might work fine for some time, you'd quickly notice that searching becomes painful, you have a constant stream of spam, quickly transforming your idea into a nightmare.
So sticking with this example, how about we decide that all data related to monitoring, logs, and observability should be handled by one service? We're also past the point of engineering it in-house, as we want to focus on building our product instead of thinking about petabyte-scale log ingestion, so we'll happily take this opportunity.
Performing this kind of orientation process for all areas of your business where you're considering implementing a new tool will force you to think about different alternatives, opportunities to reuse existing tools, and find the best fit for your company.
It's also worth noting that there's no shame in reusing software. As long as it serves its purpose and makes sense for you, go for it! We want to decrease friction while making sure everyone knows which tools are used for different tasks. Ideally, we want to make use of the best tools while being completely mindful of our infrastructure.
To conclude, feel free to use the best tools available to you, but make sure there's a reason for using them, if there are inherent benefits of reusing an existing tool or if that would create more work than necessary, and make an informed decision. Don't try stacking up your SaaS stack like it's Tetris.
This takes us to the next point. If we know which services we run, we can communicate which software can be used, detect if we have expenses without actual usage, make sure to cancel those orphaned subscriptions, and build our stack.
While we briefly covered a new kind of product emerging, focused around monitoring SaaS spend and detecting what you invest your budget in, there's a lot of software we use for free, one-time licenses, or expenditures not covered by this software.
Even if you consider adopting some spend management software, how about starting a document to collect which tools are actively used?
How about creating and maintaining a list with tools, use cases, maybe even people using it so your team knows who to ask (don't overdo it, though, people don't want to spend their whole day as tech support for the service they tried once)?
This way, anyone on your team can check out what to use when, and if anyone ever asks you where that budget went, you'll have an overview of which subscriptions are active, can cancel those that aren't, and finally feel in control.
By the way, you're not restricted to applying this exclusively in a company context! You can monitor which tools you're using personally as well, and I'd strongly recommend doing this. Not only because it's basic budgeting, but also because you want to know where you put your data. Let's have a look at the list of tools I'm using regularly, and the exact use case:
While we've only got a list, we can extend it with active subscriptions, more service-related information, and think about if we can or should reorganize parts of our stack. Knowing you've got a problem is the first step in fixing it.
As one more point, let's think about how we want to enforce boundaries between different services. We might have picked each service with a clear use case in mind: A wiki for sharing product-related knowledge, a cloud provider to deploy your code to, and so on.
For documentation on internal code I noticed repeatedly that the closer your documentation is to your code, the better it will be maintained, and this way people actually leverage it. If your documentation is archived in a drawer at the other end of the organization, do you really think anyone would use that?
Reducing friction means having clear processes in place. Do I need to assemble a list of our inventory? Goes into the company knowledgebase. Am I filing a support ticket a customer opened via email? Straight into the issue tracker. Any documentation on the library we want to share across services? As close to the code as possible.
Once you discussed and decided on the workflow most comfortable for your team, put in some effort to create the systems to assist you in the long run. And don't let things rot: Any outdated information can be disposed of, if it's not important anymore, you don't have to carry it around with you.
Maintaining company-internal systems, whether it's different services or processes, is a lot like regular chores. If you manage to create a routine, track the software you're using, and keep your team informed about what's available, ask what is no longer needed, and everyone, including your bills, will thank you.
Thanks for reading this post 🙌 I would love to learn more about your thoughts on onboarding software engineers and the challenges you're facing in your company. If you can spare 30 minutes of your time, I'd love to chat with you! Just send me an email!