How to Manage a Software Development Team

You’re a new software development team lead (or tech lead, or engineering manager). You’ve been put in charge of a new team of engineers and other technical people. Now you want to know how to manage a software development team.

This article will give you the basics to manage that team successfully.

As the manager of a software development team, you have three main tasks:

  • Managing people
  • Organising team processes
  • Setting goals

Let’s start with the people you’ll be managing.

What is a software development team?

A software development team is a cross-functional, self-sufficient team of technical people who design, build, and maintain software that solves customer problems.

Small companies may have only a handful of software development teams while larger tech companies such as Amazon and Google have thousands of these teams.

Getting the right people

A software development team should contain all the people it needs to get work done on daily. This means the following:

  • A software development team lead to manage the team and its members.
  • Software engineers – generally two to eight – to build and maintain technical solutions to customer problems.
  • A product manager to uncover customers’ needs that align with business needs.
  • A product designer to design usable solutions for customers.

Some teams also include these roles:

  • QA engineers
  • Data scientists

Managing people with one-on-ones

As the manager of a software development team, you will often be the people manager for most of the engineers in that team. Regular one-on-ones are your primary tool for managing people in a software development team.

When you join a new team, set regular one-on-ones with each of your direct reports.

A one-on-one is a regular meeting between yourself and your direct report for the purpose of their development. One-on-ones should be held at least sixty minutes each fortnight and should not be cancelled unless a cancellation is unavoidable.

There are three primary purposes for the one-on-one.

Providing a space for growth

The first is to provide a space for your direct report’s growth. Your direct report should propose most of the the topics discussed in a one-on-one. One-on-ones may include project updates; however, that should not be the primary focus of most discussions.

Sharing information

The second is to share information. There are two main types of information: cascading communication and feedback.

Cascading communication is information you have received from your manager or other parts of the organisation. For example, you may share a change in the company strategy or provide information on an interesting technical challenge another team faces.

Feedback is information on your direct report’s performance. The purpose of feedback is to align expectations and to help their development. Feedback should have the following qualities:

  • Objective; presented with data not assumptions.
  • Shared close in the time to the situation you are discussing.
  • Provides an opportunity for your direct report to share their perspective.

Developing a relationship

The third is to develop your relationship with your direct report. This means showing empathy for their situation, being curious about their life outside of work, and sharing information about yourself. By doing this you build trust.

Here are example questions you can ask your direct reports:

  • What successes have you had since we last met?
  • What’s the biggest challenge you are facing?
  • What do you need to grow in your career?
  • How do you feel about your work?
  • What can I help with?

Organising team processes

As the manager of a software development team, you are responsible for defining the processes the team uses to maintain a regular cadence of delivering work. Most modern software development teams adhere to an agile way-of-working.

Scrum and Kanban are the two most popular frameworks on which software development team base their processes.

When you join a new team, define the processes for defining and delivering work.

Scrum

Scrum is an agile framework that helps teams structure their work and deliver value incrementally and regularly. Teams who use scrum work in time-bound sprints that run from one-to-four weeks, with two week sprints being the most common. Scrum is defined by four types of meetings: sprint planning, daily stand-up, sprint review, and the sprint retrospective.

Sprint planning is held at the start of each sprint. Team members collaboratively decide what tasks from the team’s backlog will be worked on during the upcoming sprint.

Daily stand-up is held at the start of each day. The team meets briefly – typically no more than 15 minutes – to share progress and surface blockers.

Sprint review is held at the end of each sprint. Team members share the work completed during the sprint with the rest of the team and stakeholders outside the team.

Sprint retrospective is held at the end of each sprint, generally after sprint review. The team reviews what was successful during the sprint and what could be improved next time.

Kanban

Kanban is a lightweight agile framework that helps teams visualise their work and improve their flow of work by reducing work in progress. Teams who use kanban represent their work using cards in project management software – such as Jira or Trello – or physical cards on a whiteboard in the office.

Instead of working in fixed-length sprints with predefined tasks, kanban teams bring in new work continually once their current work is finished. Like scrum, teams who use kanban run daily stand-up meetings. They also run sprint review and retrospective meetings; however, since there is no clearly defined sprint, kanban teams must schedule these separately.

Not sure which framework to choose? Look at what other teams in your company are doing. If you’re first, start with the lightweight kanban framework. This will help you manage your software development team.

Setting goals

Your responsibility as the manager of a software development team is to set goals for your team. You should have goals at each of the following levels:

  • Per sprint, if using scrum
  • Quarterly
  • Annually

Each goal should ladder up to the level above. That is, achieving your sprint goals helps you achieve your quarterly goals, which helps you achieve your annual goals.

These goals should also be aligned with other parts of the organisation. For example, multiple software development teams may work on the same product to increase customer retention. While each team will have different goals, the result of each team achieving their goals should contribute to the broader organisational goal of increasing customer retention.

Common frameworks for goal-setting include SMART goals and OKRs.

SMART goals

SMART goals have the following qualities:

  • Specific: What needs to be accomplished? Who will do it? How?
  • Measurable: How will you know when you have accomplished it?
  • Achieveable: Can this be accomplished with the resources you have?
  • Relevant: How does this relate to your long-term objectives?
  • Time-bound: When will it be completed by?

These types of goals are effective for near-term and concrete objectives. SMART goals are less effective for aspirational and longer-term goals.

OKRs: Objectives and Key Results

The OKR framework is used by many leading tech companies – such as Apple and Google – to set inspirational goals at all levels of the organisation. OKRs are best used for quarterly and annual goals rather than short-term goals. They have the following two components:

  • Objectives: Memorable, qualitative descriptions of your goal.
  • Key results: Metrics that measure progress towards the goal.

Objectives should engage and motivate your team. This is the outcome you want to achieve. Key results should be measurable and verifiable. These are how you measure success of the outcome.

Keep these principles in mind when setting goals:

  • Ask for your teams’ input. Don’t set goals without consultation.
  • Connect short-term goals to long-term goals.
  • Make trade-offs. Decide what you won’t do.
  • Connect team goals to company strategy.
  • Make goals engaging and inspiring.

What next?

You’ve got the right people, scheduled one-on-ones, defined team processes, and set short-term and long-term goals. Do you now know how to manage a software team development? Yes and no.

You now have a starting set of tools to effectively manage a team. And there’s even more to learn:

  • Delegation
  • Leadership
  • Team building
  • Communication
  • Effective influence

Want to grow your confidence and competence as a manager? Join my newsletter to learn how to become a more effective leader in tech.