Assessing your engineering team: questions for managers

As an instructor and content developer for engineering management training, and as a director who hires and manages engineering managers, I’m constantly thinking about how to help engineering managers be more effective.

Whether you’re new to management, or have managed teams for years, it’s likely that at some point you’ll need to assess a team. Perhaps you got a job at a new company as a manager and need to onboard; perhaps you inherited a team; or perhaps you’re just ready to make lasting improvements. Starting with an assessment helps you get oriented and figure out what areas to tackle first. Just don’t forget not to break the things that are working.

Consider writing down what you discover, sharing it with the team as appropriate, and getting their input to confirm (or correct) your observations. You’ll benefit by being transparent and getting the team’s buy-in. Do they agree with your impression of the stakeholder relationship? Do they agree with your calculation that the team is running at 50% RTB? How do they rank the importance of areas to improve?

I’ve broken the questions into five categories, or five focus areas for team improvement and development: People and Team Development, Technical Knowledge/Quality, Partnering, Scope/Impact, and Project Execution.

This isn’t an exhaustive list, and other ideas are welcome. You can submit a pull request here:

People and Team Development

  • Are team members at the right level in role?
  • How long have people been in their roles?
  • Is anyone due for a promotion?
  • Is there danger of attrition?
  • When is the last time each person received formal written feedback?
  • What’s the team culture in meetings and chat channels? Are people friendly, helpful? Sarcastic and annoyed?
  • How diverse is the team?
  • Is the team inclusive?
  • Is the format of current team meetings effective?
  • What’s the work life balance of team members?
  • Are there signs of burn out?
  • How is the oncall burden? Are systems alerting appropriately?
  • Is the team the right size (number of people)?
  • Is the team the right shape (levels of experience, skill sets)?
  • Are there any open requistions that need to be filled?
  • Are there documented fair hiring processes? Does your team have interview rubrics?
  • What is the engineer:manager ratio?
  • What is the format and cadence of 1:1s? Are they effective?

Technical Knowledge

  • What services or systems does the team own?
  • What is the state of the code base?
  • Is there thorough, current documentation?
  • Are there thorough, current runbooks?
  • Is the code in source and deployable?
  • What is the deployment cadence (daily, weekly, monthly, etc.)?
  • Does the team’s work adhere to company tech stack standards?
  • Are there unit tests, integration tests?
  • Is the team up to par on data privacy and security requirements?
  • Are there technical design documents (TDDs) for past projects as well as those in progress and not started?
  • How much tech debt is there?


  • Who are the team’s customers, partners, and stakeholders?
  • Check in with all stakeholders: what is going well? What could be going better?
  • Check in with partner teams: what is going well? what could be going better?
  • Are there standing stakeholder input or review meetings?
  • What are the relationships with partner/dependency teams like from the team member perspective?
  • Are there working agreements with stakeholders or partners? Should there be?
  • Downstream dependencies: Which teams are dependent on this team? Which teams tend to get blocked by this team? How long does it tend to take to unblock?
  • Upstream dependencies: Which teams are dependencies of this team? Which teams tend to block this team? How long does it tend to take to get unblocked?
  • Do interdependent teams perform project and roadmap planning together, or in silos? Are there ways to collaborate more?
  • What are the communication channels between teams for sharing wins and misses and finding out what other teams are doing (meetings, roadmap planning exercises, documents, chat, email announcements, etc.)?
  • How does upper management know what your team is working on (communication channels and cadence)?
  • How does the team hear updates to the vision from upper management (communication channels and cadence)?

Scope / Impact

  • What is the impact of the work the team is doing? Is it local, cross functional, org-wide, company wide?
  • What is the impact of the projects each engineer is working on?
  • Are engineers challenged?
  • Are there any single points of failure (SPOFs) on the team, where a single person holds the only working knowledge about a project, service, or system?
  • Is the work aligned with company goals?
  • What are the short term projects?
  • What are the long term projects?
  • What is the 2-3 year team vision?
  • What are the north star metrics that can be used to develop your KPIs (key performance indicators)?
  • Does the team have a defined charter?
  • Do the services, systems, and projects owned by the team align with the stated charter?

Project Execution

  • What are the processes the team is using? Agile, scrum, kanban? Are they effective?
  • Does the team have sprint planning? How often? Is the cadence effective?
  • How is the backlog? How old are tickets in the backlog?
  • What is the portfolio of the team (percentage of running the business work, vs. feature work, vs. tools and improvements, etc.)?
  • How much running the business (RTB) work does the team do? Can you burn this down to free time for more project work?
  • How much unplanned/ad hoc work comes into the team? How will you plan for future unexpected work?
  • Are there defined KPIs or OKRs (Objectives and Key Results)? Are they measurable?
  • Does the team tend to complete OKRs each quarter, or carry them over?

As always, I hope these questions lead you to actions that help develop the potential of the team, all of its members, and you as an effective manager.

Photo by Fallon Michael on Unsplash

Comments are closed.

Blog at

Up ↑

%d bloggers like this: