The essence

One of the reasons I am so attracted to “the startup way” is the process of discovery that happens early on. In fact, even as the startup grows, if it keeps that same beginner’s mind from the early days, the process of discovery repeats itself, and so does the joy.

Of course it’s not just one type of discovery: there’s always discovering a new team, discovering new technologies, discovering things about businesses or new vertical domains or how companies work — and always, discovering things about yourself. That’s not what I want to talk about here.

Discovering the essence

I do want to talk about discovering “the essence”: the gist of the solution that comes after understanding, and settling upon, the gist of the problem you’re going to tackle. In my experiences, it feels a little like wandering through some sort of fog, or maybe more like listening to some random sounds, and at some point something emerges, a structure or pattern, and the more you look at it, the clearer it becomes. Long after, maybe it seems obvious, perhaps trivial. But at the time, there’s no sign on it saying “this is the one”, or “drink me”, so you have to noodle on it. You have to test it, first by seeing if it really hangs together, then by seeing if it’s hanging just for you or for a lot of people — your future customers.

OK, enough abstract talk, let me share some examples.

Aptana and Jaxer

At Aptana, for example, we were a tiny team that had built an IDE for what was then called Ajax development: front-end Javascript web work, and increasingly single-page Javascript web apps. The community loved it, because we were able to give them the kind of help that devs got in typed back-end languages. But do we just keep adding features? Do we offer support for more Javascript libraries? Or is there some non-obvious direction that would excite this growing community?

Indeed there was: we asked ourselves, why not let them go “all the way”, let the apps encompass the back-end and front-end work, all in the same language, making these devs be what later would be called “full stack”. How? The elegant pattern that emerged from the fog was to truly make the entire app be single-page: having some script blocks on the page be tagged to run on the server, and of course executing this server-side Javascript with a new server, which we called Jaxer. Here’s how it worked:

1. Jaxer was basically a headless browser, so it would start to process the page, building a server-side DOM and executing only the <script runat=”server”> blocks (which would modify the DOM, e.g. by getting data).

2. The DOM would then be serialized back into HTML, and shipped to the “real” user-side browser as usual.

3. The browser would again process the HTML, building a user-visible DOM and running the remaining Javascript blocks.

It was a simple and elegant model that built on the skills of our community, and was super-easy to try out because it shipped with our IDE. Coming up with this essential structure was pure bliss. Now, was it a success? Perhaps it helped pave the way a bit for the full-stack developer movement that followed along with the success of node.js, and it did get decent early adoption, but in the grand scheme of things, no, it was not a success. For me personally, though, it helped to understand what it meant to look for the essence.

MuleSoft and API-led connectivity

Fast forward to the third startup after that: MuleSoft. The gist of our server, Mule, was a lightweight (for the time) integration engine that you’d program mostly declaratively — connect to this, get some data, enrich it by connecting to that, send it over there — and run on your own or in our hosted version. Mule apps were pretty fast to build, and adoption was growing. My job was to figure out what’s next. More features? Less weight? Maybe a marketplace of pre-canned integrations?

But what emerged from the cacophony of possible directions wasn’t any of these. And what led me down the path wasn’t some positive, “what would be cool to do next” kind of thinking. Instead, it was anxiety. My worries were that, as our users built more and more Mule apps, they’d actually slow down their pace of innovation. They were successfully gluing together lots and lots of systems, but the sheer complexity of glue apps (spaghetti, if I may mix my metaphors) would become a growing and intractable problem for them. I did not want to be remembered for a sea of glue, or for gallons of spaghetti for that matter.

The solution to my worries was to introduce something that fights this complexity: the API. I introduced it as a countermeasure to the integration glue, but in fact it worked well with the integration capabilities we already had. And that’s because it allowed an elegant pattern:

1. Integrate some complicated, often old systems to extract some business value, and expose the result as a simple, useful API.

2. Then integrate several APIs to extract some other business value, and again expose that value as an API.

