What does it mean to be a technology leader? This has been and still is a perpetual question for me. In this post, I’d like to reflect on what I learned about technology leadership in my experience as the creator of Jenkins and as the CTO of CloudBees.

Leading by Code

When a software engineer rises in prominence through the popularity of their work, the first phase of the leadership is what I call “leading by code.” People around you notice that you are doing some great work, and they start paying more attention to you. By this point, you own a lot of code, meaning you’ve probably written quite a bit of code of the said software yourself, including the heart of the design and the architecture. Owning code gives you upper hand in many ways, which you can use to influence others:

• You probably are the most knowledgeable person for many parts of the system, so whenever somebody tries to build something anywhere, they want your input, approvals, or maybe even some matching change from you.
• Your code, coding style, and how you produce it all become the baseline for everyone. In trying to do “monkey see monkey do,” they seek your input and approvals.

In essence, you lead by being “a better doer.” I remember that this felt great. Engineers close to me did not need a title change to know the influence I was radiating, but now my boss, my distant friends, and people who are looking at my LinkedIn resume knows that I’m a leader! I also obviously believed that my way of doing something is great, and I was helping others do it better. I wasn’t really changing anything I was doing before – I kept writing code, just more often together with other people. When I wanted something to be done in a certain way, it was usually followed. Everyone wanted my input. What’s not to like!?!?

Limit of Leading by Code

I think “leading by code” comes naturally to everyone. I’ve seen many senior engineers who perpetually stayed in this comfortable mode. But today I believe it breaks down at a certain size of a team. I now think, perhaps selfishly, trekking beyond this comfort zone is what differentiates a technology leader from a better software engineer.

Why does “leading by code” break down? Simply put, you become a bottleneck.

• Bandwidth: if everyone needs your attention and focus to get their job done, then you run out of time. When people start doing things increasingly on their own as a result, you feel threatened, because you feel your control is slipping away and other people are developing deep expertise in various pockets.
• Creativity: when you influence others by basically controlling what & how they do, either directly by telling so, or indirectly by controlling a tribal custom, it naturally limits other people’s creativity. This is a hard one to see when you are in the middle of it, because there’s always some room of creativity that you can point to.

That is me in 2019 speaking. I didn’t have a perspective back then to think in these terms. So I’ve probably stayed in this mode of leadership for too long, feeling increasingly unhappy and disappointed at myself. There were a few signs that this leadership style was hitting a limit.

• At one point, I wanted to design and write an interface between two subsystems myself, because “owning code” was how I was exercising the influence. People implementing the two subsystems weren’t happy at all that I was lagging behind, producing something different from what they wanted. It didn’t help me either because I lost some credibility in their eyes, rather than gaining influence!
• I was in a design fight with somebody under me, and I couldn’t resolve it in an amicable manner and ended up just overriding him. I remember him saying “I’ll reserve the right to tell you I-told-you-so.” I had some reasons for doing that, but really that’s beside the point. He got demotivated, and it created “my way or your way” framing. He’s also now rooting for you to be wrong, and sooner or later, you WILL be wrong!

So I started exploring other mode of technology leadership.

Launching a New Project

One of the things that worked was to focus on launching a new project/product/effort. The idea is that you basically get embedded into a team for a while, then transition out when the time is right. I’ve done this several times, and I think it suited me well for several reasons:

• I could “lead by code” with all its benefits without much of its downsides because new things start small. I could steer a team toward a general direction without making people feel like you are telling them what they do.
• New things benefit from an executive sponsor who communicates progress upward, keeps unwanted disruptions at the bay, builds bridges to where necessary, brings input, context, and perspectives from other parts of the org.
• When a new team is formed to take on a new thing, which I suspect is a norm in a startup, I can help the forming and norming phases. I bring in “how things are done around here” naturally thanks to the title, and speed up initial decision making. Just don’t forget that you will be wrong on some of those decisions, and you got to let the team take over and fix some of those. That used to feel embarrassing, but now I take it as a sign of a maturity of the team.
• I suspect one of the things that keep the CTO role influential is being on the side of change, as opposed to being the defender of the reality on the ground. Being seen as a part of new projects is helpful with this regard.
• And new things are fun, so it kept me engaged!

Storytelling

As the org grew, the number of people I needed to influence got larger, and I found myself leaning more and more toward a meaty, structured write-up, as opposed to email dialogs, or 1:1s with key individuals. This blog post itself is a good example of such a write-up, albeit too long.

A write-up can start with a recap of context, or cross references to earlier write-ups, which help larger number of people to “get it.” Writing down helps you organize your thoughts more clearly and think more thoroughly. Your message also won’t get lost in Chinese whisper game, when people forward your message to others. It takes more time to compose one, but the wider reach makes it worthwhile.

