When I joined a small blockchain startup in Reno, Nevada, I didn’t think I’d end up leading the team that built its core web application. I just wanted to build better React apps. Two years later, I’d learned lessons about leadership, communication, and simplicity that reshaped how I think about software development.
At Blockchains Inc., our mission was ambitious: use Self-Sovereign Identity (SSI) to help organizations share data securely and privately. I joined the Web Team as a Web Engineer, building the user interfaces that interacted with our backend APIs.
Like most startups, our structure was messy. Product managers collaborated with designers in Figma, but technical details rarely made it into the user stories. I’d open a ticket, see a beautifully designed screen, and think, “Okay… but how does this actually work?”
That gap meant I spent a lot of time bridging worlds — translating product intent into API calls, coordinating with backend engineers, and occasionally rewriting expectations on the fly. Over time, that frustration became an advantage: it forced me to understand the entire system, not just my slice of it.
One of my biggest contributions was building the onboarding flow — the part of the app where users created their first Verifiable Credentials. Since credentials were the foundation of our SSI model, I designed the components to be reusable across other core flows. Those same building blocks powered new features long after onboarding was done. It taught me an early lesson in scalability: reusability is the simplest form of architecture.
About ten months in, my manager left. I was asked to step into his role as Technical Lead without losing my responsibilities as a Web Engineer. Overnight, I went from contributor to coordinator.
My new job was part translator, part shield, part coach. I had to communicate what our team was capable of to product managers and executives, while also protecting my developers’ focus. I learned that documentation wasn’t just a nice-to-have — it was a leadership tool. A well-written architecture doc could prevent three meetings and a week of confusion.
When we bootstrapped a new app in Next.js, I saw it as a clean slate. We were migrating everything from a legacy React codebase that had grown unwieldy. The old app relied on a massive global store. It was convenient at first, but became increasingly brittle. Instead of adding yet another state management library, I asked: What if we just simplify? We reorganized data flow, cut out unnecessary abstractions, and leaned on React’s built-in patterns. By simplifying state management, we reduced onboarding bugs by 25% and new feature development time by 30%. It wasn’t trendy, but it worked, and developers actually enjoyed working in the codebase again.
The best part of leading wasn’t making decisions. It was learning from the people around me. I hired two senior developers whose experience challenged my assumptions about architecture. I also hired a junior developer, and teaching him ended up teaching me even more. Explaining something forces you to understand it twice: once in code, once in plain English.
What I learned most was that leadership isn’t about control — it’s about clarity. When your team knows what success looks like and how their work connects to it, they don’t need micromanagement. They just build.
That startup environment wasn’t perfect, but it was the best classroom I could’ve asked for. I left with a few principles that still guide how I work today:
The same principles I learned there — simplicity, reusability, and communication — are what I bring to every consulting engagement today.
Please visit my Wordpress site to leave a comment on this post.