How to ask software team for basic yet important tasks without lowering morale?

Question

So here's the deal - I have a software engineering team I'm the lead of that is remote (different country and timezone - take strong note of this. Too many responses I think are from people envisioning a self contained single office. There are narrow windows I can communicate with my team.) and communication is a key apart of our success. The team is awesome and they work really hard for me and for us. The work they do is great and I'm proud to work with them; they are some of the best I have ever worked with.

However I have 1 small reoccuring issue with them that I have addressed kindly several times which still seems to be an issue. We have a central place where teams can communicate their daily progress. It takes all of 5-10 minutes daily to complete.

This helps me understand what the progress they made, issues, and where I need to pick up and continue. So for example, I might get a current code update from the repository and see very few if no files committed. It's not completely unforeseen, but I typically jump over to the 'daily progress' page hoping to see something like this:

Worked on Task 'x' but ran into an issue with 'y' and 'z'. Will look to see if 'a,b,c,' will fix it tomorrow. Could not commit this code because it would not build.

Easy enough! 3 sentences and I know exactly what's going on and can keep moving forward. The problem is when I get no communicated updates. Was there something wrong? Did someone call into work? Was there a build issue? etc. etc. Communication is key. I have meetings 2-3 days a week with them and making it 5 to get daily updates is not necessarily the answer.

My quandary exists because I have an excellent rapport with my team and they work really hard. I'm worried about putting on the pressure via "OK guys, we have talked about this 3-4 times before and I'm still not getting updates...." They are doing the hard part (great code) but missing on the easy part.

How do I approach this 1 more time (and yes I have contacted the PMs and management and they have had meetings on directing the team about what to do) without getting my team in trouble for forgetting to do some of the lesser basic tasks (yet still important to me)? I just don't want to mess up the good vibe we have getting the real work done.

Answer 1

Get them on board with it. Present this as a problem to your team: "I'm remote from you. We have a limited window in which we can communicate during our respective working hours. I need to know what's happened in your day so that I can help you. For example, we recently experienced a build blocker. It occurred a couple of days before our regular team meeting, and I didn't find out about it until the team meeting. I was able to address it when I found out about it. I could have helped you earlier. How can we avoid problems like this in the future?"

Factor in cultural issues. They could fear that posting information in a public place (say, on a wiki that anyone in the company can access) could put their job in jeopardy if they admit that they're having trouble. They could not want to lose face. They could not want to make their colleagues look bad. They could not want to admit that they're experiencing a problem because they fear that it makes them look incompetent. Consider what might be blocking them other than a simple allergy to "busywork", and come up with a strategy that will meet their needs too. It might be that you don't get your status page, but rather you get it all in email. It's a bit more difficult for you to see at a glance, but if it gets you the information that you need, I'm sure that you can do a bit of work on your end to make it more easily consumable by you.

Lead by example. Whatever daily status you want from them is probably daily status that they'd like from you so that they have some insight into what's happening when you're working. "We've run into an issue with our build system, so I talked to IT about it, and they're planning on rolling out a fix at 8pm PT / 2am your time. You should be able to build tomorrow morning."

Answer 2

It sounds like your common place is essentially where you want your daily scrum meeting to happen, and some people are not speaking (metaphorically) in the meeting. Encourage them to think of this as a virtual scrum meeting, and to just give a quick update, even when they do check things in.

If this is a place where EVERYONE writes at least one sentence about their daily progress, then it will be more apparent when people are not contributing (just as in a scrum). It is a place where they can see what others (including you) are doing. And encourage them even if they only write one sentence. If this has value, it will be something they continue to use, perhaps in more detail. If it doesn't have value to anyone but you, then it may still need to be done, if the value to you is greater than the pain to all of them together. But, if it is only one sentence (at least to start), a simple scrum status, there really shouldn't be that much pain.

But, you will need to talk to them again, point out the value it provides to you, and ask if they have ideas that will help it provide value to them too. Push it as a daily, virtual scrum where everyone contributes, if only briefly.

I suspect it can help the whole team work together better, help solve each other's problems more quickly, just as in a good scrum. If so, then it will bring value to the whole team.

Answer 3

It doesn't sound like your team has any real objections to making updates. It sounds more like the team is neglecting to make updates, and you want to remind them without nagging them. It might help if the team members had a non-intrusive recurring notice of some kind that cues the thought, "Oh, it's time to make my update today."

My team handles this with emails to each team member when someone posts their daily update. When one person posts, it reminds everyone else to post too. If you make your daily update first, the whole team will always be reminded.