CEOs and managers of big orgs do this all the time, but I think technology leaders should do this more, too. And you don’t need to use the “unicorns and rainbows” voice that they use, either!

I started consciously doing this more and more after getting hooked to great storytelling podcasts like This American Life and Radiolab. Those podcasts got me thinking a lot about how to tell a story better. When it works, it makes your write-up more engaging, and it frames how people think about a certain thing. When you succeed in that, there’s no need to sell people a solution. I’ve sought some help from people who studied journalism, and I’m seriously wondering if there’s more training/class available in this area.

Aside from one-off write-ups, I’ve run two series of write-ups that have certain themes, and both had great tractions. One was a series of “portraits” of people who we are building our products for, and the other is things I’m noticing about what’s going on in the industry, such as event reports.

I’ve done most of this on Google Doc, and what I loved is that people can comment on my message to add more colors, which makes it a whole lot more valuable. OTOH, Google Doc sucked at helping people find your write-ups, and that took a lot of value away from it. If Confluence was more loveable experience, I would have switched.

1:1s with CTO

At around ~100 people, and as I developed a “storytelling” broadcast channels, my 1:1 interaction with engineers started to change in nature. It used to be “outbound” where I tried to influence key senior people. It now became more “inbound” where I learn great ideas, interesting efforts, and/or their challenges from people. People were much more willing to talk about that in 1:1 and all I needed to do was to prime the pump and listen attentively.

So I started to encourage them, help them get more time working on them, and so on. Basically, find a pocket of excellence and try to lend my credibility to grow them.

It’s much easier to make something happen when there’s already somebody who’s thinking about it and passionate about it, even considering the downside that is “it’s not exactly how I wanted it.” I’d also like to think it creates a workplace that engineers want to be in.

I’m still trying to figure out how best to do this. When you skip reporting chains and go directly to ICs, it can be disruptive. You can’t create a change without creating any friction, but you want to minimize that. Also, not every ground-up effort pans out, and when they fail for one reason or another, it can be really disappointing for the person I encouraged. Expectation setting can be tricky, and so much depends on individual context and the personality. When an effort does pan out, the next stage of the project needs more serious organizational commitment, and I often struggled to bridge that smoothly.

Toward the end, I started thinking about creating a rotating position to do these “incubation” projects by pulling engineers out of their regular positions and time-boxing projects. This felt like a promising idea – it makes the whole thing a repeatable program that other people would recognize better, and hopefully that encourage more people to bring ideas to me and help with the “next stage” problem.

Architecture Forum

I’ve seen this done in many places, but I’m not sure if I cracked the nut. I’d love to hear from people who has done it successfully. The idea is that you have many teams with defined territories, and you drive the alignment/collaboration between them through meetings where people from those teams come, present, and talk to each other.

• I thought the way to make this valuable is to ask them questions. What about observability? Have you thought about this failure mode that happens all the time? Help them tap into organizational memories. Bring concerns and realities from the field. But I felt one-hour session is too short for that, and there’s always somebody from other teams who ends up in the “let me design it for you” mode who speaks too much.
• When I invited one person from every team to be on this forum, some people thought “hey how come Alice is invited but not me?” and that made them unhappy.
• I suspect many engineers just don’t have the mindset of “there’s always something to be learned from new perspectives” baked into them, and those people don’t feel a real value from this setup. When enough people do not feel value, it’s too easy for this to become a bureaucratic formality.

In retrospect, I think a better way to do this is eng-org wide continuous education. I could have identified people who can speak to those concerns, perspectives, and context, and perhaps I could have a dialog with them and capture that into a presentation, a document, a podcast, or something. That way I can amplify a voice of somebody while still creating a crafted message that I want the org to hear, and I can influence everyone, not just tech leads. And so long as it sticks to somebody in a team and they speak up, the team will be doing the right thing.

Conclusions

This post is really more of a progress report of mine than a guide book for others. Your mileage will vary.

That said, if there’s any take away for others, I think it’s that the PDCA cycle works. That is, you try something, notice that it seems to be working, so you build/adjust a mental model of why that works, then that helps you plot the next move. What started as a random search and blind shots gradually become more systematic hypothesis testing over time. You never really find answers (at least I didn’t find one), but you do find questions that are worth asking.

It was uncomfortable at the beginning, but once I felt that the cycle was going, I felt happier because I was making a progress. Then the rest became easy.

I hope you’ll find some of this useful, and I’d love to hear from people what worked for them and didn’t.