I’m 6 months into my second extended sabbatical from operating. It’s my birthday today and I’m taking some time to reflect on what I’ve been up to this year. And one of my favorite things I’ve been doing is coaching engineering organizations on how to be high impact. Relecting on that half year of chatting with CEOs, CTOs and VPEs there have been a few FAQs.

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.