I told myself at the 6 month mark of fun employment I’d publish my notes about what I’d been up to. I missed that. Did some yak shaving. Having a couple of different blog redesigns in various stages, and another long post about my (awesome) experience at Recurse and building a database.

But it was my birthday this weekend, so I published some quick half formed thoughts on what I’ve been researching about, mostly around climate change lately.

The other thing I’ve been doing is teaching engineering leadership (though I lost my partner in crime from my last sabbatical to gainful employment). I’m on record believing that we radically under invest in training technical leaders, a problem that is compounded by the fact that CTO and the various related technical leader roles are among those that change most dramatically as a company scales.

So in the spirit of half formed thoughts, a few conversations that come up frequently talking to engineering leaders and founders.

Frequent Asked Questions (and Frequently Encountered Assertions)

1. CTO vs VPE?

“We have a CTO who is great engineer, but we need a VPE because our CTO hasn’t lead large teams before” “We need a CTO because we need someone to manage the engineering team, and a CTO can’t report to a VPE” and a million variations on that theme.

Nothing you’ve been told about the roles of what a CTO or a VPE does is set in stone. The most common understanding, namely that the CTO leads technical decisions and the VPE leads the management organization (some times described as dealing with the humans) is fundamentally broken and dysfunctional. Shipping software requires unified responsibility for people and technical management, which is one of the reasons that technical leadership is a hard and distinct discipline.

You’re either creating an organization where technical leadership, and technical decision making is happening explicitly, and people are held accountable for it, or it’s happening in the shadows and accountability is hard to impossible.

2. The team isn’t working hard enough

The team isn’t working hard enough is never the problem. It is sometimes the symptom. In particular, it is usually a symptom of a lack of clear goals, cascading down to a lack of ownership.

Usually it goes something like this:

a. Goals are unclear (or someone is unable to admit their hypothesis was wrong)

b. Lack of demonstrable progress leads towards increase precision in instructions. Strategic becomes tactical, tactical becomes micro-management, micro-management becomes a “butts in seats” policy.

c. Often we see collapsing scope exacerbated by “best Agile practices” which attempts to reduce software practice to an industrial process of pulling tickets off a backlog conveyor belt.

d. trust breaks down in your cross functional organization, communications becomes harder, clarity around shared values and goals weakens further. Your halls echo with cries like “we can’t, too much technical debt” and “the engineers are just goofing off”.

e. Rinse and repeat.

3. Okay, but how do we make sure that everyone is working on the right thing?

Clear goals. Focus. 30 minute sprint planning meetings. Everyone talks. Understanding of the hypotheses, and the why behind the hypotheses feeds into shared commitment and accountability. No one comes to work to do the wrong thing.

4. How do we hire a team?

You start. You aren’t spending enough time on it. In 100% of the engineering teams I talk to they aren’t spending enough time on building a team.

You’re also over emphasizing the interview (and you probably still suck at it). Interviewing is ~10% of the success of hiring. It’s also extremely low information. Optimize your interviews for great candidate experience. You’ll increase the chances that you’ll find someone who might succeed in your organization and increase the chances that the 95% of people you interview who don’t end up joining your team are positive brand ambassadors for you.

5. Should we do squads? Swim lanes? Pods? Working groups? Two pizza teams? Etc

Yes you should.

You should have small (less than 10) teams of people, with cross functional leadership, who have shared responsibility for a goal and for devising how that goal will be achieved. Communication and coordination will swamp all the other costs of modern software development if you let it. Is customer support important to your business? They should be represented in your squads. Marketing? Ditto. Specialists? Same.

6. How do you build culture?

What you celebrate is what your culture will be.

7. Basically everything else ever

Ship smaller changes faster, do a better job of measuring, correctly communicate your confidence level.

Modern software development is an operational challenge of creating an environment for shared vision, decent technical decisions, and constant measurable progress.