My first job was as a "marketing associate" at a seed-stage startup. This meant that I wore a lot of different hats and used a lot of different tools. On any given day I’d be logging in to at least half a dozen different web UIs to do tasks ranging from marketing to customer service to order fulfillment.
Getting access to each of these was a challenge in and of itself. The cycle would usually go something like:
- figure out who could give me access and ask them nicely
- get access but find out that the default user role didn't have permission to do the thing I need
- ask nicely for more more access
- repeat this a few times
Eventually, we’d both get frustrated and just grant me admin level access just so that we could move on with our lives. If by some miracle we actually figured out what role had the permission I needed, we'd just do this again the next time I needed to do something different.
I have no idea when or how it happened, but as time went on I found myself on the opposite side of the table. We hired an accountant who needed access to payment processing tools that I hadn’t thought about since I’d set them up. I’d somehow ended up in charge of our analytics, which meant that I was in charge of managing access to self-service tools which themselves also needed access to other self-service tools! Was our CEO saying the widget sales dashboard was broken because he wasn’t a “Dashboard Viewer”? Or was it because the reporting tool’s service account didn’t have permission to count widget sales in our ecommerce platform?
I didn't want to just go around granting people more access than they needed. But there's only so many hours in the day and I hated feeling like I was keeping people from doing their job. This remained the case even as I started a new job, and then started a new job again. Sometimes things were slightly better or slightly worse, but the song and dance of:
- figure out who could give me access and ask them nicely
- get access but find out that the default user role didn't have permission to do the thing I need
- ask nicely for more more access
- repeat this a few times
never went away.
I really have no idea when or how it happened, but one day I woke up and found myself building software instead of just using it. Inexplicably terrible past experiences dealing with access to tools and services started to become explicable.
“Why can’t we just give the customer service agents our internal-use-only super-admin cli app so that they can manage our user’s accounts instead of asking us?” I’d say to myself, mocking something I’d said to the CTO at that first job.
Of course, I was correct, we totally should have done that. But I’d only been correct in the way that people who hide “We should do X” statements behind “Why can’t we just do X?” questions are always technically correct. At that point our internal-use-only super-admin cli app’s authorization policy was “only two people can use this.” Giving our contracted customer service agents access to that tool would have been signing our engineering team (at the time three people, including the CTO) up for a lot of work.
I didn’t get this until I actually started working on software. At the time, I’d thought that the engineering team didn’t trust anyone to use the tool correctly. Now I understood that they didn’t trust themselves to make the tool safe to use.
Likewise, none (or at least very few) of the developers who’d built the external tools that I’d used had set out to build a hard to manage authorization system. It's just that it's a hard and time consuming thing to build, even if you're only interested in building the bare minimum. A "delightful" (or at least “not miserable”) access control management system is typically reserved for The Enterprise and is implemented only by companies with considerable engineering headcount.
If you click around www.osohq.com for long enough, you’ll find the quote “Our vision: by 2032, we decrease the amount of time and brain calories that developers spend on authorization by a factor of ten.” This is a tall order, but it would have a massive impact on what kind of software gets made. Internal tools that access sensitive data could be developed both cheaply and safely. Managing roles and groups for your company’s suite of SAAS tools might not be a full time job. These are exciting possibilities that certainly would have made my life easier. For me, trying to make that future happen is the best part of working at Oso.
If this kind of work sounds interesting to you, see our open roles.
