Forem: Verena Ermes

Managing Saas for Growth: Insights into the FINN Way

Verena Ermes — Thu, 14 Dec 2023 16:08:00 +0000

In today's economic environment, effective SaaS (Software as a Service) management can be a game-changer. In a series of LinkedIn posts, Andi, our CTO, dove into our SaaS management strategies. Let's take a closer look at these strategies, from welcoming new tools with open arms to mastering the art of negotiation.

Roll Out a Welcome Mat

At FINN, innovation and autonomy go hand in hand. We believe in giving teams the freedom to choose the tools that best suit their needs. This not only boosts productivity but also fosters a sense of ownership and accountability. When individuals work with tools they love, they tend to perform at their best. As shown by the DevOps Research and Assessment (DORA) team, giving teams the autonomy to make tool choices increases the teams’ performance and job satisfaction.

Central Overview Monitored by the CTO Office

As a result of providing autonomy to choose and change tools, we saw the number of SaaS tools grow from seven at the beginning of 2020 to over 80 in 2023. It’s therefore essential to maintain control over expenses. The CTO office keeps a close watch on the SaaS expenditures. Any tool crossing the €50/month threshold automatically becomes part of a central overview monitored by the CTO office. We have developed an in-house vendor management solution that provides the central overview and helps us streamline spending and optimize SaaS investments.

Meet HUBERT: The Vendor Management Solution

Managing contracts for numerous SaaS tools can quickly become chaotic. That is why we created HUBERT, our internal Vendor Management tool. HUBERT centralizes contract information, ensures data integrity and notifies billing DRIs, responsible for invoice upload to our expense management tool, about renewal dates through automated Slack reminders. It enhances transparency and accountability and provides smart spotting of emerging SaaS tools to identify Shadow IT. With HUBERT in the picture, we keep an overview in one place.

Figure 1. HUBERT, our vendor management solution.

Create a SaaS Repository

From day one, we recognized the value of maintaining a complete SaaS repository. This repository, hosted on Confluence, has proven invaluable for various purposes. Whether evaluating potential partners, conducting audits, preparing due diligence inquiries, or analyzing the tech stack, this repository provides critical insights and now too, can be derived from HUBERT. We developed an export functionality to download a sharable view on our SaaS repository.

Figure 2. Our Third Party Services repository.

SaaS Spend and User Inactivity Management

Closely related to the challenge of keeping a central overview of SaaS contracts is the challenge of optimizing SaaS investments. To optimize SaaS spending, we follow a dual approach: Provision ALL, Deprovision FAST.

Provision ALL: We provide new starters with access to the ecosystem of widely adopted tools, reducing onboarding time and fostering autonomy.
Deprovision FAST: By automatically identifying and deprovisioning inactive accounts, we have achieved a 7% reduction in costs (since tracking in July 2023). The automated processes sync with Google Workspace and are based on either user inactivity of over three months or working contract end dates.

A dashboard visualizes the ratio of active to inactive users per tool for better visibility, and the automations help us reduce spending and minimize manual auditing efforts.

The Art of Negotiation

We view negotiation as the big sister of inactive user management when it comes to optimizing SaaS investments. At FINN, we like to approach negotiations playfully with a spirit of sportsmanship. Everyone involved in SaaS negotiations learns these four guiding principles:

Turn Negotiations into a Game: We treat negotiations as a friendly competition, encouraging the Tech Leadership to secure the highest discounts.
Preparation is Key: In-depth market analyses, needs assessments, Requests for Proposal, and decision matrices ensure we enter negotiations well prepared.
Ask for More: The golden rule is to ask for a discount that makes us slightly uncomfortable, ensuring we get the best deal.
Anchor the Deal: We aim to improve the price or get more value for the same cost, resulting in a win-win for the company.

In conclusion, our approach to SaaS management revolves around empowering our teams, centralizing information, optimizing spending, and negotiating effectively. By implementing these strategies, we are following one central Engineering paradigm at FINN: we buy commodities, we build assets.

What are your strategies to manage software as a service?

User Centric Technical Writing: A conversation with Kosara Golemshinska on elevating documentation

Verena Ermes — Thu, 07 Dec 2023 16:10:00 +0000

Documentation can oftentimes come as an afterthought. At FINN, technical writing is set up as docs-as-code approach to be closely aligned with new developments in the Tech teams. But how can you elevate documentation further and ensure that the audiences' needs are served? How do you align priorities and document the most impactful things? We are trying to get answers to these questions and more by sitting down with Kosara Golemshinska, Technical Writer at FINN, who started her tech writing career at FINN and is continuously shaping user-centric documentation.

