[Editorial note: This is the third post of a six-part series. If you missed the first and second post, check out, “CTO Spotlight: Q&A with Roman Shaposhnik (Part 1)” or “CTO Spotlight: Defining the CTO’s Mission (Part 2).”]
Last time we chatted with Roman Shaposhnik, Co-Founder and CTO at ZEDEDA, and learned what’s included in a CTO’s mission, the “northstar vision,” and the CTO’s primary role and responsibilities. He continues the conversation and dives a bit deeper into the significance of engineering’s open source culture and how to properly measure the CTO’s performance. Let’s take a look.
Q: How can the CTO maintain the engineering’s open source culture?
A: The CTO must rally the engineering organization towards the long-term technical goals of the company and align them with the open source technical culture (even for the parts of the product that are not open source). This is mostly done through CTO maintaining and executing proper open source rituals when it comes to engaging with the outside community (i.e., community calls, design summits, open source developer programs, hackathons, etc.). The idea here is that it may be desirable to extend the reach of those rituals into the rest of the engineering organization (open source or not). The fancy term for this is inner-sourcing, but it really just boils down to maintaining a single engineering culture in the organization.
At a more practical (or corporate if you will!) level, the CTO must be able to inspire new engineers to join the engineering organization and must help in the sourcing or identification of such talent. The CTO then becomes a chief recruiting officer as well, but not through some fancy marketing – rather by being an embodiment of the technical culture that makes the company capable of attracting and retaining technical talent.
Q: How does a CTO properly measure his or her performance?
The health of an open source engineering culture is one of the areas where measuring CTO performance is rather easy. A lagging indicator is significant attrition of top engineering talent, or inability to attract new top talent to the company. On the open source side, this could be measured by various standard metrics around community health and open source project maturity (as established by the Linux or Apache Foundations).
Q: As ZEDEDA’s CTO, what advice do you have for others as they consider new approaches and strategies?
A: The most counterintuitive part in splitting the CTO time and responsibilities into a new role is internalizing that, in many ways the CTO, similar to the CFO, is a service center to all the other organizations in the company (more on these responsibilities later). If these internal organizations don’t feel they are getting value added out of the CTO, then there is no point in having a formal CTO role (in a small company) or perhaps the CTO needs to be fired (in a bigger company). Another surprising bit to keep in mind is that even though CTO is a services organization, that service is split about 70% external focus vs 30% internal focus. But, I’ll wait to elaborate more on this during our next discussion!
In the upcoming blog, we’ll transition into considerations and approaches for allocating time and effort into the CTO’s role and organization. You’ll get to learn and understand what the time allocation breakdown looks like from Roman’s perspective! In the meantime, feel free to check out this interactive webinar, “Mythbusting OSS – Transform Digest Series,” where Roman and other panelists discuss open source software and collaboration.
