#1: SparkToro’s (previously Moz’s) co-founder, Rand Fishkin, shares Moz’s CEO, Sarah Bird’s recounting of how she took the unquestionably arduous third path of furthering herself enough to lead great tech teams. (Source)
Let’s use software engineering as an example because it’s something so many founders and would-be founders in the startup world struggle with (just look at the thousands of questions on startup-focused forums that begin with “I want to start XYZ but am not technical . . .”). Assuming you’re like me, and this skill is currently a level one [Theoretical knowledge or less] or two [Managerial knowledge], your options to make this a strength are straightforward:
- Learn the process and do it yourself.
- Start the company with co-founders who have this strength already.
- Invest in the knowledge necessary to hire, retain, focus, and manage great talent in the field.
Nearly every piece of advice I’ve ever seen ignores the last one and focuses on the first two. But after Sarah Bird became CEO, I watched her go from the low end of level one to the top end of level two, and turn a fundamental weakness we’d had at the company throughout my tenure (with only occasional success stories like the early link index) into a core strength in her first eighteen months leading the company.
How did she do it? I asked Sarah to contribute so we could hear directly from the source:
“Before Moz, my only software engineering experience was a Computer Science 101 course many years before. My lack of technical depth made me feel insecure about managing engineering leaders and teams. It was pretty easy to discern when development wasn’t going well, but it often wasn’t clear why. Was it because I had the wrong CTO? The wrong engineers? Perhaps the technical problem we were trying to solve was harder than we imagined? Maybe we didn’t have enough resources? Or the right resources? Were we underinvesting in development infrastructure and tech debt? I can spin myself in circles trying to understand the why.
Here are the top things I did to become a better leader of technical people and teams:”
Ask questions during skip levels (meetings where a senior manager meets with team members who report to the managers below them) with engineers that go beyond identifying problems and into concrete solutions. For example, asking, “What good development practices did your last company have that you don’t see in play here?” surfaces best practices.
When you find an engineer on the team who can articulate different strategies she has tried, and the why behind them with conviction and clarity, give her power to try implementing some of those changes here. Be her champion, even when she ruffles some feathers making change. If some of the strategies don’t work out, praise the effort.
Read everything you can about different engineering cultures and best practices. Read dev blogs for companies like Spotify, Netflix, and Airbnb. There are a lot of great books, blogs, and conference talks about best practices. Invest time to consume as many of these as possible. For example, I follow Edmond Lau (a software engineer who worked at Google and Quora, and runs the EffectiveEngineer.com blog) and Jez Humble (who works at UC Berkeley and runs ContinuousDelivery.com) pretty closely. Go beyond the slogans into the meetings, habits, and platforms high-performing teams employ.
Take notes about the technologies and practices that you hear about in design reviews and one on ones. Then go back to your computer and google them like crazy. Read everything you can about the technology. While reading, keep in mind that engineers are famous for indulging in so-called religious wars about why a particular technology is “so much better” than another one. Learn to spot it when an engineer moves beyond advocacy to naive devotion to a particular tech. Take everything with a heaping spoonful of salt. You need to know the lovers, the haters, and the companies that are using the tech. There’s no such thing as the “perfect solution,” and beware anyone who tells you otherwise. It’s all trade-offs.”
Recruit technical leadership with a teaching orientation. The best way to “ensure that your CTO is going to make you a better CEO is to hire a CTO who likes to teach. Make it clear that you’re looking for someone to drive change and educate you and the team. Beware CTOs who try to “shield” you from the details. Being able to explain complex things simply is a job requirement.
Ultimately, leading technical teams comes down to curiosity and courage. You must be humble, ask questions, and read a lot about engineering. If incremental changes aren’t getting better results, you need the courage to change technical leadership. Keep changing and trying new things until you start seeing positive momentum, and then get out of the team’s way.”