Hi, Kosara 👋 Thank you for offering to be interviewed. To dive right in, could you explain what your journey into technical writing looked like?

By education, I am a software engineer. As such, I did hear a lot about the importance of documentation, the different types of documentation, and what role it plays in software development. During each semester in my program at university, we worked on a lot of practical projects in small agile teams. I always ended up advocating for documentation, making sure it gets done, and trying to ensure that it was in a proper state. That was sort of the first indication I had that I am really passionate about documentation, managing knowledge, and managing information.

After university, I went into pure engineering roles, and there too, I still ended up advocating for documentation. I saw the impacts that insufficient documentation had on actual software teams firsthand. Especially in my previous role, I looked a lot at test documents. I noticed that the documentation there was in such a format and in such a state that it did more harm than good. That was when I felt ready to make the transition into being a documentarian.

As someone who's always been very interested in the humanities it really made sense to combine both my technical skills and my language and communication skills into one. Luckily, I found the Technical Writer role at FINN. It was a really good place for me to make the transition because of the role’s focus on software documentation. Right up my alley. And yeah, this is how I'm here today.

What is your current view on documentation at FINN?

It is appreciated and needed. I can see that documentation is part of everyone's job. Everyone takes the time to document their knowledge, whether it is on Confluence, Slack, or in a document that they share with others. The idea that documentation should not only record knowledge but also help generate it is widespread. Documentation is used to brainstorm and to align on the next steps before diving into the details. I think this wide recognition is why we have a very diverse ecosystem of documentation.

At the same time, I also see the effort that people put in to maintain their own documentation. They assign a DRI when they create something and this is the person who's going to follow up. They also try to maintain some sort of standardization in their teams, which is really cool to see.

The documentation is as diverse as the teams themselves. There are so many different types of information being created. And it really depends on the roles and the functions that people have. Documentation at FINN is a living breathing creature.

How do you value the impact of technical writing on our products?

At FINN, we view it as an enabling function since the documentation that technical writing is involved in is entirely internal. If we take our API developer portal as an example, it's an excellent resource that is used not just by the engineering teams but also by the product managers and some business roles to understand how to use our APIs. They hold each other accountable whenever they see issues or need clarification. The responsible team that owns that API goes in and updates the documentation. They see the value in it.

That makes documentation a part of the API landscape. The APIs are essential for how we do business at FINN. But that doesn’t apply to just API documentation. We also have pretty extensive business-related documentation, that is often referenced to align on how things should be done. And it's especially critical in our daily operations. For instance, in Finance, where the stakes are always high, documentation is an integral part of how we operate and what our source of truth is. Because if we can't agree on the truth, we can’t do anything. Documentation serves precisely as this source of truth, for all teams.

You have been studying the book The Product is Docs. What are your key takeaways?

I think it's a very good resource. It's not just an introduction but it also has a lot of advanced topics for all sorts of roles. Any documentarian is going to tell you that we do some writing but that's not the majority of our tasks. We do a lot of research, communication, editing, reviewing, and verifying information. That book, The Product is Docs, focuses precisely on all the processes surrounding documentation. It provides practical advice, for example on the process for defining a learning objective or how to communicate with product managers. It focuses heavily on the processes of technical writing and information development. This makes it really valuable to me and I often use it as a reference. I always find something new in it because there's so much practical advice given, which makes it a mainstay at my desk.

Looking at the research aspects of technical writing, how do you perceive the value of leaning into the profile of a User Experience (UX) researcher?

I think there's a lot of overlap. The fields of UX writing, content design, and technical writing you can also call information development and knowledge management. All of these topics are closely connected as their main focus is managing knowledge. They also rely heavily on empathizing with users, doing user research, communicating with lots of different functions, and using common patterns to manage our content and to make things accessible for users. So, I think you can't really do technical writing at an advanced level if you aren't familiar with UX research practices. The main idea is to understand the users, to understand their needs, and to understand how to provide the most value to them. That's what technical writing is really all about.

How do you imagine an ideal rhythm of technical documentation throughout FINN?

It has to be a very scalable way of doing documentation, because FINN is a very fast-growing company. We defined our own documentation strategy to best match the mission of FINN and to best support our stakeholders. We looked at who our main stakeholders are, what their needs are, and how we can support them. Based on that, we defined our mission: to make knowledge a top–tier resource. This is the overarching idea of what technical writing at FINN is all about.

