A thing that came through self-reflection is that my previous work projects were hyper-focused in one area, and that this focus came at the cost of giving up on my interests in other areas. I dedicated the last fifteen years of my life to an in-depth exploration of the most difficult problems in computer science—e.g. naming things, cache invalidation, off-by-one errors, data locality, access latency. The more money I made exploring these topics and their interactions in systems, the less I chose to investigate other interests. This includes both old interests—e.g. regional cultural differences, linguistics—and new: finance, incentive systems, organizational hygiene, business ethics, marketing and sales.
A keystone moment this month happened when I encountered this question: “do you prefer solving problems or building a product?”
I am being paid handsomely to solve problems, but one thing is sure, as clearly today as it was already ten years ago: I am so much better at building products. My intrinsic motivation, if there is one, is to optimize the experience of a user (or customer) approaching my project from the outset. Sure, I find the internal quality of products essential, but to me quality is essential because it is what underlies suitability for purpose in the eye of users. My driver is suitability, and sometimes user delight can be achieved with just 80/20 technology and instead a serious investment in stellar documentation, support and integrations. I like clever technology, but only to the extent cleverness reduces the implementation effort and liberates my time to work on experiences instead.
(Incidentally, I had built that point as one of the central arguments of my doctoral thesis, more than ten years ago. Yet, at the time, I had not realized it was as a driving factor of my work in other endeavors too.)
❦❦❦
A side effect of my subvert interest in product building, over the last few years, was internalizing how much dependent a project’s success is on a team that combines the various required skills. The more business there is to run, the less chance that a single person can deliver properly in all the areas that need attention.
Again, all the above talk about “product building” is a recent realization. Recent, as in, a few weeks fresh. The interest was always there, but only at a subconscious level. Nonetheless, that interest pushed me to develop strong opinions about various areas of running a project. Co-workers saw me increasingly often stick my neck out of the proverbial woods to meddle^W explain my views on how to develop an ambitious roadmap while keeping tactics practical and low-key, how to structure documentation for diverse audiences, how to create a layered narrative to feather adoption, how to onboard new team members, which roadblocks to focus on first, etc.—all the while rumbling when non-optimal choices were being made and whining when my suggestions, as valuable as they were, were neither taken up on nor rewarded.
❦❦❦
Not knowing what I did not know (even thought it was staring at me in the face all along, I just did not see it), I tried to find insights in leadership science. So I avidly consumed a large volume of literature from the Harvard Business Review, followed by a constellation of works from both online and paper authors.
Then, four things happened.
One is that I learned a thing or two about leadership. I have gobbled up historical perspectives (e.g. evolution of power structures over the ages); geographical variations (e.g. differences in leadership structures across cultures); sector variations (tech vs manufacturing vs services, etc); and quite importantly, the fundamental difference between leadership and management.
The second thing that happened is that I started seeing patterns of leadership around me, and detect quite a few leadership failures with momentous consequences. I would dare say that the tech industry is much less meticulous about good leadership than many other sectors with a longer history. There is a perverse incentive at work: good leaders choose to operate where good leadership is appreciated, and tech people do not know how to do and recognize good leadership because they largely have not experienced it before; and so the two communities (good leaders, tech people) remain at a distance. Tragic.
The third thing is that I realized that leadership science is mostly descriptive, somewhat predictive, but not prescriptive. There is nearly nothing recorded about leadership that can teach someone to become a good leader. Reading (or watching, or listening) about leadership is like watching performances at the Olympic Games; it does not teach one how to become an athlete. Listening to leaders talk about leadership to each other (e.g. to share experience, asking for advice) does not commonly lead to actions that increase the impact of their leadership. In short, leadership as a learnable skill is an art more than a science.
The fourth thing is my other realization: that leadership is merely a mean to an end. A project exists from a goal, some substance and an audience, and leadership merely provides it with momentum and resilience. The former can exist without the latter (albeit inefficiently), but the converse is not true.
At the end of this series of realizations, I came to a conclusion: a successful project’s foundation is one or more people doing a thing together, and then when the time comes to make the thing bigger or more durable, leadership emerges as a vehicle to achieve that, and then the group might choose to specialize skills and push more specific leadership responsibilities into fewer hands. These still remain service hands though (even though some folk forget that).
And so now when I read online adverts about a self-proclaimed CEO looking to hire “their first technical person”, I laugh: I just see a cart before a horse, and some unspoken questions about the wisdom to start becoming the “doer” for just half (or less) of the equity.
❦❦❦
Another recommended read from this month, topical to the above, is Brené Brown’s Dare to Lead. It focuses on vulnerability, and the various ways effective leadership emerges from it. This, too, was an eye opener.
It will take me a while to fully process what this book aims to teach me.
❦❦❦
References:
- Harvard Business Review: https://hbr.org/
- Brené Brown - Dare to Lead: https://brenebrown.com/hubs/dare-to-lead/
is an entrepreneur who occasionally publishes field notes on systems, leadership, and the messy edge between technology and people.
Comments
Interested to discuss? Leave your comments below.