Introduction
I've only been "in" crypto for a few years, but the seeds were planted much, much earlier, starting with some leadership training I received over a decade ago followed by my subsequent adventures with DevOps. The common thread throughout: a gravitational pull towards more autonomy, empowerment, freedom, and happiness.
In this post, I write about my path from leadership to DevOps to blockchain, highlighting how autonomy played a role in each step and ultimately led me to the world of crypto.
Leadership Training: Culture is Everything
In the early 2010s I went through a leadership development program called LPMA: Leadership Process Motivating Achievement. Based on academic research about psychology and intrinsic motivation¹, LPMA shaped my views on leadership and equipped me with the tools and the confidence to grow from an individual contributor to Vice President of Global Business Operations at Cornerstone, with responsibility for Enterprise IT and a global team of over 100 people.
Paradigm Shift: From Directive to Empowering
Leadership is "the skillful use of influence to bring about the accomplishment of goals". When we think of leaders, we often think of someone commanding control and telling people what to do. But leadership isn't about commanding; it's about creating an environment where people will be intrinsically motivated to do their best work. The LPMA training showed us exactly how to create this optimum work environment which would motivate people towards achievement and peak performance.
In a leadership talk I gave at the DevOps Enterprise Summit in 2022, I described the job of a leader not as doing any actual work, not as telling people to do the work, but as creating the environment where the work can be done.
The Six Dimensions of Organizational Climate
LPMA introduced a model featuring six dimensions that together create the organizational climate. You can think of climate similar to an organizational culture or a work environment.
Conformity: often felt as "too much bureaucracy", or when too many rules, policies or processes exist that have little or no perceived value.
Responsibility: felt when people have personal ownership and decision-making autonomy.
Standards: the amount of emphasis placed on excellence and achievement.
Rewards: when balanced feedback is given, and accomplishments are recognized in a meaningful way.
Clarity: when everyone understands their role, their goals, and how they are related to the overall purpose of the organization.
Sense of Team: when people feel a strong sense of belonging and pride within the organization.
Once you understand these 6 dimensions, the formula for high performance is simple: reduce conformity and maximize all other dimensions.
Putting Theory into Practice
In my leadership roles at Cornerstone, whether managing a team of 25 or 100, the impact of the LPMA model was clear. Reducing red tape and empowering my team members with more autonomy not only increased our team performance but our happiness as well. A pivotal moment for me was when one of my direct reports worked up the courage to tell me she thought I was micro-managing her and asked me to step back. It was a wake-up call. I always saw myself as a "player coach", and wanted my team to know I wasn't above getting into the weeds with them. In engineering culture, there's nothing worse than a CTO who is seen as out of touch with technology. But in the context of LPMA I learned to step back and out of the day-to-day operations. I proved to my team that I trusted them to make the best decisions on how to succeed. As soon as I gave them more autonomy and empowerment, their productivity increased and they achieved even more than when I was heavily involved. All it took was giving them the space to grow and the autonomy they needed.
This journey through leadership training not only reshaped my approach to managing teams but also laid the groundwork for my adventures with DevOps. As I moved forward, applying these principles to engineering yielded similar results - high performance and happier people.
Transitioning to DevOps: Empowering Developers
At Cornerstone we went through a large-scale modernization effort migrating from monolithic software architecture to microservices, from on-premises hosting to public cloud, and from quarterly big bang releases to continuous delivery. This multi-year transformation introduced me to the art of DevOps. My interest in DevOps came from a familiar place: discovering a better way to work that not only improves performance and creates more value, but also made everyone involved happier.
There are many definitions of DevOps, but I personally define DevOps as anything done to make deploying code easier, faster and safer². I visualize DevOps as a system of guardrails - any structure, process, system, or tool that makes it easier for developers to ship code. Most of DevOps is based on automation - automated code scans, quality tests, performance tests, code merges, builds and deployments. But I also consider Lean and Agile ways of working to be part of DevOps by promoting small batch sizes which greatly reduces risk. In a healthy DevOps environment, developers can write and ship code permissionlessly, with autonomy, because they know in advance all the requirements and rules they need to comply with because they are written into the automation. Compliance is baked into the process. With DevOps, developers waste less time in meetings asking for permission to deploy, they just need to stay within the guardrails.
Introducing DevOps as part of our modernization efforts was a difficult but rewarding journey. I've always seen coding as an activity that should be fun - stemming from my early career experience at an internet startup where we would see our code go live on a daily basis. As I advanced in my career and worked at larger organizations, the thrill of coding went away. Work was no longer fun. As a manager I was no longer writing code but spending time in meetings, dealing with people problems, and managing bureaucracy. We spent more time talking about what to build than actually building anything. I assumed work got less fun because I wasn't writing code anymore, or because I wasn't at a startup.
But with the introduction of DevOps practices, we started shipping faster. We didn't have to roll back as many changes. We didn't have to cancel as many half-finished projects because an executive or customer changed their mind before we could finish the work. We were shipping small and continuously delivering iterative improvements. Work became fun again, even though I wasn't the one writing code, nor was I working at a small start-up. I had discovered once again that empowering individuals and giving them more autonomy led to better results and happier people.
There would be no turning back. I'll never again work in an environment that doesn't have strong DevOps practices. I believed in this so much I ended up starting a consulting company centered on these practices with a simple mission: bring joy back into work, and help large organizations ship as fast as startups.
But as it turned out, my adventures with DevOps was just another step towards my final destination: blockchain.
Moving to Blockchain: The Next Level of Empowerment
While my journey through leadership training and DevOps centered around the theme of autonomy, it was discovering the world of blockchains where I truly understood how meaningful autonomy is. Autonomy, or having complete control over one's environment, is inherently linked to the permissionless, open-source, and composable nature of blockchains.
I first started exploring blockchains through work around 2016 or 2017 as part of some experimental labs we were running about innovative and disruptive technology. Looking back I'm not surprised it didn't go anywhere. In his book Read Write Own: Building the Next Era of the Internet, Chris Dixon explains why:
[Blockchains] let you write code that makes strong commitments. Individuals and organizations don't have much need to make commitments to themselves. That's why attempts to create 'enterprise blockchains,' which function exclusively inside corporate organizations, haven't been successful. Blockchains are useful for enabling coordination among people who don't have preexisting relationships.
Outside of owning some bitcoin and ethereum through Coinbase I didn't get deeper into blockchains until the NFT boom of 2021 when I got my first self-custody wallet and started actively participating. My introduction to blockchains were first through narrative projects like Crypto Coven and Philosophical Foxes, plus education through podcasts, research reports, twitter and a 30 hour full stack developer course.
The more I learned about blockchains, the stronger the gravitational pull to learn more became. Blockchains' inherent design is the ultimate invitation for people seeking autonomy. With no central authority or gatekeeper, the blockchain space champions open source values and rewards those who are willing to learn, have skills and want to contribute.
This path eventually led me to joining Farcaster, a sufficiently decentralized social network built on the ethereum blockchain, in late 2022 and that's when I started to truly see with my own eyes the promise of blockchains and how they can provide more autonomy, empowerment, and freedom for individuals. Seeing developers build on top of the Farcaster protocol is mind blowing for someone who came from the corporate world of top-down decision making.
Examples of persmissionless innovation include any of the many different clients that are built on top of the Farcaster social graph, including Supercast, Searchcaster, Farcaster User Stats, Outcasters, Events, tokens like $degen, $higher, DAOs like Purple, art like FarCats, the FarCon user conference, the GM Farcaster news show I started with Nounish Prof, and the many hackathons that launched as soon as Frames were announced.
Conclusion
Over the last decade, my journey from leadership training to embracing DevOps, founding a consulting company, and diving deep into the world of blockchains has been driven by the slow pull towards more autonomy. This journey has taught me that autonomy is more than a mere luxury; it's a fundamental human need, as Matt K. Parker explains in A Radical Enterprise:
Autonomy is the human need for "control over one's environment" - to feel like we "have choice within any given situation," which in turn is strongly linked to individual and organizational success.
When deprived of higher-level psychological needs, our mental health suffers, but we also become motivated to rectify our deficiencies. We will be naturally, instinctively drawn to deficiency-gratifying environments. And under free-choice conditions, we will engage in those environments in quantities sufficient to remedy our mental health.
Parker's insights resonate deeply with my experiences. Witnessing what happens when individuals are truly empowered has been the most rewarding aspect of my journey. Whether it's leading a team with the principles learned from LPMA, streamlining software development through DevOps, or fostering community within Farcaster, the common denominator has always been empowering people to take control and to innovate.
This path of increasing autonomy isn't just a professional quest; it's become a personal mantra and a universal principle that can guide us towards more fulfilling and successful lives. As I look to the future, embracing autonomy whether within the corporate walls or the wild gardens of blockchains, will remain my north star.
Notes
LPMA was based on research by Dr David McClelland, Dean of the School of Psychology at Harvard University who led research in the 1950s to answer the question "Is there a personality variable in male progeny that if changed or aroused can predict the economic performance of a nation?"
My definition of DevOps has been informed by several books including Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations and The DevOps Handbook
