The Complete Team Checklist 📋: A Guide for Technical Leaders

When starting in a new team, it's always exciting but overwhelming at the same time. There are so many aspects to take care of as a technical leader, whether it's an Engineering Manager position or Technical Lead position.

However, in that situation, I usually encourage fellow leaders to have a team checklist at hand. Using a team checklist helps us have a quick overview of the status of the team, and prioritize improvement points. It is very helpful for starting the journey in a new team, and set the initial direction.

The following is a list template that I use every time. You can download it and use it with your team, and read until the end of the article to see explanations and importance of each item!

Section 1: Development Workflow

1.1. There is documented coding standards and best practices

Different developers have different coding styles. In order to achieve alignment, we need a guideline that covers naming conventions, formatting rules, and policies for team projects.

Policies can include logging, validation, and anything we want alignment of. A good policy also provides great foundation in code review. Both reviewers and authors would know the background of the reviews.

1.2. There is a Process for Starting a task to Release

This means a clear path from task creation to production deployment. It should help answer the following questions:

• Anything to do before starting implementation such as tech design review
• When to submit a pull request
• How to ask for a review and how many rounds
• When to push changes to our test environment and how to verify
• How to release changes to production

1.3. There is a Branching Strategy

The industry convention is to follow Git flow or GitHub flow, but it can be anything as long as it works for the team. Just make sure that there is one and the team has the alignment.

1.4. There is a Code Review Guideline

For code reviews, it's common to use the following set of best practices:

• Pull Requests should be small and manageable
• Clear context explanations in the description
• CI should pass before the code reviews
• Provide constructive feedback and suggestions

There are more but here are just some examples.

Section 2: Testing & CI

2.1. There is Automated Unit Testing With Sufficient Coverage

For automated unit testing, we recommend 70-80% test coverage across the codebase. This helps prevent regressions and makes refactoring easier.

A good practice is to encourage members writing tests alongside new code. Having a dedicated task to write unit tests is never fun.

2.2. There are Continuous Integration (CI) tools

There are many popular continuous integration tools such as GitHub Actions and Circle CI. The aim is to set up workflows that automatically builds and tests our code with each push or pull request. It can catch issues early before any code review.

If your project allows, doing continuous deployment (CD) would be a good idea, too!

2.3. There is End-To-End Testing (for Full-Stack Teams)

For full-stack applications, end-to-end (E2E) testing helps us verify that all components work together correctly from the user's perspective. They simulate user interactions and connect all components as one process. It has a higher error rate (and can be flaky sometimes) but it helps catch issues that unit tests might miss.

Common tools include Cypress, Selenium, or Playwright. Frameworks like Ruby on Rails also provide built-in E2E tools.

2.4. There are Automated Code Review Tools

There are established common best practices in the software engineering industry. Many automated tools help with code review using those rules. For example, when there are three places where the codes are exactly the same, we should consider refactoring them into an utility function.

Tools such as SonarQube or Code Climate are good for such purpose. They are easy to set up and can help the team catch code smells, security vulnerabilities, and duplicated code. They are usually integrated into the CI pipeline.

2.5. There is a Test Environment For Cross-Team Development & Verifying Changes

A dedicated test (or staging) environment is useful for collaboration among multiple teams and verifying changes. Most companies should have it already since it's a common practice for stakeholders such as Product Managers to verify changes before releasing changes to production.

But in case your team/company does not have one, I would strongly suggest it.

2.6. There is a Manual QA Process With Stakeholders

Developers usually have a blindspot when testing their own changes. That's why we need a manual QA process.

A QA process allows QA members, stakeholders, or users to verify the changes and catch bugs. Such processes usually come after the code review and before production release.

Section 3: Monitoring

3.1. There is a Monitoring System For Availability And Performance

We recommend implementing a monitoring system to track both availability and performance metrics. Common tools include New Relics or DataDog.

Example key metrics:

• Server uptime
• Response times
• Error rates
• CPU and memory usage
• Network latency

Keep these numbers on a dashboard in an easy-to-understand format. It allows the team to quickly assess the system's health, especially during incident handling processes.

3.2. There is Reasonable SLO

Without Service Level Objectives (SLOs), it's hard to tell whether our application availability and performance are acceptable. It's better to consider the following criteria and find reasonable numbers:

1. User expectations
2. Business requirements
3. Historical performance data

For example, users usually expect a web page to open within 1 second, so it probably not a good idea to have our service response time higher than that.

3.3. There is a Alerting System

Modern monitoring tools like New Relics and DataDog also provide alerting system that work with other tools such as PagerDuty to alert the development team. There should also be a on-call rotation and incident response process, which I'll explain a bit further in the "incident handling" section below.

Section 4: Security & Compliance

4.1. There is Dependency And Vulnerability Tracking

With the evolving speed of the community, dependencies get outdated fast. Tools like Dependabot keep our dependencies up-to-date and secure. They automatically scan our codebase for outdated or vulnerable dependencies. They can also create pull requests with the latest versions to make review & merge more efficient.

4.2. There is a Practice of Security Coding

