My Playbook
Welcome.
After running dev teams for over 2 decades, I've learned a lot about what to do and what NOT to do when building and running software engineering teams. This playbook captures my distilled learnings in a template for you to follow.
These are the patterns, principles, and practices I'd use if I were running another dev team from scratch. If you're in the same situation, I hope you find it useful.
Assumptions
For the purposes of this playbook, I am making a few assumptions which may have an impact on applicability for you at your company.
We are building a web-based product.
It might be a web app or an API. This assumption allows me to be more opinionated about release/deployment practices.
We are building software for other businesses to use.
As a B2B company, this assumption allows me to be more opinionated about roadmapping and backlog management practices.
We are building in a low-regulation industry.
Certain safety-critical industries (like healthcare, transportation, aerospace, banking) have strict, mandated processes. I will assume that we are operating in an industry without these constraints.
We are an all-remote company.
While some colleagues will invariably be co-located in the same city, I am going to assume that we are building a distributed workforce, one in which each individual is empowered to work and live wherever they are the most fulfilled.
We are operating on calendar quarters.
Some businesses, as they mature, shift their fiscal quarters (when they do financial reporting) to offset from calendar quarters. To simplify the mention of “quarters” in these playbooks, I will assume that there is no difference. Q1 is January 1 through the end of March. Q2 is April 1 through the end of June. Q3 is July 1 through the end of September. Q4 is October 1 through the end of December.
Phases of the Engineering Org
I've seen software development organizations go through 4 notable phases.
The Establishing Phase
These are the early days after the founders have created the company. The engineering team is small (less than 10) and operates as a serialized, tightly-knit team. A couple of us are co-founders. We have the seed of an idea, and we’re working together to rapidly build out product experiments, hoping to find product-market fit (PMF). There’s lots of greenfield development. We’re playing with some newer tech stacks, and everything feels shiny and new. There’s excitement and everyone is motivated by the idea of being on the ground floor of creating something valuable and cool.
Notable Challenges:
- discovering and building a product with enough traction to generate revenue or justify further investment
The Growing Phase
Bolstered by finding some product traction, we experience pressure (market pressure and internal pressure) to deliver more product more quickly. We hire and onboard fresh talent from across the globe to expand the team, structuring ourselves to take on efforts in parallel. We build our first meaningful product roadmap, and work to deliver against the commitments we’ve made. We continue to innovate, but — with real, paying customers — we also need to maintain our software by delivering bug fixes.
Notable Challenges:
- attracting, retaining, and growing talent
- delivering software effectively with a team split across timezones
- managing and delivering on roadmap expectations
- balancing features and fixes
The Maturing Phase
What was once a product is now a product suite; product breadth and depth have grown to support many worldwide customers. The codebase has bloated, with some early features still in the code but no longer in use by customers. We see some customers churn from product issues and occasional downtime. Some of the early engineers leave the company, and we continue to hire new talent. Product delivery expectations remain high despite this shifting team dynamic.
Notable Challenges:
- loss of early influential team members (and the knowledge in their heads)
- keeping morale and momentum high
- broad product obligations (features and fixes) seem overwhelming; the team cannot focus on every part of the product all of the time
The Aging Phase
With a sprawling product suite and a team of hundreds under my purview, the engineering org endures some mergers and acquisitions (M+A), then prepares for an exit of its own. While continuing to ship product, we perform and prepare for due diligence, manage culture clash, and deal with inevitable budget cuts.
Notable Challenges:
- communicating during turbulent times
- evaluating M+A opportunities
- managing culture clash when two companies come together
- keeping morale and confidence high
