Tech Lead’s Checklist #

I came across this a while ago and bookmarked it, but also wanted to create my own version that I hope to continue developing.

These are lightly logically-grouped, and then ordered roughly (emphasis on roughly!) from when a project is starting from scratch.

This list has very little focus on architecture / solutioning - I may have that go into another post later.

What problem(s) are we solving? Are those the right problem(s) to solve?
What are we building and how does it solve those problems?
Who are we building it for? What are they like? What do they need to get done?
How do we measure success? How can we know we need to pivot? (leading, lagging indicators)
What milestones do we need to hit?
What are the key domain concepts and terminologies? Are people (tech and businesspeople alike) using the same language?

Where do codebases live?
Where’s the CI/CD pipeline?
What environments are there, for what we’re building and the systems we depend on? (They could be different)
What’s along a request path from an external user? (if we’re building something externally-facing)
How can we get production-like test data? Is there an existing process for this that we can leverage or do we need to invest our own efforts to get it?
What do we need to go to production? (environments, firewall configurations, certificates, security checks, any approvals) Who do we need to coordinate with for those, and how long might it take to do that coordination?
How actively are the systems we depend on developed? How can we stabilize our contract (both social contract as well as technical / API contract) with them?
What technologies do this organization use?
What capabilities are already well-developed in this organization, and which aren’t? (e.g. not a lot of infra capabilities)

What usage pattern can we expect?
What kind of traffic?
Where do we get data? How does it look? How clean and trustworthy is it? How fresh is it, and how fresh does it need to be?
Where should the data flow after it passes through our systems?
What data are we the source of truth of?
How should we integrate with our dependencies? (Pay extra attention to dependencies external to the organization)
Are the systems you depend on able to support you adequately? If not, how can you avoid having them be your weakest point?
Who (other team) depends on us? What do we need to support them?
What monitoring tools are in place?
What other cross-functional requirements do the systems need to fulfil? (security, resilience, …)

It’s ok for the solution / architecture to evolve as you learn more. Get comfortable with that.

Work on grooming and prioritizing the backlog, up to a point where stories are on the board and somewhat fleshed out 2 or more iterations in advance. Stories on the board doesn’t mean they can’t change - as always, they’re a placeholder for further conversation.
When starting afresh, the first priority is that there are enough cards on the board for people to work on. That may mean we need to do a fair bit of technical analysis and collaborate on story writing. As the project stabilizes, look into enabling others to step into this role.

What skills do we need in the team? What level of experience?
Seek diversity - in backgrounds, skills, personality, experience level as much as possible
We don’t always need the most experienced people. Junior devs bring fresh perspective and a lot of drive. How can we make room for junior devs?

Give context on:

the mission
who’s who surrounding the organization and the external environment
the technical vision and the thought process behind it
Sharing the thought process is important - what’s important is not the vision or the decision that was made, but how we arrived there. It’s ok for the vision or the decisions to change as we get new information. By sharing the thought process behind it, the team will be more empowered to help us refine those decisions later.

Where should the code live?
Set up environments, from local (laptop), development, etc. to production - starting from the earlier ones
Set up CI/CD pipeline
Discuss and set up the patterns we’d like the team to follow going forward (e.g. folder structure, linting rules and setup, architecture decision records)

Have 1:1 with all team members to understand them better - where they are in their career, what their interests are, how they’re trying to grow. Have a conversation about how the project can help them grow (listen first).
Take note of people’s strengths and weaknesses. Try to amplify their strengths and balance their weaknesses with someone else’s strengths.

The main question to ask every day: what is the most important thing that I need to work on today for the team / project / engagement?

Delegate as much as possible, taking into account the needs of the team and individual interests and goals. But monitor and provide support if necessary.
Do people have the resources (knowledge, relationships) to spot and solve problems on their own? Are people talking to each other?
Think about systems you can set - for example, regular retrospectives, regular anything, a system for rotating responsibilities, a system for documenting architecture, that others can follow (to start with) and refine over time
Stay in touch with the code and the quality of the product the team is building
Make time for pairing - if not for whole stories, pairing / tripling a little bit here and there across multiple stories
Be available for the team and its members
Manage dependencies on other teams
Continue to build relationships with stakeholders
What may become an issue for the team in the next few weeks? How can we get ahead of them?

Set up monitoring - starting with some baseline golden signals
Incorporate business metrics (remember ‘how you measure success / how do you know if you need to pivot’)
Set up log aggregation
Set up your production environment as early as you can, even if for an internal / dark launch
Get ahead of the coordination required to get things out properly (exposed externally if needed)