The mission needs to rest on a set of fundamental principles. We defined these as our pillars: documentation should be user-centric, searchable, and accurate. These pillars are the building blocks of our strategy. For each pillar, we defined activities and metrics to track our progress against the strategy. This is how we approached defining a strategy, which was similar to how it was actually done in our data organization at FINN as well. We're trying to be aligned in how we approach these high-level topics.

What is most challenging when putting such a strategy into action?

It’s definitely managing to keep track of and monitor the metrics that we have defined. Documentation is something that is notoriously tricky to measure. It's not impossible, it's just not straightforward. You need to combine a lot of different things. You need to look at different sources and always view the metrics in context which makes documentation measurement kind of special.

It's definitely a learning experience and I'm curious to see what we will learn from the impact of our metrics. Maybe the impact is going to show us that some of the metrics are not the best choice. Maybe we will see that we need a different approach or we’ll see something new about our stakeholders and their use cases.

Speaking of stakeholders, how do you currently ensure that you are aligned with your stakeholders?

The main thing is communication. The wider field of documentation is often described as technical communication and I think that's a really good way of putting it. So, technical writing is all about maintaining open communication channels and being in a constant feedback loop with pretty much everyone.

We have not just regular meetings that we attend as technical writers but we also have one-on-ones where we try to dive deeper into current challenges and goals of individual stakeholders. We apply UX research and look at specific pieces of documentation and assess how usable they are. We also apply principles from information architecture to make the documentation better organized and, overall, more accessible. Essentially, we apply a lot of different techniques to make sure that we understand what we're supposed to be documenting. We always aim to put our efforts where they create the most impact. In short, the answer is communication, communication, communication.

Thank you very much for sharing your insights into technical writing at FINN. What advice would you give someone who wants to start a career in technical writing?

My first advice is to connect with the very strong technical writing community. There are lots of groups, for instance on LinkedIn or the Write the Docs community. You can find many conferences, too. Look up some meetups and enjoy them. People are really open to newcomers and always happy to share their learnings.

My second advice is to decide on a specific technical writing profile that you want to pursue. There are many avenues for technical writers. Decide on the type of tech stack you want to learn and the type of industry that you want to go in, then focus on that. That's really going to have the most impact.

How do you approach technical writing in your organization? Share your insights in the comments below

Strategy is delivery: Scaling 10x through ownership and trust

Verena Ermes — Mon, 27 Feb 2023 13:20:59 +0000

At FINN, we are determined to build the most popular car subscription platform. We are on a promising path and hit $100 million annualized recurring revenues (ARR) in 2022, in our third year of existence. Supporting this immense growth we need technology. But as the company changed so much in only three years, our technological needs changed just as much.

As my colleague Ish Zafar outlined in his article No-code isn’t scalable, we were facing a range of technical challenges that were a loud cry for action. For in order to enable the business to grow as fast and ambitiously as we were planning to, we had to make our technical foundation scalable. So we decided to build a next generation car subscription platform standing on a foundation of pro-code.

Now imagine a growing company that is busy as a bee hive. And then you come to realize you need to do this tiny change of turning the core tech platform upside down while the business is running ever-faster. How do you manage a project like this?

I was visiting the OMR Festival in Hamburg in May last year and listened to a talk by the Delivery Hero CTO Christian von Hardenberg. He was presenting their approach to unifying all Delivery Hero’s acquisitions’ technical systems. This talk gave me two key insights:
Think 10x – a Google paradigm to innovate and create moonshots
A centralized approach may not win over a decentralized one

Moonshot mindset
Thinking 10x—this refers to shifting the mindset and aim for improving 10x rather than by 10%. The idea behind it is that people get way more excited about an opportunity to make something 10 times better. The goal becomes to create breakthroughs and to be radical. An accelerator is the ability to detach from existing solutions and old assumptions.

Discovering 10x-thinking triggered another thought process. In my view, it in addition emphasizes the iterative nature of evolving a minimal viable product (MVP). Building an MVP requires some kind of agreement of what’s minimal. So, when I thought about our goal—to create a scalable car subscription platform that serves 100,000 cars, having that number in mind and discovering the 10x thinking—suddenly I knew how to structure this project: we would start with an MVP serving 10 cars and iterate 10x the number of cars in each cycle going from 10 to 100 to 1,000 … and eventually to 100k cars.