3. At every stage, think of the API as a product, designed for easy, even delightful, consumption. To encourage that, we introduced a design-oriented API spec, RAML, and an API designer tool to let you easily craft the product (the API) and test it before implementing it, much as you would for any good consumer product.

Soon, there would be enough good APIs that you’re more often reusing rather than rebuilding, and things accelerate rather than bog down. We called it API-led connectivity. And though — or perhaps because — it was simple, it resonated strongly with our customers. We gambled to invest our product and business resources in this direction, and it paid off. The essence was simple and elegant, and this time, also successful.

Otterize and intent-based access control

I think I was craving that “essence discovery” hit when I joined Tomer and Ori in founding Otterize, though I’m not sure I knew I had that craving at the time. I did feel the essence was hiding there, somewhere, in our aim to make service-to-service access easy and secure. There were multiple principles we thought would be important: we wanted to make access declarative (vs imperative); we wanted to support lots of different services and infrastructures; we wanted to solve this problem directly for the people who experienced it directly, namely developers, vs for the executives that ultimately would see the benefits (e.g. zero trust) for the entire organization. And there were equally-important things we didn’t want: to introduce yet-another-engine to handle authorization, or to offer yet another reactive tool that alerted you about problems vs something that helped you build better to begin with. We sketched an outline of a solution pretty quickly, but what was the essence?

You might suppose it’s the decision we took to be an integration company: that we would integrate with existing access control mechanisms, rather than force yet another mechanism on the world. Or you might suppose that it’s our dev-first approach: that developers simply declare what access is needed, and we automatically configure secure access. But we believe the essence is actually this:

1. Developers simply declare what services they want to call.

2. And we automatically configure secure access for them and hand them the keys to call them on a silver platter.

In other words, rather than trying to figure out what access controls to impose on the server side, developers simply declare what they intend to call, and we put together all these client-side intents to work out the needed server-side constraints. It took us a while to figure out what to call this paradigm, until we simply settled on: intent-based access control, or IBAC. With client-side intents, we only ask devs for information they have: what their code needs to call in order to work. If their code is approved, it’s likely the intended access should be given too. So if we can integrate with all the access control mechanisms to allow this access and only this access, the overall system becomes secure while developers’ lives become even easier than before.

Is this another essence discovery? For me, it feels like it. It’s simple, perhaps even elegant, and when you think through barriers that other approaches have faced, whether adoption or technology shifts or simply bad timing, there are lots of inherent benefits to this approach. But arguably it’s early days, and only time (and hard work) will tell whether this works for developers and the platform/devops teams that enable them. Ultimately, that’s more important than the elegance of any essence we could come up with. But I do believe that truly successful approaches can inevitably be boiled down to elegant essentials, and I personally relish the discovery itself. It’s probably the reason why I decided to be responsible for the product side of Otterize, for the first time in my career, vs the technology side. But that’s a topic for another time.

What’s next?

In every “essence journey”, what’s next is to bring the idea to life, and see if it sinks or swims. Few ideas live and succeed on their own: they require the care and feeding of a team that deeply cares not simply about the idea but, much more importantly, on whether it proves truly useful.

Not everyone will understand it, and not everyone will find it easy to use, even if they do have the problems it’s meant to solve — so the job starts with explaining it, in ways that resonate with the audience; in making it easy to use, starting from a great product and experience. And then you must listen very carefully to what works, and what doesn’t. Beware of being so attached to the idea that you think it shouldn’t evolve, beware of being so in love with the idea that you can’t see if it might even be discarded and replaced with something else. You need to learn from your users, not what the product should be — I think it’s rare for users to know what the product should be — but rather whether it works for them, where it doesn’t work or could work better, and what problems it solves or doesn’t actually. If you’re lucky enough, they might even tell you why.

Regardless of whether it’s this essence, or the one it evolves to, or maybe the one that replaces it — when it does click for your users, and you realize you’ve got it, it’s pure heaven.