My Leadership Principles I

It has been 5 years since I started my first job, and since then I have always worked in startups or on products that required exploratory as well as iterative development processes. That means I have always been in small teams (minimum 2 and maximum 10 members), when there was a team at all. Such teams and people tend to experience fewer top-down forces compared to larger, more corporate environments. That is simply because exploratory work is meant to shape the destiny of the product. In this text, I want to document the two key leadership principles I have observed that helped me and those around me succeed. The first one is:

High Agency

Have you seen people who take on extra weight? The ones who usually break the silence with their initiatives and findings, the people who keep the fire going. I’ll tell you: no successful product is built without someone playing that role. If you look around and see a working mechanism, then someone is driving it—someone doing more than their defined duty. They might be a researcher in an academic group, an admin of an online platform such as a Telegram group or a Discord server, a member of a paper-reading group, or simply a CEO. The best CEO I have worked with was also a coder. He started coding out of frustration with the narrow thinking of some engineers—not because he was brilliant, but because it had to be done. The team was busy trying to find the best heuristic, and he dropped in a simple meta-heuristic that worked very well.

Such people are easy to recognize by their persistence. Their actions are all about removing blocks and keeping the cycle going. They do exploratory work so that others can ship. They organize meetings, send invites, ping you in chats, and review your code. They don’t go with the flow—they drive the flow.

Being Articulate

The reasons behind this are obvious, and the rewards for having it are immediate. Let’s think in reverse: what are the costs of miscommunication and misunderstanding? They result in wasted hours—now, later, and possibly forever. Misalignment leads to longer debugging and development cycles per feature or bug. Worse, different understandings of product or software decisions can result in bad or overly complex systems. This has even been formalized in the software community as Conway’s Law (my favourite software law!):

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

The example above is in the context of organizing product teams. But on the individual level, one gains more by explaining themselves clearly and succinctly. That way, people earn the trust and respect of others. I have seen this happen in funny ways. For example, people start copying the articulation mechanisms of more articulate colleagues. I have silently copied from at least a dozen people, and I’ve seen others copy from me. In fact, today I saw my sister making jokes in our dad’s style. That’s copying from leaders in action.

These were two examples of leadership principles I found truly important within startup and product teams. This is by no means an exhaustive list and I will keep adding more.