Leading In The Open

I make an effort to document my learnings so 1, I can make sure they stick and 2, to look back on them with new eyes of additional experience to see if I interpret them differently. As I work toward documenting a new leadership plan at the dawn of a new project, I am reflecting on what I’ve learned, what I can do differently, and how best I can enable agile success and sustainable growth.

Some back story

My pathway to leading engineering teams has been linear. I started by being an individual contributor to projects which soon turned into leading projects. This elevation had me looking further down range which naturally distilled a vision that encompassed multiple projects and stages. Through this growth, I found that my strength lies in my ability to “see the forest” and find the best path through to the other side, which lead to me leading teams to build the things that progressed us down that path. To my amazement, I found that I struggled as a new leader getting people to see what I saw and how often I was met with a lack of emphatic support. You see, I naively thought it was obvious. “Don’t you see it, it makes so much sense. If we just do x, y, & z then f(x,y,z) becomes possible and with f(x,y,z) the problems of business(a_1(f),a_2(f)….a_n(f)) are solved.” Seeing this laid out plainly was enough to make my heart race. So if it did it for me, it should do it for them too.

This is where I learned that having a vision and leading people under it are two very different things.

The transition from individually contributing to another’s problem definition versus leading others to your own isn’t one of your perception, but of their interpretation. How they see the world, the company, the problems within it, the problems at hand and how best to solve them. This lens by which others see the world is completely formed by the melding of the individual’s background, experiences, beliefs and expertise. Therefore aligning individuals to the same vision, common deliverables and milestones wasn’t going to be as simple as pointing at a flag far down the line and expecting everyone to take the same steps to get there. You had to give them the raw materials that enabled them to reconstruct the path with their own hands.

This broke my black and white brain.

But also made me realize figuring this problem out is what unlocks unbounded potential.

What is leading?

I’ll cut through how I got there which included talking to many more experienced than myself, sifting through aggrandizement and corporate ideologies to come to these core truths.

Leading is simply:

  • Building a vision for better future

  • Communicating that vision to your team in a digestible way that makes goals clearly defined and achievable for all functions

  • Fostering an environment where everyone can align and produce outcomes in the most efficient and sustainable way

The second order details are: what makes a good vision, how you communicate it, how you define success, how you create culture and grow people. But I’ll leave that as an exercise to the reader. (insert how to draw and owl)

Defining this in a plan that has time based actions, cadence, direction and structure takes you out of leading into an instruction set of how to grow a garden where individuals produce the fruit that gets everyone toward the end goal.

I used this model to lead teams from 5 - 40+ engineers across multiple disciplines and a multitude of projects supporting the production of many of the Boeing aircraft flying today. It not only drove execution and transformed areas of production but it ultimately upended the way I saw my role from a hard-headed executor (define>assign>manage) to an orchestra conductor (as much listening as instructing, making a symphony from individual inputs).

How blockchain is different

When I came into developing in blockchain, I (naively) approached leading in the same way. This is the vision, build the team, we collaborate to make success measurable, write the music, put it to a metronome that creates tempo and measurable progress in an environment that supports it. The problem I quickly came to realize was that the formula for success that I had come to be so comfortable with now had this other factor in it which I wasn’t prepared for. This factor seemed to act as multiplier to performance, which if fractional impacted all areas, and if greater than 1 emboldened all with a nothing-can-stop-us attitude.

This is the public and open nature of building in this space. Most just lump it into one all encompassing term, community, but it is more multifaceted than that. It encompasses the need to get people interested and excited by what you are building, transparently sharing code and progress, succeeding and failing publicly, with a constant external voice of ideas, encouragement, demands and criticisms.

To formalize it, the game now became:

outcome = execution(vision, clear_definitions, capable_team, culture)*f(community)

where f(community) was some black box function that had a large determining factor to the outcome despite engineering execution.

I knew there was a power in harnessing it, but felt as clueless to how as I did in harnessing the power of my employees when I first became a manager.

Leading in the open

So taking the learnings I had in building DeFi (which really ended up being trying to juggle what I knew how to do with trying to solve for the unknowns in the above equation), I began writing the new execution plan for the next project. It had two distinct sections. One for the internal team, and one for the external community.

Where I have spent months steadily filling out the structure of an overarching vision to meaningful execution steps and how we are going to get there, I left the community section largely empty. I felt a bit aimless (and maybe a bit reluctant) on exactly how to handle it.

When I finally started, I asked myself, what do we need them to understand of our vision, what and how do we communicate that to them, how do we externally demonstrate progress to our goals and enable them to contribute in a way that is mutually beneficial.

Then it clicked. These questions have a striking resemblance to the outline of leading above.

That community, them, really is just the no-boarders, lower case generalization of us, the team. They are part of it. Just the other side of a very faint line.

In this space of open development, all anyone needs is to understand the vision, with tangible outcomes, that allows them to align to it and feel a part of it. If done well, that alone will enable them to amplify, accelerate and contribute. One vision, one goal, no boarders. This forces us to be open in leading and open in contribution (in the truly general sense of feedback, ideas, marketing, code). It is the resistance to this or the effort to change the core characteristic of developing in this space that dims the possibilities of what can be.

Of course, this assumes commonality on the value alignment of us and them. Values are like momentum vectors. If we aren’t all aligned, even slgith deviations from individuals can impact the rate of progress or worse, begin changing the momentum vectors of others). This is why value alignment must be the foundation to any vision worth doing, embodied by the core team and underlining all decisions. Then, identifying any non-value aligned contributor is as easy making sure their paint is the same color as whats on the wall.

What about in general?

What is remarkable about this concept of “us/them” is in its ability to be generalized to any level or hierarchy. We can easily reframe “us”, building a project in blockchain, as “them” to another project or team. And while this might make sense in more traditional, Web2-style closed development, it doesn’t make sense in open development that is so deeply value aligned. In fact, in the macro view, there really is no us/them duality in the bubble of value aligned projects. There is only those that do what they can to push toward the end goal, aligned under one vision of a trustless, permissionless, boarderless fabric for society. We are all just sub-teams under the larger Team working to build a similar vision.

This us/them duality can also be brought to the top of the stack and be used to better understand the human experience. To define anyone as “them” creates division, denouncing the very things that make us all the same: we are born, we learn, we grow, we have dreams we strive for, we love, and eventually we all leave everything behind. This perceived division which births all contention becomes just noise at some altitude.

So whatever you are doing, there might be some wisdom to be gained by finding the right altitude to asses the problem and the people involved.

Admittedly, that got a bit more spiritual than I intended but the realizations couldn’t go unsaid. But as usual, the more exciting bits of any lesson are left to the reader to explore.