For the purposes of these playbooks, 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.
Engineering Leadership
your job in a nutshell
Build the Machine that builds the product.
As an engineering leader, you need to shift from building the product to building the Machine that builds the product. This Machine is composed of 3 interlocking parts:
- PRODUCT -- your technology and patterns
- PEOPLE -- your team
- PROCESS -- your ceremonies, actions, and procedures
You've got responsibilities across all 3 of these domains.
Product Responsibilities
your 4 responsibilities with respect to technology
Deliver software.
This responsibility is all about deciding what to build, building it, testing it, and shipping it to users. If you don’t: You’re fired. This is your primary responsibility, the core reason you have your job as an Engineering leader.
Balance features and fixes.
You’ll come under pressure to constantly innovate and deliver new features and capabilities, but maintaining product quality and limiting technical debt requires time and effort too; YOU will need to be the one that holds the line, advocating for focus on both features and fixes. If you don’t: Users will regard your software as buggy and unreliable, even if it is full of features. Engineering morale will drop from the perception that leadership is not interested in producing quality software they’re proud of; a low-morale team is unproductive and rarely sticks around.
Inspire engineers to build the product.
This responsibility is all about picking technologies and patterns, and taking on challenging technical problems. Working with interesting tech to compose elegant solutions is exciting for developers. If you don’t: Failure to expose engineers to challenging work and interesting technologies will result in limited growth, boredom, and early departure.
Inspire users to champion the product.
You’re responsible for advocating that your software delights users with its design, speed, utility, and quality. Software that delights feels like magic and excites those who use it. If you don’t: You’ll produce okay software. Users will consider it fine but unremarkable, and will be uninterested in proactively recommending it to others.
People Responsibilities
your 3 responsibilities with respect to your team
Attract, retain, and grow talent.
This responsibility is 3-in-1, and it’s all about building your team, keeping them around for as long as you can (or want), and making them better while they’re in your care. If you don’t: Failing to attract talent results in insufficient team horsepower to deliver the product you want on the timeline you want. Failing to retain talent results in wasted time offboarding team members and onboarding and ramping neurew talent constantly. Failing to grow talent results in stagnant colleagues and an inability to scale your business; stagnant team members get bored and quit.
Structure and organize the team.
With whatever team you have, you’ll need to give it some order to make it effective in delivering software. You can do this by giving the team structure and by getting it organized. Structure is the team’s makeup – its composition and shape, and it defines where authority, responsibility, and accountability reside. Organization is about facilitating and optimizing the team’s communication so they can do their work effectively. If you don’t: Failing to bring order to the team results in inefficient (slow, incomplete, or failed) delivery.
Motivate and inspire the team.
There are LOTS of actions required to deliver a piece of software, and every action your team takes requires some level of motivation to make it happen. A spark of Inspiration makes motivation easier. As an Engineering Leader, it’s your responsibility to provide both. If you don’t: The people on your team MAY still deliver, but it will feel like a grind. Colleagues that feel like work is a chore will leave for more satisfying opportunities.
Process Responsibilities
your 4 responsibilities with respect to getting things done
Deliver on time.
When you set a target date for delivery, you’re responsible for hitting it. This might be for a software project, for landing a new hire, or for getting a new initiative going. If you don’t: Trust in you and your team will decline, as other parts of the organization depend on you. Your reputation will suffer.
Deliver on budget.
You’re responsible for operating your team and building software as effectively as possible within the financial constraints the business has imposed. You need to know your budget and stick to it. If you don’t: Failing to stay within your budget means that the organization will inevitably come under financial stress (somewhere).
Deliver with quality.
You’re responsible for producing good results; for people, these are quality colleagues. For product, quality software. If you don’t: Failure to build a quality team will result in an inability to execute. Failure to produce quality software will – again – result in a loss of trust from the other parts of the organization that depend on you AND will disenfranchise the people who use your software.
Keep all stakeholders well-informed.
You need to devise ways to keep colleagues aligned. If you don’t: Failure to keep teammates well-informed breeds misalignment, creating disappointment and distrust when expectations go unmet.
