Owning the plugin ecosystem

The plugins team is where LottieFiles meets everybody else's software. An animator works in After Effects. A designer works in Figma. Neither of them wants to leave the tool they are already in to get an animation out of it, so the work is a plugin living inside each of those applications, and every one of those plugins is a small product with its own users, its own platform rules, and its own idea of what an extension is allowed to do.

My title was senior engineer. I acted as the technical lead for that team, which is a different sentence, and I am going to keep writing it the honest way. What it meant in practice was roadmap, sprint and milestone planning, prioritization, architecture, code review and every production release, across 10+ plugin surfaces.

That list is the study. It is not a title I was given and it is not a promotion I am describing. It is a set of jobs that had to be done in a particular order, and the order turned out to be the interesting part.

The unit of ownership was a surface area rather than a product, and that changes what planning, review and release have to become.

A product team can hold its product in its head. An ecosystem of them cannot be held that way by anybody. The Figma plugin and the After Effects plugin share a purpose and almost nothing else: different platform APIs, different distribution, different review queues run by companies I do not work for, different release rhythms. What counts as a bug in one of them is frequently a platform constraint in another.

There are two ways that goes wrong, and they pull in opposite directions.

The first is drift. Plugin after plugin, each individually reasonable, solving the same problem four different ways, so that fixing it once fixes it once. Nobody decides to build an ecosystem like that. It is what you get by default when the same decision is made once per surface by whoever is nearest.

The second is the bottleneck. Route everything through one person and the ecosystem stays coherent right up until it is a queue. The team was small, so there was no stage after me to hand review and release to, which meant the queue was never hypothetical.

Both of those are real, and you do not get to avoid one without moving toward the other. What I could choose was where to sit between them.

I kept four things together on purpose: roadmap, architecture, code review, release.

Each one is where the previous one gets tested. The roadmap decides what a surface is for. Architecture decides what that costs to build. Code review is where the architecture either holds or quietly stops being true. The release is where you find out whether any of it was right, in front of everybody.

Split those across four people and every handoff drops the reasoning behind a decision while keeping the decision. Six weeks later somebody is defending a constraint nobody can explain. Keep them together and the person deciding what to build is the person who has to review it and the person whose name is on the release, which is a strong daily incentive to decide well.

Underneath that, three rules did most of the work.

• Platform difference lives at the edges. What a plugin does is shared. How one particular host application insists it be done is not, and it does not get to leak inward.
• Every surface ships through the same gate, including the quiet ones. A small plugin is exactly where a broken release survives longest, because nobody is watching it.
• Code review is not a rubber stamp on a finished diff. It is the last place a decision can still be changed cheaply, and it should be used that way even when the diff is fine.

Two things it bought

Figma announced Figma Motion, which changed what an animation in Figma meant more or less overnight. Getting animation out of Figma is the plugin's whole reason to exist, so the only question was how fast we could support it. I had a working converter within 48 hours of the announcement.

The speed is not really the point. The point is why it was available: nobody had to be convinced first. I could decide it mattered, decide how it was built, review it and ship it, and the loop is what turned a week of alignment into an afternoon of decisions.

The second is quieter and I like it more. Export failures used to arrive as support tickets. Somebody wrote in, described an animation that came out wrong, and a human read the file to work out why. Working closely with support, we moved that conversation into the plugin itself, so it checks what you are about to export and tells you what will not survive the trip before you take it. Failures turned into self-diagnosing guidance, which is a smaller sentence than it sounds like. It means the person who hit the problem is now the person who can fix it.

Breadth costs depth, and I paid it deliberately. 10+ surfaces means never being the deepest engineer on any single one of them. On any given day somebody out there knows the Figma plugin API better than I do, and they should, because it is all they do. What breadth buys is that no surface is orphaned. What it costs is that no surface gets the person who has thought about nothing else for two years.

The bottleneck was not theoretical either. Every review and every release through one person is a queue with one server, and I worked remotely from South Korea, so the queue had a timezone in it. Some of that is answerable with process and some of it is just being awake, and I am not going to pretend the process part covered all of it.

Shipping first ships the gaps. A converter standing up that fast handles the common case and arrives with a list of things it does not do yet. I would make that trade again, and it is still a trade: the gaps are yours to close afterwards, while the next thing is already asking for attention, and the list only gets shorter if somebody protects the time to shorten it.

And the title never followed the responsibility. I did the job for two years under the title I was hired with. I am not sore about it, but I would not repeat it, and not for the reason people assume. It is not the word. It is that every conversation about scope starts one step earlier, with establishing that you are the person to have it with, and you have that conversation again with every new stakeholder for as long as it lasts.

Across the two years: 10+ plugin surfaces, 200+ production releases, and Figma plugin installs passing 1M+ during my tenure.

The Figma Motion work is the one place I can point at what all of this did to the product's numbers rather than to its engineering, and it needs the setup to land. Getting an animation from Figma into Lottie is the reason that plugin exists, and Figma Motion changed where those animations come from. After we supported it, two numbers moved with it: saves per user in that flow went from 2.07 to ~3.08, a change of +48%, and Figma to Lottie exports rose +20%.

I am wary of claiming those as mine alone. A plugin at that scale has a lot of hands near it, and product numbers move for reasons nobody in engineering gets to see. What I will claim is the loop that made a response that fast possible in the first place.

That loop is the part worth taking somewhere else. Roadmap, architecture, review and release want to be held together, and holding them together is why 10+ surfaces read as one ecosystem instead of that many products sharing a logo. It does not scale past a certain team size, and it should not. The job of holding it is to write enough of it down that it stops needing to be held.