Let’s go decentralized
FINN’s organization is split into vertical departments that are very independent, autonomous, and follow their own departmental missions. The sum of its parts results in the company mission. The Engineering department, however, is an enabling function, which means that Engineering teams are mostly distributed across all other departments. When starting the new subscription platform project, it quickly became obvious that it was going to be a cross-department effort involving teams from all departments.

A decentralized organization can hold a lot of complexity. Holding the complexity of a cross-departmental project that would reach the size of coordinating ten streams plus guiding the technical side of things would simply have been too much for one person alone. I am very grateful for my colleague Andrea Perrizato for joining me and taking ownership of the technical guidance throughout this project. Having two perspectives on the same situations is incredibly valuable and can elevate outcomes to a higher level, I am convinced.

A project principle
After having the basic project structure and approach defined, we added one simple project principle for everyone to keep in mind and use as a decision aid. The principle is “strategy is delivery”. For me it has one very clear meaning: to prioritize shipping features fast. Not in order to rush the process—to the contrary. We wanted to use this project to do it right. To review processes and workflows that grew organically and adjust them if we learned how to do things better in the meantime. The principle’s meaning underscores the sense of building an MVP. This MVP not only aims to do things better in the long run, but also, during short-term implementation iterations, aims to ship fast to maximize feedback cycles.

You could argue that the principle “strategy is delivery” has another meaning, at least in the beginning. After all, we are delivering cars that have been subscribed to be delivered at our customers’ doorsteps. For the very first car (and probably the following 100 too) serving the car delivery was very much the goal. On reaching every new 10x milestone we had a special sticker counting the number of cars delivered. We just got the 1,000 cars version added to the collection.

Zooming out to zoom in
Okay, I hear you asking, but how do you get going? My personal preference on doing things is to get context and see the bigger picture, so that I know what I am working towards. I’d like to think about it as zooming out, in order to be able to zoom in. In our first scoping workshop for our MVP 10 Cars, people from all teams came together to do exactly that: zoom out, to zoom in.

The tricky part about having a decentralized organization is the question of how to access distributed knowledge and make it available. Bringing relevant people onto the same (figurative) table is step one. Step two is pouring out the knowledge. My biggest objective was to understand what the whole lifecycle of a car and a subscriber at FINN looks like. I knew every department works on parts of this cycle, but I couldn’t visualize the whole process.

Everyone drew their core parts on a Miro board and we could stitch it together having one flow. We could break each step down into features and prioritize these features to match the MVP iteration’s focus. We would repeat this process for every MVP iteration and refine the overall flow as well as the next prioritized features.

Give out trust and ownership instead of managing risk
When you google for project management it is highly likely that you’ll find articles on managing risk. In the context of software development I refuse to understand this concept. Building software is inherently risky, because you’ll never really be able to predict the exact outcome and timeline. So, let’s just accept that there is risk.

Instead I want to give people trust and ownership. After choosing and defining the scope for every iteration collectively, I trust people will pick up the right things to work on in order to reach our joint goals. In a decentralized organization like ours, they effectively know their domain best. I like to give people true ownership, because I want to avoid micromanagement at all costs. Never forget that with ownership comes freedom and responsibility. I strongly believe that when giving out trust first and foremost, adding ownership on top, most people won’t risk you pulling the plug because they enjoy their radius of operation and know their impact.

See the gaps
For following through, it is essential to have an overview at all times and to never lose track of the target picture. Establish a weekly stage to exchange updates, challenges, and successes between teams. This will provide two opportunities:

It creates accountability
It can uncover gaps

You want to have week-by-week accountability to encourage progress to be made in a timely manner on the defined scope. More importantly, I think it is crucial to see gaps when connecting the dots week by week. This way you can course correct without a lot of delay and manage the project’s successful progress effectively. You are by default not waiting for crashes to occur and adjust direction only after they happened, but instead you are trying to read the ocean and navigate it based on your observations (which still leaves room for crashes).

Communicate interdependencies
Lastly, and this is especially true for a cross-department project, communicating interdependencies right from the beginning is key. Make this step mandatory, prior to any line of code being written or any automated workflow being built. For whenever there are dependencies between multiple teams it is most important to get back onto that figurative table with the teams involved and get clarity on each other's requirements and dependencies. We aim to design solutions for each other, because every team has stakeholders to serve and we highly value being customer-first at FINN.

Originally published on LinkedIn