Blockchain: not as easy as it seems (and it didn’t seem easy…)

I’ve worked in a lot of startups throughout my career, but nothing prepared me for the pace and intensity of the web3 universe.

I came in expecting complexity. New terminology. New tools. A steep learning curve. That part didn’t surprise me. What did surprise me was how quickly I had to let go of the idea that there was a stable state to reach at all. In web3 and blockchain, there is no moment where things slow down enough to catch your breath. No point where you “get up to speed” and then operate comfortably from there.

As someone with a background in project management, I assumed my biggest challenge would be learning the technology. Instead, the real challenge was unlearning some deeply ingrained assumptions about how work is supposed to flow, how decisions are made, and how much certainty you can reasonably expect before moving forward.

What I eventually learned is this: project management in web3 isn’t about keeping up. It’s about staying upright while the ground keeps shifting beneath you.

There Is No “Keeping Up”

Early on, I kept trying to orient myself. I read constantly. I asked questions. I tried to build a mental map of the ecosystem so I could understand where we were and where we might be going. And every time I thought I was getting close, the landscape changed again.

Protocols evolved. Priorities shifted. External forces (markets, regulation, community sentiment) would suddenly reshape what mattered most. The instinct, especially for someone trained in more traditional project environments, is to chase clarity. To look for the right framework, the right roadmap, the right process that will finally bring order to the chaos.

That instinct will exhaust you in web3.

Eventually, I realized there was no final version of understanding waiting for me. The work wasn’t about mastering the environment. It was about learning how to move within it without freezing or thrashing. Once I stopped trying to “catch up,” I could actually start contributing.

That shift, from control to adaptability, changed everything.

Flexibility Beats Process in Web3 Project Management

This is where a lot of conventional project management advice starts to break down.

In fast-moving, high-uncertainty environments like web3, strict adherence to process can become performative. It can create the illusion of control without delivering the substance. Documentation gets created to justify decisions that are already outdated. Roadmaps look impressive but quietly lose relevance the moment they’re approved.

What mattered more was flexibility. Not chaos for its own sake, but intentional looseness. The ability to zoom out, spot patterns, and decide what not to formalize yet. 

At the company, I slowly moved from being seen as “the Scrum person” to someone the leadership team leaned on for broader operational and strategic decisions. That didn’t happen because I enforced frameworks more rigorously. It happened because I learned when not to.

The same project management skill set was still there. It was just applied with a lighter touch, focused on the few things that would actually move the business and the ecosystem forward.

A Concrete Example: Building a Blog That Actually Mattered

One of the clearest examples of this approach was when we discussed whether to develop a blog.

On the surface, the goal sounded simple: position the company as a thought leader. But this wasn’t about marketing theatre. The team was full of genuinely brilliant developers who were thinking deeply about web3, governance, infrastructure, and long-term ecosystem health. They weren’t chasing trends. They were asking hard questions and building thoughtful solutions.

The opportunity wasn’t about “creating content.” Rather, it was to share thoughts with the community and to deeply engage them. 

As a project manager, my role wasn’t to jump straight into timelines or tooling. First, I had to identify the audience. Who were we actually talking to? Builders already deep in the space? Curious outsiders trying to understand web3 without drowning in hype? Potential partners looking for signals of credibility?

Once that became clear, I pitched the idea not as a blog, but as a knowledge strategy. A way to educate, to invite people into the conversation, and to provide entry-level insights without talking down to anyone.

From there, things grew organically. Topics emerged naturally from the work people were already doing. Contributors stepped forward because they cared, not because it was assigned. What started as a simple idea became a living expression of how the company thought about its role in the ecosystem.

Agile Without Calling It Agile

Another moment that stands out involved how the development team worked day to day.

There was understandable resistance to “agile.” Not the principles, but the baggage. People had seen it imposed poorly elsewhere. Rituals without meaning. Ceremonies that consumed time without improving outcomes. The word itself had become a warning sign.

So we didn’t call it agile.

Instead, we listened.

We talked about what wasn’t working. Where handoffs were painful. Where people felt blocked or rushed or disconnected from outcomes. The solutions came from those conversations, not from a framework deck or some textbook.

Gradually, patterns emerged. Shorter cycles of work. Clearer goals. Regular moments to pause and reflect. Before long, we had sprints (we just didn’t call them sprints for a while). We had shared commitments. We even had a community of practice focused on how we worked together.

None of it was “my idea.” My role was to create space for reflection, help surface common threads, and lightly guide the conversation when it drifted. The structure followed the people, not the other way around.

That experience reinforced something I’ve come to believe deeply: the best project management often becomes invisible once it’s working.

From Chaos to Pattern Recognition

What web3 forced me to develop, more than any specific methodology, was pattern recognition.

When everything feels urgent, discernment becomes your most valuable skill. Not every new idea deserves equal attention. Not every fire needs to be put out immediately. The ability to step back, see recurring dynamics, and understand which levers actually matter is what separates motion from progress.

In hindsight, what I was really learning was how project management in web3 works when uncertainty isn’t a phase to get through, but the permanent state of the system. Once you accept that, your job changes. You stop trying to stabilize everything and start focusing on enabling good decisions under imperfect conditions.

That mindset is uncomfortable at first, especially if you’ve been rewarded in the past for predictability and precision. But it’s also freeing.

Why These Lessons Apply Far Beyond Web3

Here’s the thing: none of this is unique to blockchain.

What surprised me most is how transferable these lessons from project management in web3 turned out to be, especially in non-profits and small tech startups. I’ve worked in environments where funding cycles are uncertain, priorities shift based on external pressures, and teams are asked to do meaningful work with limited resources.

Sound familiar?

In non-profits, chaos often comes from competing stakeholder needs and mission-driven urgency. In startups, it comes from runway anxiety and evolving product-market fit. In web3, it comes from all of that plus a rapidly evolving technical and regulatory landscape.

The common thread is volatility. And in volatile environments, rigid processes are rarely the answer.

What works instead is:

• Clear intent
• Lightweight structure
• Trust in the team
• And a willingness to adapt without panic

Those principles travel well.

The PM’s Real Job in Chaotic Environments

If there’s one thing web3 clarified for me, it’s this: the project manager’s real job isn’t enforcing order. It’s helping people make sense of complexity without oversimplifying it.

Sometimes that means adding structure. Sometimes it means removing it. Often, it means asking better questions rather than providing answers.

I didn’t succeed in that environment because I followed the rules more closely. I succeeded because I learned when the rules no longer applied, and how to replace them with something lighter, more effective, and more responsive.