We don't have to be experts in security, but we need basic security awareness in our coding. Tools like SonarQube help identify common security issues in the codebase such as SQL injections and CORS.

They can track our improvement in overall reduction in security-related bugs and issues.

4.3. There is a Secret/PII Management Process

We've all heard people accidentally pushed plain-text secrets to public repositories. In order to avoid such issues, proper secret management needs to be in place.

Depending on the organization size, the level of security requirement might be different, but some common practices include:

• Encrypting secrets in communications
• Rotating secrets regularly
• Limiting access based on roles
• Auditing access logs

You can talk to security engineers to have a review of the team if there is one. Some organizations also provide regular security trainings. Make sure the team has someone participate and share the learnings with the team.

Section 5: Project Management

5.1. There is an Effective Task Management Tool

Project and task management is the core of a team that connects the engineering team with the business. There should a tool such as Jira or Asana to manage all these tasks so that we have an overview of all tasks including:

• Past, ongoing, and future projects/tasks
• Technical debts & bugs
• AdHoc requests
• Tasks with close deadlines

Having an overview of this gives leadership members a sense of how the team is doing, and how does their workload look like.

5.2. There is a Task Prioritization Framework

It does not have to be fancy, but leadership members need to have a basic principle of how to decide priority of a task. One common method is Eisenhower Matrix in which we use urgency and impact to decide what to do first.

Without a principle, it's easy to take the intuitive "deadline-driven" approach to decide priority. It can easily lead to ignoring non-urgent but high-impact tasks such as improving unit test coverage and other technical debts.

5.3. There is a Technical Debt And Bug List

Keeping track of technical debts and bugs is essential for maintaining a healthy codebase. There should be a dedicated list of known issues and areas for improvement. This list should include items such as:

• Legacy code that needs refactoring
• Performance bottlenecks
• Security vulnerabilities
• Outdated dependencies

5.4. The Team is able to Tackle Both Features & Technical Debts

We believe in addressing technical debt proactively. When planning new features, we allocate time to tackle related technical debt. It's common to use Pareto Principle in software engineering, and we usually use it in handling technical debts as well. The 80/20 principle we apply is:

• We spend 80% of time building features
• We spend 20% of time handling bugs & technical debts

This 20% time is mainly spent on:

1. Improve code quality
2. Reduce future maintenance costs
3. Reducing the number of system bugs

You can follow any other principle, as long as there is time allocated to tackling technical debts.

5.5. The Team has Regular Communications with Stakeholders

Regular check-ins with stakeholders on projects and the team's status ensures that updates are synchronized between teams. These meetings/communications typically cover:

• Project progress and milestones
• Potential risks or roadblocks

It has occurred several times that project delays were communicated with stakeholders at the last minute, and they created confusions and frustrations. Having regular updates keep both parties up-to-date.

5.6. The Team Collects Regular Feedback from Stakeholders

Most stakeholders do not actively share feedbacks to the team, but they usually have valuable opinions that can help the team improve.

Make sure that there is a way to collect feedback from stakeholders such as Product Managers, customer support operators, and system users. It can be quarterly surveys or casual meetings.

After that, make sure to act on the feedback, demonstrating commitment to continuous improvement.

5.7. The Team has Regular Retrospectives

Sprint retrospectives serve to provide a space for members to identify improvement points at the end of each sprint. Even if the team does not use agile methodology, I would still recommend the team to have retrospective meetings regularly.

During these sessions, we:

1. Celebrate successes
2. Identify pain points
   1. Brainstorm solutions
   2. Create action items

Make sure the action items are assigned and executed. The team will see improvements overtime.

Section 6: Incident Management

6.1. The Team has an Incident Handling Procedure

Incidents happen sometimes, so it's better to be prepared. The procedure should include the following:

• A on-call rotation schedule
• An escalation policy
• Severity categorization guideline
• Solution guideline
  • Short-term mitigation
  • Long-term fix
  • Prevention measure
• How to work with post-mortem (see below)

6.2. There is a Postmortem Analysis for Incidents

There should be a postmortem analysis for each incident, and it should be in the standard procedure. This helps us learn from experiences and prevent similar issues in the future.

Key elements of an effective postmortem include:

• Timeline
• Root cause analysis
• Impact assessment
• Actions taken to resolve the issue
• Lessons learned

The highlight here is that the process should be blameless. Focus on systemic issues rather than individual mistakes. This approach promotes open communication and continuous improvement.

6.3. The Team is able to Track Past Incidents

It’s easy to forget what happened in the past . However, it's important to learn from future mistakes. If there is no list of past incidents, start creating one.

Looking at past incidents tells us a lot about the team's issues. For example, the team might not have sufficient unit test coverage to find out changes impacting seemingly irrelevant areas. Briefly viewing all past incidents can help new leaders find existing issues.

Section 7: Team Management

Team management is not specific to only Engineering Managers. For any senior developer in the team, it's also important to be part of this team overview.

7.1. The Team has Key Metrics For Tracking Team Performance

The company might have a division-level key metrics such as DORA, but if there's not, it's good to define metrics to help track the team performance. There are a lot of examples to choose from, so choose those relevant to the team.

