The violet verse files.
Three proof points across different domains: team structure, developer frameworks, and AI behavior
I’ve been watching Married At First Sight, and one of the couples is an academic who uses “philosophy” and “frameworks” in every single conversation. As much as it may give a lot of people the ick, overanalyzing something so much that you take the human and emotions out of everything is probably not great for a relationship. But when you’re building a high-end startup at lightning speed, thinking in frameworks and systems is literally what separates the amateurs from the people who build businesses. I am no stranger to thinking in frameworks and systems. I previously published work in Future Commerce, where I curated an original column called Lovers and Outlaws.
In this post, I’ll lay out some of the inspiration behind how I diagram everything.
Why I build systems from scratch
Earlier in my career, I worked for big corporations like Ebay, Publicis and Elsevier. The systems were already there: the approval chains, the custom CRMs, the content calendars, the reporting dashboards. My job was to work inside them and don't mess up.
However, for the last six years, I’ve worked exclusively in early-stage companies, most with fewer than 50 employees. There, nothing exists until someone builds it. There’s no playbook for how content gets approved, how a contact becomes a customer, or how engineering’s launch schedule connects to marketing. This is where I thrived the most because I got to take everything I learned and apply to these early stage teams that desperately needed structure. If I’m not building frameworks, I’m thinking about growth opportunities across different budgets, and usually I’m doing both at once.
The diagrams below came from completely different scenarios, but they share one thing: each started with a blank page.
Systems thinking isn’t just “I made some boxes" in a meeting to look smart and strategic. Some of the greatest strategists, political scientists, advertisers, and business thinkers have been masters of this skill. When you think about systems design and everything that comes with it, the ability to visually represent your ideas has been at the crux of how complex ideas get communicated, understood, and ultimately built.
For example, David Ogilvy is the father of advertising and communication, even shows like Man Men on HBO were inspired by this man and his advertising firm that is still one of the top earning media companies in the world.
To me, diagraming is an art and it sits somewhere on the same spectrum as financial and legal thinking. But systems design is much more driven by architecture: understanding how all the different pieces of an enterprise or startup fit together, and then figuring out how the backrooms actually need to operate for the business to function.
Did you know that 47% of B2B marketers have a documented content marketing strategy, but only 29% rate it as extremely or very effective? That's because people rarely customize a workflow. As my work usually sits between the content, business, product, and technology teams, I’m often the storyteller. For the last few years, creating diagrams has been one of the ways I communicate, organize information, and work with teams. The diagram is often the thing that makes everyone look at the same problem at the same time.
I came in as the head of marketing with a goal of organizing teams and getting everyone to think about content launches in a way that actually helped the entire organization.
From PR launches to daily content, one of the recurring themes I hear is that people can’t stay consistent.
Luckily, people scroll their algorithms based on interest, not points in time. So my rule of thumb is: if you have something urgent to say or a call to action, post multiple times per week to build engagement and acquire customers or an audience. You can always delete it later.
If you’re posting for an aesthetic, make sure you’re on theme.
As far as workflows, after spending the majority of my career in media, I tend to run marketing like an editorial department. It’s the only way I’ve found to stay aligned with teams, especially engineering, who always seem to have new launches ahead of schedule.
In these diagrams, the information comes from the top down, but the top is intentionally crowded and seeded so anyone can add their ideas. Those ideas get curated as they move down the funnel, and eventually get distributed based on data: what works on each channel, where the audience is, and where the content or idea can actually be used.
Then there are the teams.
Usually, marketing revolves around consumer-based or developer-based audiences. In crypto, marketing touches almost every part of the business. From crisis management to GitHub launches, marketing is often on the front line.
I created this diagram when I was leading marketing at Moonbeam Protocol, which is now totally decentralized.
When I first joined crypto, no one really explained the ecosystem layout to me.
I just had to figure it out by examining diagrams from the engineering team.
That experience taught me something pretty quickly: technical people already have a mental model of how the system works. The problem is that everyone else usually doesn’t.
So one of the most useful things I can do is take something that makes perfect sense to an engineer and build a visual framework that makes it legible to everyone else.
The interesting thing about this diagram is that I’m not just documenting what an AI agent did. I’m mapping how it behaved: what it investigated, what assumptions it made, where it failed, and what ultimately led to a successful outcome. This distinction matters the most. I used the above graphic for a governmental challege. When you’re building with AI, you’re not only evaluating the output. You’re evaluating the system that produced the output.
The human in the system
Back to Married At First Sight...Turning everything into a framework doesn’t work in a relationship, because it takes the people out of the conversation.
The best diagrams do the opposite. They don’t replace the people on a team; they give everyone something to point at. When engineering, content, and leadership each have their own mental model, a good diagram is what gets them speaking the same language. It’s not about looking smart in a meeting. It’s about getting everyone to look at the same problem at the same time.