Advice for a new executive
When I was getting ready to join Kickstarter as VP of Engineering, Chad Dickerson (who was the CEO of Etsy when I worked there) offered to send me a bunch of advice. Chad had been a CTO multiple times before being CEO; he knew that this executive-level role was brand new to me, so he offered to help give me a steer and a foundation as I walked into this totally new territory.
I had no idea what Chad was going to say in his email. It ended up being CHOCK FULL of stuff that was clarifying (I made a table of contents below!), and proved exceedingly useful as I entered my role. I’ve referenced Chad’s advice so often since then; his words certainly helped me during my time at Kickstarter, but I’ve also quoted this email when mentoring and coaching other people who are considering becoming, or finding themselves becoming, a brand new executive.
I asked Chad if it’d be okay to post his advice publicly, since I’m eager to share it with many more emerging leaders out in the world. Chad and I have lightly edited it to make the content more translatable to people at any company (removing some names, generalizing some examples). A handy table of contents so you can easily link to the different points in the future:
- Find/create a peer support group
- Partner absurdly closely with product and make sure you understand priorities and the head of product understands tradeoffs
- Focus on delivery of the roadmap and everything else will follow
- Ask your executive peers regularly what you can do to make their jobs easier – particularly the CEO
- Take a stand when you need to
- Always have a story
- Read widely – offline! – about management and leadership
- Realize the impact your mood and demeanor has on people
- Develop the right relationship with members of your company’s board
From: Chad Dickerson
To: Lara Hogan
Subject: unsolicited advice, as promised!
As promised, below is some unsolicited advice. Note that I’m using CTO and VPE somewhat interchangeably below because my sense of what you will be doing at Kickstarter’s size is that it’s a combo of both (for more, Fred Wilson did a great post on the difference between the two). Note that I read the Kickstarter job description so I’m making some assumptions based on that. I’m also channeling some lessons learned and mistakes made from Etsy and other places. So here you go:
1. Find/create a peer support group
Peer support groups are great because people will talk privately about things that you won’t find them tweeting or blogging about – and those are often the interesting things!
Two routes that can be combined:
Formal:
Have a formal group (like a CTO group) that you have regular contact with. I joined a CEO group a few years ago that was really helpful to me. It was much more formal and we met for half a day every quarter and each person was expected to prepare specific topics to discuss with the group. I workshopped everything from organizational structure to key hires to fundraising to broader strategic issues with that group. I noticed a pattern that working through difficult issues with that group led to greater success. I can’t imagine NOT having such a group.
Informal:
You’re now a VP of Engineering for a company that people love, so that means anyone else who is a top engineering leader at almost any other company will be glad to talk with you. You could easily start your own group if you wanted (if you haven’t already).
2. Partner absurdly closely with product and make sure you understand priorities and the head of product understands tradeoffs
If you and the VP of Product are on the same page at all times, your life will be a lot easier. In multiple companies I’ve seen the VPE/Product relationship become strained and that is a road to pain, usually with engineering suffering the most. That’s for one simple reason in my opinion: it’s generally easier to specify high-level product goals and create high-level roadmaps than it is to write complex software. Over-communicate. Come up with an agreed-upon set of processes (e.g. sprints, roadmap reviews) and artifacts (e.g. shared roadmap) and relentlessly keep those things active and updated. The world works on delivery dates and estimates so figure out the best way to operationalize those without driving everyone insane. (I am very familiar with the “no estimates” camp of thinking but it just doesn’t work, IMO!)
I know people sometimes make fun of methodologies and how religious they are (Agile!) so I’m not saying you adopt some overly-religious framework, but you have to have some kind of consistent process with supporting artifacts that make sense to people. If you don’t drive that with product, product will likely impose it upon you. I hate using sports analogies, but I will here – always play offense or you will be playing defense. Simple rule: if you hear “what are all these engineers doing?” then you have work to do. You will never have enough engineers and there will always be more products/projects than resources available so some sense that engineering capabilities are being reasonably utilized will always be a topic of discussion.
3. Focus on delivery of the roadmap and everything else will follow
Every day when you get up in the morning, you should ask yourself if you’re doing the right thing that day to deliver on your team’s commitments. All of the other interesting stuff in engineering – conference talks, open source contributions, etc – flow from delivering products for your customers (internal or external).
I joined Etsy as CTO in September 2008 and didn’t do any public speaking or writing for almost 18 months. That was because I had to devote 110% of my energy to building momentum – getting the team in the right place and putting us in a position where we could deliver product reliably. Even when we did something that didn’t seem directly related to delivering product, it was very much intentionally related. For example, the Code as Craft blog was launched in February 2010 to build a technology brand in the industry so we could hire great people and deliver solid products and infrastructure (and it worked – so many people who joined the team later on came to their interviews already understanding our core culture and how we built things.)
Also, this may sound weird but most (maybe all) of your executive peers won’t really care about the intricacies of engineering since they are worried about other things in their functional areas. This is not a bad thing, but it’s important to understand. It’s kind of like how most people don’t care about how the finances are managed at a company or the intricacies of how payroll works – they just want to get paid reliably and on time. Engineering is similar. Go as deep as you want with your engineering team but be mindful not to create unnecessary cognitive burden on your executive peers. You’re in the position you’re in because you understand engineering!
4. Ask your executive peers regularly what you can do to make their jobs easier – particularly the CEO
You’re going to be in a senior functional position reporting to someone who has never done your job before. There will be a natural communication gap because of that and very different from working inside an engineering org with people who’ve done the work. Your job is really about being a bridge between the technology side of the business and the business itself. That means that some of the shorthand you may have developed working with other engineers and engineering leaders will have to be replaced with shorthand that your CEO and executive peers can understand. As the interface to engineering, you are solely responsible for making that work. If it’s not working, it’s on you.
Being a CEO in particular is HARD, particularly for someone who is running a technology business but is not an engineer. Read this post about CEO psychology because it is spot on and may help you empathize. Solve as many problems in your domain as you can without leaning unnecessarily on the CEO (though there is an exception – see next point). They’ll surely have enough challenges in other areas.
5. Take a stand when you need to
To be a trusted advisor to your CEO and executive team, you have to push back sometimes. It might be a ridiculous demand with a project or a broken cultural practice or some other issue. As a senior leader, it is your absolute duty to do that; however, your credibility in taking stands will always rest on delivery of product/infrastructure (see #2 and #3) and successfully running your organization. That is the basis of your social capital inside the company. If you critique HR practices, for example, but the roadmap is dragging due to engineering issues, then folks may either quietly or loudly roll their eyes and say, “You really need to focus on making sure these products / this infrastructure is delivered.” On the other hand, if you’re executing like crazy in your team, people will take EVERYTHING you say very seriously and you’ll have a massive amount of credibility. Anyone can be a critic but not anyone can build and lead a high-functioning engineering org.
6. Always have a story
A lot of day-to-day engineering work is grinding but people want to have a sense of higher purpose. Your job is to help give them that in a way that is essentially Kickstarter. This isn’t about priorities or roadmaps as much as it is is about a narrative that feeds the spirit. Peter Drucker did a good job explaining the importance of spirit in his book The Practice of Management (and apologies for his antiquated gender-biased language – it was written in 1954):
Management by objectives tells a manager what he ought to do. The proper organization of his job enables him to do it. But it is the spirit of the organization that determines whether he will do it. It is the spirit that motivates, that calls upon a man’s reserves of dedication and effort, that decides whether he will give his best or do just enough to get by.
“Code as craft” is an example of story in the way that I mean it. If you think about Etsy, “code as craft” could have only existed at Etsy and that made it powerful – that phrase seems so normal now but it was really the seed for Etsy’s engineering transformation. It was a rallying cry. Within that container, you could fit many things: “just ship,” generosity of spirit, blameless post-mortems, just culture, etc.
From a pure technology standpoint, you should also have a story. Etsy’s story for a while was around continuous deployment. What will the Kickstarter team be uniquely known for from a pure technology perspective (aside from the culture you want to build)? Try to figure that out.
7. Read widely – offline! – about management and leadership
Go beyond the hot Medium posts and management hot takes on Twitter and read some of the classics (if you haven’t read them already!) Examples:
- Peter Drucker, The Practice of Management and/or The Effective Executive and/or The Essential Drucker
- Andy Grove, High Output Management
- Jim Collins, Good to Great
- Michael Carroll, The Mindful Leader (“30 reminders of a mindful leader” from Jerry Colonna’s old blog distills the keys of the book)
I am not necessarily endorsing all of these books (and it’s obviously too white and too male), just noting that each one is provocative in its own way.
8. Realize the impact your mood and demeanor has on people
As the leader of engineering, you want to be open and authentic. That said, your moods and demeanor will have an outsize effect on the entire team so you have to be mindful of that. When you are THE leader, it’s an order of magnitude bigger than being a leader in the engineering org. Tell people when you’re struggling and need help but be careful not to drag everyone down. I’ve seen this pattern happen a number of times over the years when someone with the “cranky engineer” personality ascends to a leadership position. The person who served as kind of a trusted truth teller as an IC or even a mid-level leader becomes THE leader and consistently bums everyone out.
You have never struck me that way, so this may be more useful to you as you think about building a team around you.
9. Develop the right relationship with members of your company’s board
In my first two years and nine months at Etsy as CTO, I went through two CEO changes, complete rebuild of the engineering team, and, re-architecture/re-build of everything. (In other words, we were rebuilding the proverbial engine while the plane was in flight but the lead pilot kept getting shot, too!) During that time, I gave regular updates to the board and got to know them pretty well. Developing those relationships in an organic way made it easier for me to speak more informally with the board at critical moments between board meetings.
The people on the board were world-class investors and operators and I learned a lot in my early days from asking questions and accepting their offers of making connections to people in their networks who could help. For example, we had a common board member with Facebook in Jim Breyer and I had a great conversation with the head of engineering there in 2009 that really challenged my thinking at the time in a good way. In a few cases, I asked board members to put in quick calls to key engineering prospects in my final push to convince those people to join Etsy (incidentally, the success rate of those calls was 100%)
It was also fun. Kellan, John, and I invited Fred Wilson to do a code deploy one day after a board meeting and Fred posted on his widely-read blog about it. When I stepped up to CEO in 2011, having strong relationships with the board from the beginning was really helpful in a million different ways.
Thanks, Chad, for being game to share this advice with the world. :)
New: The Complete Demystifying Management Video Program
I've transformed my renowned in-person workshop for managers into this self-paced virtual program. It's accessible, actionable, and will level you up each step of the way. Learn more!