Going from open source maintainer to running a business: 7 lessons
authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Active Directory, and auth0. Authentik Security is a public benefit company building on top of the open source project.
Since November 2022, authentik has gone from an open source project with one maintainer writing most of the code (me), to having a real business built on top of it—with six full-time team members across the globe. We celebrated the company’s first birthday last year, but I wanted to share some personal reflections from my own journey from maintainer to CTO.
What’s worked
Standardizing and templatizing (on some things)
One of the advantages of a greenfield environment is being able to choose my own constellation of tools and workflows to make things as easy and efficient as possible.
You might think that standardizing of any sort is the remit of scale-ups and big corporations with compliance requirements, but the business efficiency and simplicity that comes with it is also a huge bonus for lean startups.
1 Team hardware
Standardizing on the computers that new team members were given was one of the things I wanted to do from the outset. For example, we default to MacBooks for our laptops, because that’s what we support. If someone has a problem with their laptop, we don’t want them to be blocked because we don’t have an IT team or adequate documentation, and no one knows how to fix it.
If someone has a real preference for something else and they are comfortable with having no company support if they need help with it, they’re free to do that. I don’t want to draw too hard a line, or have Authentik be at the level where you need to get approval anytime you install anything on your machine.
In a previous role, the company I worked for stipulated that all USB sticks had to be encrypted, which at face value seems reasonable. But I had to create a USB stick to boot a server, so of course I couldn’t encrypt that, which meant every time I had to get an exception from some other team… these things can very easily hinder your work.
It’s about striking a balance between enough flexibility to move quickly, and enough structure that people aren’t running into issues and not able to get help.
2 Release checklists
Over the first year of the company, we started rolling out bigger releases: partly because we were purposefully going longer between releases, and partly because the team was picking up momentum. Up until this point, our releases were mostly ad hoc, but with a growing feature set, we realized we needed a little more process around rolling out these bigger releases.
And now we have a release checklist
Our infrastructure engineer, Marc Schmitt, created a release checklist (and an accompanying template for future releases) and acted as the release manager for our 2024.2 release. We started working off the checklist two weeks before the targeted release date, with standing team meetings to check in and assess our readiness level, review the release notes, and go over any release blockers.
One item on the checklist was for creating an RC (release candidate) build, and then pushing that release candidate to GitHub for early testers, along with the release notes—allowing us to get some early feedback before GA release day. As the release date neared, the team felt more confident in the release and the new features.
We also created a marketing launch plan for the release (along with a template for the next launch plan, of course!). With a target release date on the calendar and the team having better visibility into what was in the release, we were able to act on the launch plan and get the word out to our users and community via social media a little earlier.
3 Dogfooding (in our case, implementing SSO early on)
A lot of startups don’t have a documented onboarding process. So on Day 1 someone is probably manually creating your Slack account, your Google Workspace account, and whatever else you need access to. We have the advantage that we make software that can do that for us: authentik.
We just create an account for the new employee in authentik and in Google Workspace (because Google does things a bit differently). Then the employee logs into authentik on with their first-time credentials on Day 1 and immediately has access to everything they need, right from the start. They’re able to get into their actual work right away.
This is great for multiple reasons: it’s a smoother onboarding experience for new joiners, it helps instill good security practices from the beginning, and it helps us improve authentik for users. By running the development version of authentik and having our own instance that we use as a company, we’re able to find and fix bugs before we ship them.
When I was onboarding our first team members, it also helped show me where aspects of the product were not as clear or simple as I thought, because I was too close to it. Having other teammates use authentik exposed room for improvement that we’d otherwise be relying on customers to raise with us.
This is hardly a hot take, but I think every company would benefit from using their own product in their day-to-day work.
People and management style
4 Hiring
When I started hiring the Authentik team, I wanted to focus on sourcing candidates with a higher seniority level for two reasons.
At this stage of the company’s growth, I don’t have time to teach and mentor juniors. More senior candidates were more likely to be comfortable working independently and take initiative to reach out if they needed help.
This was especially important since Authentik was a brand new company and is fully remote, which can be challenging for team members who need a bit more guidance. This was also the approach recommended by OCV.
Secondly, while I do believe in people specializing (which is why you won’t find full stack engineers on our team), there is a lot of value in having team members who are interested and curious in things beyond their role. Having some exposure to different contexts and technology is likely to go hand in hand with seniority, but can also come down to someone’s personality or disposition.
With a small team, you need team members who genuinely prefer working with less rigid roles and who feel comfortable questioning things and speaking up if they see opportunities to do something better. It is so helpful for momentum if people are experienced and confident to make suggestions or even contribute a fix to something themselves.
5 Regular 1:1s
As CTO of a new company, I also had the new challenge of figuring out “How do I want to manage people?”
Generally, I’ve tried to combine the best aspects of my experiences of being managed (for better and worse, as you’ll see below). In a previous role, over the course of three years I think I had maybe two or three 1:1 meetings with my manager. We had regular team meetings, but the 1:1s with my manager were only in the context of an annual review.
Later, at a different company, I met weekly with my manager and I enjoyed those meetings. They were regular enough that we had time and space to talk about more than the immediate work in front of us. We’d discuss my ideas, things I might want to do but that aren’t yet on the roadmap, even just geek out about technology.
So, when team members started joining Authentik, I started off with 1:1s every other week, with the option to meet weekly if the team member wanted. We spend some time on prioritization, but there’s also room to go deeper into each person’s thoughts in a way that’s hard to recreate in the context of a team meeting (with limited time, competing priorities, and group dynamics to contend with).
What hasn’t worked (and what we’ve changed)
6 We needed a structure for prioritization
I’ve been fortunate in my past roles to have a lot of freedom to explore and figure out the right things to work on myself. Initially, I tried to keep this freeform approach to planning and prioritization at Authentik—which worked for me, but not so much for my team. We were spending every 1:1 focusing on prioritizing, which just wasn’t efficient.
I have previously been exposed to a more structured system with sprints; at the time I was initially sceptical because I thought it would be too restrictive, but I did find the orderliness of it helpful. There was time allocated to planned work, and some time allowed for researching, trying out, and learning new things.
So, we rolled out a sprint system at Authentik Security
We began by trying to use GitHub (which we were already using for version control, CI, and issue management). It was missing some key functionality for us though, like being able to close items from this sprint and move items to the next sprint.
Notion, which we were using for internal documentation, launched Sprints right around the time we were getting fed up with trying to make GitHub work for this purpose. So we standardized on Notion and imported all our internal GitHub issues into Notion tasks.
I wouldn’t say we have it all figured out, but the big advantage we’ve seen with this system is that everyone has visibility into what the rest of the team is working on. That way, if you see someone else working on something interesting or that you’re curious about, it’s easy to reach out and ask if you can help, or if you can collaborate or learn together.
7 Delegation
I imagine every founder (especially if you’re a technical founder/CTO) struggles with this. When authentik was just an open source project, most of its contributions were for documentation and guides rather than code, so I was used to doing most of the coding myself, spotting issues and fixing them.
It’s been a big adjustment to get into the habit of taking a step back, writing things down, adding them to the sprint and assigning them to team members to be fixed, instead of just doing it myself. Yes, it might take longer that way and I might still have to review the pull request or support whoever is working on it to figure something out. But it’s an investment in the future of the company to grow and develop the team and make it easier for everyone to learn and contribute. I can’t be a single point of failure.
Reflection and what’s next
The first year and a bit of Authentik Security has been a crash course in defining the right level of process to help us be more efficient without getting in the way. While it’s been hard to step back and focus on empowering others to contribute to authentik, it’s amazing to have a real team working on the project full time. The next natural step for the company was to appoint a CEO to lead us in the next phase of growth, and in February we welcomed Fletcher Heisler to do just that.