Joining a new team

Whenever you arrive in a new team as a development or delivery manager, or perhaps as a lead developer, it's a good idea to dig into that team's people, culture, and work in some detail. This helps you to understand the team dynamics faster, integrate into the team, and find the one or two critical perspectives that might make a significant improvement in the team's output.

It's good to have a formal structure around the digging, rather than just being a randomizer. What follows is my structure. It's probably far from being the best approach, and isn't even particularly original. But it's been effective for me when working in line-of-business companies, and might be a good starting point for you.  

First, let's divide the analysis into 3 areas: people, process, and work. For each area, prepare a list of questions and discussion points. You're not looking for single data points, but rather for trends. If multiple people agree on a specific problem, then that's something that you should help the team to fix. You can't fix everything, but you do need to focus on a few of the biggest issues. 

Many of these questions can be answered in one-to-one meetings with each member of your team, with your peers, and with your team's primary stakeholders. Other questions are deeper and will need workshops, both within your team and with various stakeholders.


These are questions about team dynamics and relationships. As I've said before, complex projects are ability-led rather than process-led. It's the quality of your team, and the team relationships, that will ultimately dictate the succcess of your projects.

  • Is each team member aware of the team's mission?
  • Is the team structure appropriate for the team's mission?
  • Has the team maintained healthy relationships with all of its stakeholders?
  • Are there any perceived performance issues within the team?
  • Are there any perceived relationship issues within the team?


These are questions about the processes that your team uses, and how those processes can be improved. Even one or two inefficient or bad processes can have a significant adverse impact on the team's performance. 

  • Is there clear accountability for each person's work?
  • Does the team have the right degree of planning? Too little is reckless, too much is wasting resources that could be spent on delivering business value.
  • What behaviour does the team culture reward and discourage? Are the right behaviours incentivised appropriately?
  • Is there agreement on how the team measures "done" at each part of the work cycle? For example, what are all of the required steps before a design or code can be submitted for peer review? If there's no common agreement on what "done" means, then it's likely that the quality of the team's output is uneven, or in the worst case is just poor.
  • Are there any easy ways to improve the SDLC process? For example, what phase of the work cycle is taking the longest time, and can you fix that?
  • More generally, does the team have the goal of constantly improving its SDLC process? Is there usually a root-cause analysis to generate improvement ideas?
  • How is the team handling its dependencies on other teams? Can that dependency management be improved, for example by better and more timely communication?
  • Is the team working reasonable hours, or is there a culture of excessive hours and "heroics"?


These are questions about the team's current work, and what it plans to do in the future. You need to understand whether the current work is what the stakeholders want, and is organised in the right way. And you need some strategic planning to structure the content and delivery of the future work.

  • What is the team planning to deliver in the next month?
  • What is the core of the future work, the basic deliveries that your stakeholders want and expect?
  • How are you planning to extend that core work, to ensure that your stakeholders' current needs are met?
  • What more speculative work is there that might be a big help to your customers.
  • What work is necessary to reduce (or clarify) the technical and businesss risks?
  • What infrastructure work is needed? This will help the indirect delivery of business value.

At the end of this in-depth exploration process, you and the team will have clarified the team structure, the team processes, and the current and future work. You'll also have identified the most important problems that need to be addressed. The next step is to discuss, agree, and schedule the potential fixes. As each improvement is implemented, your team should start to see the benefits of better productivity and happier stakeholders.