Team Pulse Check


One of the software engineering manager’s responsibilities is to understand the team’s dynamics and to know if your direct reports are happy in their jobs. While it sounds easy getting full insights from 1:1s, team meetings, or from your direct collaboration with the team is not always that straightforward. It may happen that your team members wait with raising their concerns or frustrations (i.e. hoping they can resolve them on their own) until it’s way more difficult to get the root cause of the problem resolved. In addition, it’s good to be pro-active and address any problems your team may encounter as soon as they arise rather than being reactive and wait for the team asking for your help (be careful, though, not to become a micro-manager who steps in too early and/or against team’s will).


A few months ago, I introduced so-called Team Pulse Check to my teams that is meant to address the above. The idea is that every month I ask every team member to answer 3 simple questions:

  • Are you happy in your team?
  • Are you satisfied with the type of work your team is doing?
  • Are you happy with the way your team works?

each assessed on a scale from 1 to 10.

I picked these questions because to make it work the survey needs to be very simple and answering it shouldn’t take more than 30 seconds (of course, you still must get your team’s buy-in for the whole idea!). Otherwise you risk it either lands in the “deleted” folder or you get random answers in case the team doesn’t want to make you unhappy by simply ignoring the survey whatsoever). These questions allow also for a high-level understanding where a potential problem is (is it a process, is it a scope, or is it something more personal within the team?). Of course, number and type of questions depend on your situation, environment your teams operate in, etc., but I hope you get the idea.


I run this survey anonymously which means that each team gets only averaged results (for each question) but doesn’t know how exactly each person voted. The reason behind it is that in this case people are less afraid of telling the truth, especially if there are only single people in the team that deviate from the overall team’s opinion. Nevertheless, while teams see only their averaged results, I see all the details therefore I can react accordingly (more on that later). There is nothing wrong with making it fully transparent and sharing all details with the whole team, but – again – it depends on the context, your organization, etc. The main point, however, is to be transparent with the team when presenting the idea of Team Pulse Check so that they understand who sees what before a first survey is sent.


Assuming you managed to convince the team to give it a try and you successfully sent the first survey, the question is what to do with the results you got (apart from sharing them with the team). Here are some hints:

  • Don’t be bothered with the values themselves. Never compare the numbers between different teams or people. The same state can be assessed differently by different people – for somebody 6 may be an equivalent of 8 for a different person.
  • Look for trends and significant or unexpected changes. Both on a team and individual level.
  • Look for deviations or exceptions. A drop in one’s scoring may be (but doesn’t necessary is) a symptom that something is not ok. Don’t overreact. Rather do nothing and simply discuss it in the next 1:1 or team meeting (depends on the context).
  • Don’t blame the team! Don’t make them feel guilty for sharing honest yet low scores with you. As soon as you do that you will start getting only 10s going forward.
  • Help an individual or a team face the problem and support them with finding a solution. But only if they want to. Don’t micro-manage and don’t try to fix the problem without having it agreed with the team (or behind their back).


Finally, pick the right tool. In can be a survey (i.e. Microsoft Forms, Google Forms, SurveyMonkey, etc.), shared document, etc. The key is to make it as simple to run as possible therefore I suggest not using any complex corporate-style solutions which can only scare people away from using Team Pulse Check in the first place.

About the author


Head of Engineering, Agile Coach, PMP, PSM, SPS, PAL I, PAL-EBM

Add comment

By Piotr