Practical Checklist for Tech Leads: Proven Ways to Keep your Development Team Motivated

While there are many different approaches to project management, the following best practices have worked for me, my teams, and clients over the last 15 years in IT. I’m glad to share them with you.

As a tech lead, you probably know a bunch of project management techniques. You might already be using some of them in your projects, but having a checklist could be useful. I won’t go over SCRUM or Kanban since you likely know them well. Instead, I’ll share some important project management techniques that can help keep your development team motivated and focused.

It is important to note every project (and team) is different and something that works in one will not necessarily work for others. That is why I call them best practices and not the process. Usually, we pick up what works for a given assignment and build on top of that.

Design a detailed roadmap to ensure project success

The starting point is to make the whole team aware of the goals & plans for the nearest future but also long-term direction.

• Prepare and share a RoadMap, so that every team member is aware of what is expected to happen and when.
• The roadmap should contain detailed information for the next quarter in advance. Any tasks & dates further in the future can have lower priority, but still should be sketched.

Using JIRA for a successful project workflow

As a project lead, one of your most important responsibilities is to ensure that everyone on the team is on the same page about the work process. We use JIRA for that, with almost (but adjustable) the same flow in every project.

No matter which way you choose to manage the project, it’s essential to make sure that everyone knows what’s going on and follows the plan. We usually pick either SCRUM or Kanban.

Example flow statuses can look like:

Every team member must know this flow and be aware of which status they are responsible for.

Automate the processes to save time on your project

All repeatable tasks should be automated as soon as possible. It may slow down the start of a project but quickly pays off (especially while having a bigger team). Automatize every field.

• Infrastructure
• Builds, releases, and deployments (Continuous Integration & Deployment)
  e.g. After Pull Request your CI/CD tool triggers the job that verifies its completeness, triggers automated tests, checks static code validations. If all goes OK then the change is marked as ready for Code Review, Tests.
• Backups/restores
• Clean-up tasks
• Creating new DBs, users, sample data, etc.

To save time, you should automate on dedicated/remote servers. If you have automatic building processes, but only on your local machine, you’re wasting time. How come? The complex project builds can take 20-30 minutes and can take up most of your CPU. During this time, a developer is not able to work efficiently, so it is wasted time.

Proper environment definition and management will help with your project

Define environments, their purpose, and the flow between them. It is important to set up different environments for different stages of the software development process. Usually, this is enough:

• DEV
• TEST
• PRE-PROD
• PROD

This will help ensure that the software solution will work correctly when it is launched. It is also important to keep all the environments as similar as possible to the production environment. This minimizes any potential problems encountered when going live.

Keep all environments stable and ready for use all the time.

Architecture first approach

Select architecture for a project and not vice-versa. Find architectural drivers for a given project and then select proper tools & frameworks. Don’t go into buzzword-driven development. There is no one architecture that fits all projects.

• Split the project into reasonable-sized and independent modules (not too little, not too much).  You’ll gain from it at every stage.(e.g. local compilation of a single module will take less time).
• Mistakes in architecture will slow down work throughout the whole project and will cause many issues and problems. With bad architecture, even small things can be painful to change.
• Think about building & running possibilities.  If building & running the project for tests takes 5 minutes, then every developer is wasting at least 1h every day waiting for builds.
• Think about user experience. First impressions should be everything, a user should not be waiting on a loading screen. Think about performance but premature optimization is the root of all evil.

Why defining coding standards is important to project management

• Define coding standards & formatters for cleaner, more consistent and more readable code. Define it to be easily accessible for the whole team (e.g. Confluence/Wiki/project’s repository)
• I recommend having examples of usage e.g. links to well-written modules.
• If your legacy code doesn’t fit defined standards – fix it during the first occasion (e.g. during changes in that module).
• All new functionalities should be in line with defined standards – to be checked on Code Reviews.
• It will shorten the process of adding new team members and getting them up to speed.  Also, maintenance and extending the scope of work will be easier.

Review the code

Done by all and for all – this is a great opportunity to learn and keep standards.

• A Junior reviewer can learn from the feedback of a senior colleague’s comment.
• A Junior reviewer can learn by studying a senior colleague’s code.

Make sure you test the software

Unit tests are mandatory for long-running projects.  Without them, any future changes will take much more and maybe error-prone. Developers need this information to be sure that it hasn’t impacted other aspects of the project. Unit tests are also very good documentation, explaining what was expected to be achieved in a given logic.

• Automated integration/E2E tests – at least for main flows (flows that generate business).
• Manual tests for places where automatization is impossible or economically not justified.
• All tests should be consistent and written in defined standards.

The importance of auditing and transitioning to the new architecture

Also, once we take over existing projects, we have to do some additional work at the beginning:

• Audit of existing project state and architecture.
• Defining the best architecture for given project and timeline when we want to be there.
• Introduce minimal mandatory architectonical changes when transitioning to the new architecture. Usually, this connects every part of the project, so the development of new features is frozen for some time to introduce them. Therefore try to split it into minimal steps.
• Introduce new changes along the normal development process:
  • Update to new architecture while adding changes in given modules
  • Split the team: part of it is migrating the system to the new architecture, second part is working on new features & fixes to keep business going

As a result, we are migrating to desired architecture in a longer process but without freezing the project.

The importance of project management in team motivation

From my experience keeping the development team motivated is an essential factor for the success of any project. Through years of experience and practice, I have found that implementing these project management techniques consistently leads to a high level of commitment and productivity from the development team. I hope you can find them useful also for your projects. However, you must remember: every project and team is unique and what works for one may not work for another. You have to identify what works for you and keep it. Adjust and improve what doesn’t. Be flexible. Be agile.