CTO Foundry: Learning Corner #1

CTO Foundry: Learning Corner #1

Every venture capital firm spends a lot of time meeting founders, creating content for them, and helping them get together to share learnings. We thought it’d be great if the same attention and opportunity was offered to other key groups in the tech community. Given my background as a software engineer, I was hoping we could start with a program for top VP and Directors of Engineers at tech companies who are looking to stay up to date on the latest tech trends, expand their network, and build their leadership skills.

That’s why we created the CTO Foundry, a small community of engineering leaders who will come together for small events ranging from Learning Corners with existing or former CTOs to small local dinners.  While our full conversations are meant to stay private, we will compile some of the key learnings so that the broader community can benefit from it too. If you’re interested in joining our events, please drop us a note at [email protected] and [email protected].

Lessons from Kohsuke Kawaguchi

Our first CTO Foundry Learning Corner was led by Kohsuke Kawaguchi, creator of Jenkins and previously CTO of CloudBees, a unicorn in the CI space. Kohsuke recently founded a new company, Launchable, a test intelligence platform which helps engineering teams speed up their CI runs. By analyzing your pull request code and previous builds, Launchable uses machine learning to pick the smallest subset of tests to run in order to be confident in the code you are shipping.

Kohsuke has spent most of his career in the developer tools space. When he started his career at Sun Microsystems he was spending a lot of his free time building open source projects; one of them, named Hudson, was the initial version of what is today known as Jenkins. The project started because of a personal problem he felt: he’d make changes to the code which would break the build, but he wouldn’t realize until it was merged into other branches, disrupting everyone’s workflow. Today we almost take it for granted that all code changes go through a CI build, but this wasn’t the case at the time!

Hudson was eventually forked after Oracle acquired Sun, and became Jenkins. Kohsuke spent almost a decade as CTO of Cloudbees, a CI company that worked on a commercial offering for Jenkins. One of the things he observed during this time was that the CI process was producing a lot of data, but it was not being used to increase developer productivity. Most engineers wouldn’t test selectively based on changes, but they just run the full build. While Cloudbees helped organizations with continuous integration, which increased productivity between developers and the entire organization, Launchable focuses on helping individual developer productivity, which felt to him like a natural continuation of his career journey.

Creating a culture built on trust

Despite everyone in tech adapting to a virtual environment, Kohsuke reminded us that building trust is rooted in human connection. It is important to take the time to get to know the people you work with off the screen, even without having to return to the office. Instead Kohsuke shared that he brings all his team members together from time to time in an offsite, to spend two or three days together. He explained dedicating time to being in person allows him to build that holistic, human connection that can be missing in a virtual environment, such as spending time with their families.

Other members of the group shared virtual tactics that include anonymous surveys, where the results were released to the whole company. In these surveys, leadership can learn that people needed better work-from-home setups or felt a lack of mentorship. While sharing these survey results felt risky because it exposes leadership, the move also creates a layer of trust between employees and leadership. This way team members felt their voices were heard and also felt leadership was staying accountable and actively moving towards improving their experience.

Hiring in a hot market and retaining talent

While talking about team culture, the discussion moved to the realities of the difficult hiring market and the intense competition from FAANG’s generous compensation packages. KK shared that he was focused on hiring folks who wanted to be involved in his mission. He built these relationships ahead of launching his startups through his open source work and community engagement, and some of these people followed him to CloudBees and Launchable. Others in the group emphasized the importance of creating a positive culture through hackathons, constant communication and learning opportunities. This employer brand is crucial when attracting talent. As Matt Price from Cloudflare said in the past: “One of the smartest decisions we made at Cloudflare was recognizing that the primary purpose of our blog was attracting employees, not attracting customers.”

Both culture and mission are also related to retention. Upskilling opportunities was one piece of it: one Senior Director of Engineering shared that they were paying for online courses for their employees, including a full Masters in CS or an MBA. While it is an upfront investment, it’d be much more expensive to hire someone with those credentials than it is to cover tuition (1). Lastly, staying on top of compensation is critical. It is not that you want to optimize for talent that cares about money, but ensuring that everyone has equitable pay when compared to the market is important. This may mean a reevaluation of your current compensation bands, possibly as frequently as every 6 months.

Measuring developer productivity in a way that makes everyone happy

Kohsuke shared that as an engineering leader, measuring productivity did not come naturally to him at first. As an engineer himself he was initially opposed to any type of metric or number that would be used to summarize his productivity, such as lines of code written. As an Engineering leader, he realized that he needed a way to quantify the team’s productivity with leadership so that he could make a case when the team needed additional resources. He and the group shared a few helpful tactics to measure engineering productivity and getting buy in from the whole engineering organization:

• Always be transparent - at the outset make it clear why you need to create some way to measure productivity (i.e. you need to hire two more engineers to meet the demand, but you need to justify that to the rest of the organization).
• Start broad - start with a “blanket box.” Get buy in on one area where you would like to measure productivity. Test out how that goes with the team and then move forward.
• Measure at the team level - if your engineers do not want individual metrics, segment the metrics by team so that no one person feels like they are being targeted. (2)
• Use surveys - Give the engineers a voice outside the automated metrics. Ask engineers to rank their satisfaction and time spent on certain tasks on 1 to 5 scale, this contextualizes metrics such as number of code reviews, jira intakes etc.

Another suggestion was making developer happiness one of the company’s KPIs. This allows engineering teams to better weigh the ROI of developer tools, etc outside of a basic productivity calculation around features shipped and the likes. This can be measured on a quarterly basis through the same surveys shared with the team.

Growing as a VP or Director of Engineering

Despite being a leader, KK reminded us that you are never done learning. As he became CTO of CloudBees, he shared some useful tips for staying on top of your game, with learning being a core part of it. He explained that as CTO you need to focus on more than just engineering execution, but also on product direction. As a result he took Product Management courses, not to be a PM, but to work alongside the rest of the organization more effectively.

In addition to continuously upskilling, other members of the group shared the following tactics:

• Executive Coaching - while not for everyone, many people found that having an executive coach helped them realize their own core competencies and also areas that needed improvement. This increased self-awareness and ultimately drove them to work better with other team members.
• Be a mentor - Sometimes the best way to learn about yourself is to help others. By actively setting aside time to listen and mentor other individuals, you learn where you need more expertise. (3)
• Knowledge-share with peers - find an equal that you trust and who you work closely with. Set up time to give each other genuine feedback. As this is someone you trust, you will understand any critique is constructive feedback and it will help you improve.

Fun fact about our speaker

In these events, we always try to have people share some of their personal hobbies. Outside of being a great engineer and leader, Kohsuke is also an awesome bike rider! You can follow along his adventures on his personal blog. He is going to ride from San Francisco to Los Angeles for the annual SF AIDS LifeCycle ride: “I’ll be riding 545mi/877km over 7 days, climbing 23,000ft/7,000m in that process. Frankly, that is a scary challenge.”

We hope these learnings will be useful to more people in the engineering leadership community, and we’ll hopefully have more of you join us for the next one!

1. This thought was contributed by Rohit Sureka and reflects his personal opinion not the opinion of his company. Thanks for the contribution Rohit!
2. This thought was contributed by Lata Ahuja and reflects her personal opinion not the opinion of her company. Thanks for the contribution Lata!
3. Ibid