However, be careful about using metrics. Using too many metrics can lead to micro-management, and using wrong metrics can drive the team into wrong directions. Metrics create incentives, and it forms team culture.

For me, the most important questions to answer are:

• Does the team deliver in time
• Are the members happy

Key metrics should help answer these questions. As long as we get positive answers, we'll leave the rest to the team to find what works best for them.

7.2. There is a High-Level System Diagram

We use a system diagram to map out key stakeholders and their relationships to our team. An ideal diagram should include:

• Internal teams/systems we collaborate with
• External vendors/systems
• Important system components

This visual aid helps new team members understand our operating environment. It also helps with identifying potential bottlenecks or communication gaps.

7.3. The Team has an Onboarding Procedure

A smooth onboarding process allows team members to get started quickly. We've developed a comprehensive procedure to welcome new team members and bring them up to speed quickly.

Here's an example of our onboarding process:

• Week 1: Meet the team, join onboarding trainings, and set up the development environment.
• Week 2: Meet stakeholders, start with a small development task, and learn the development workflow.
• Month 3-4: Initial feedback, and continue working on development tasks.

We also provide a list of resources, including documentation, coding standards, and development workflow. Having regular check-ins ensures new members feel supported and can express concerns.

Section 8: People Management (for EMs)

8.1. Members Know the Team's Goals

Members need to know what the team is working on, and what it is trying to achieve in 3 months (short-term) or one year (mid-term). A great example is to have a team roadmap. Ideally, it should include:

• What product features the team is building?
• What technical issues the team is resolving?
• What are some big projects the team will be working on?

Without a roadmap, engineers are mostly working on the assigned tasks, without knowing where they are moving toward. It's challenging to keep long-term motivation and build a connection with the team.

8.2. Members Know Their Expectations and Improvement Areas

Managers and members should be aligned with their expectations, and it should be communicated early. For example, some senior engineers might not want to lead the team, but it's part of the expectations to be "senior". This should be communicated in the first place, instead of the timing of performance review.

There might be a company-wide or team-wide engineer levels defined. If there is not, it's usually good to start with a simple framework like Engineering Ladders. Using a framework like this can help us define expectations and spot improvement areas easily.

We mainly use 1-on-1 meetings to communicate such topics.

8.3. Identify Outstanding Conflicts & Tensions

Conflicts are inevitable in any team, and some people just do not see eye to eye. Managers should spot these issues early during onboarding. Talking to the previous manager, our manager, or senior team members will help us be aware early.

Resolving conflicts is another topic, but being aware of these issues should be part of the onboarding.

8.4. Adequate Team Member Count

Ensuring our team has the right number of members is good for maintaining work-life balance. It also reduce risks. For example, in a team of three members, if someone is taking a long leave of three months, productivity suddenly drops by 33%. The risk is always high with a small team.

Starting from the mass layoff in 2022, it's going to be challenging to keep a sufficient number of member count, but it should still be on every manager's list. When the team does not have sufficient members, some action items include:

• Actively push for hiring
• Stay connected with close teams to get support when necessary
• Consider getting short-term or long-term contractors

Also, some tips for reducing team workload:

• Tasks pushback
• Postpone task schedule
• Prioritize tasks with the highest urgency and impact

8.5. Balanced Team Structure Of Experience Levels

A balanced team structure with a mix of experience levels is healthy for productivity and career growth. This approach fosters mentorship, knowledge sharing, and continuous learning. Our ideal team composition includes:

• 25% Junior Developers
• 50% Mid-level Developers
• 25% Senior Developers

This structure allows for effective teamwork and supports the growth of less experienced team members.

Frequently Asked Questions

Who should use this team checklist?

• New Engineering Managers or Technical Leads who recently join a team
• Existing team members transitioning into leadership roles
• Senior engineers looking to assess their team's health
• Leaders wanting to improve their team's processes and practices

How long does it typically take to implement all these practices?

Implementation time varies based on the current state. If there are a lot of items to work on, try:

• Start with the most urgent & impactful items. For example, if there's no system diagram and no one knows the full list of dependencies, it's a red flag and it should be prioritized.
• Put these items on the team roadmap and aim for 2-3 improvements per quarter.

What if my team is too small to implement all these practices?

Every team has different requirements. For example, if you have only one or two members in the team, it probably does not make sense to have an overkill on-call rotation and escalation policy. Suggestions:

• Focus on essential practices first (development workflow, testing, monitoring)
• Consider lightweight versions of these processes. For example: Jira might be an overkill for a small team in terms of task management. Notion or Trello would be good enough.

What if we face resistance from team members?

It's a big topic to push for changes, but some practical tips:

• Start with small changes such as a system diagram or onboarding process.
• Involve team members in the decision-making process.
• Gather and act on feedback regularly. Not all items suit all teams.
• Share success stories from other teams (if any).

How do I measure the success of implementing these practices?

Use key metrics to measure the results. Once improved, the team should be able to shorten development time, have a lower incident rate, and better stakeholder satisfaction. These will be reflected in key metrics.

They might be able to reflect on the metrics immediately, but they will one day.

Feel free to download the checklist template for your own use. Also, leave me a message if you have any questions!