Another option would be putting 5 minutes on their calendars for "update time" or something similar. Seeing it on the calendar every day will remind them to make updates.

Answer 4

Remembering to do mundane tasks can be challenging. I would attempt to build this into the system.

1) I would do my best to make sure all work is associated to a task (JIRA in this case). This allows for all progress on the task to be tracked.

2) Make "commit" comments mandatory. If you only expect a short message this should be sufficient to what happened. Developers should not have long periods of time between commits so this should be satisfactory for most days.

In the event that a Developer is assigned to a task and they did not commit any changes for a day then the assumption should be something is wrong; the task is too large, they hit a road block, etc. This should be a red flag and give you the opportunity to reach out to the developer individually to determine what their issue is.

In my experience (as a developer) manual "checklist" tasks are the most troublesome to get done. Even if it only takes a short period of time to complete this task, the task itself is very intrusive into the though process of your developers.

When they are built into the system in some fashion they are much more organic to complete and feel less intrusive. Work on improving communication systemicly rather than hoping that you developers remember to fill in a mundane update.

Answer 5

From an Agile perspective:

Implement daily scrum stand up meeting... remotely. Get a conference line, or some web cams and do a daily meeting:

What did you do?

What are you working on today?

Any blockers?

Now, about the time zone difference: You're going to have to figure out a compromise here, surely there's 15 minutes that overlaps somewhere for you all to talk.

Seeing as you'll get a turn to talk every day, you can stress your concerns and hold people accountable.

Answer 6

To all the other great answers I would add that using a good shared project management tool like Trello, Jira or Pivotal Tracker can be a great help. It gets the developers focusing on the tickets, bugs, chores, etc and leads to helping them with managing their own work.
My personal favorite is Pivotal Tracker having used it in several organizations plus personal projects.
Then there might be a separate task of summarizing from such a tool to update the location/document you require, but this step might now be easier for 1 person (you) when you can do it all by combing through all the emails you are automatically being cc'd about by the tool.

Answer 7

You’re the team lead. Tomorrow, you check who hasn’t sent his notes in, and you call them, and ask for the reason why they didn’t. Tell them that it is important to you. Tell them to put an alarm in their calendar ten minutes before the notes are due.

If you have to call them a second time and they don’t have an alarm set, ask them to set it now, while you’re on the phone. If you have to call a third time, you advise them that it will be reflected on their performance review.

Answer 8

They are doing the hard part (great code) but missing on the easy part (ed.: communication).

(emphasis mine)

That's your perspective. I'm sure for many developers what's "easy" and what's "hard" is not the same as what's "easy" and "hard" for you.

Answer 9

Speaking from the perspective of a programmer working in remote environment, writing such a daily update may feel really pointless. Use git log to see what I've done, and if I have any problems/questions I'll just ask you directly, right? And if you, as a lead, need me to tell you what's going on—then just ask[0].

In other words, it seems you've already asked your team—more than once, apparently—and they have tacitly answered. Maybe you should try attacking the problem from another angle. And, as a lead, maybe you should be ready to follow up individually with team members on their progress as part of regular workflow.

[0] You mentioned time zone difference. Likely there still is some overlap (if not—it should be introduced, IMO it's very important for successful communication when working remotely).

Update #0: At my workplace we use a three-component system, which seems to work out pretty well:

• Bi-weekly meetings serve as milestones and is a chance for management to evaluate and estimate.
• We use a project management system similar to Jira and we make sure to have a ticket for any task one might work on—this helps with tracking people's activity.
• Any ongoing issues (such as production accidents, urgent fixes, etc.) are followed-up upon more or less individually via informal means.

Update #1: ask yourself whether you, in fact, are trying to micro-manage your developers. If someone doesn't accomplish what's expected from them, you should raise a question of firing them. Micromanaging, however, is not the answer. There're a few interesting comments on the topic on this post by Ian Bicking.

Update #2: here's a collection of great points that explains my idea in a more eloquent way: 44 engineering management lessons. Hopefully someone having same question as OP will find it worthy of a read (for their and their team's sake).

Two relevant lessons there are:

• Hire great people, then trust them completely. Evaluate performance on monthly or quarterly basis, then fire if you have to. Don’t evaluate people daily, it will drive everyone (including you) insane.

• Enforce behavioral and performance standards. Fire bullies and underperformers.

You ask how to make your team do something you want. Maybe you should ask instead whether your request is a sane management practice in software engineering world. Forgive me my bluntness, but dealing with underperforming team members by requiring daily evaluation from everyone probably isn't.