30

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.

migrated from programmers.stackexchange.com Mar 8 '13 at 17:46

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • @MrFox - what if there was no commit? This method will then not work. Plus even then if the comments are vague, it may still not be enough to get a good understanding. Re-read my OP. I want to know what the hold up is and if I can help since we all work together. – atconway Mar 8 '13 at 18:37
  • 4
    I understand your use case because I have a mostly remote team and one of those developers is in a timezone 18 hours ahead of the rest of us. I also understand your need to act as a good team leader should in clearing blockers. To that end, while I could give some helpful answer (probably), could you clarify if your team is having daily standups with their local PMs or anyone? – jcmeloni Mar 8 '13 at 18:52
  • Could you also describe a bit more about how in your experience providing scrum-like updates directly correlates to lowered morale? Or why that is a concern/inevitability in this instance? – jcmeloni Mar 8 '13 at 18:58
  • 1
    Ok, so following along all these comments, your question seems to boil down to "We have (or had) all the "right" structures in place for everyone to be transparent and good communicators, but 25% of the time people don't do it and that causes problems; how do I convince them to consistently do one or more of these simple things?" Right? (If that's the case, HLGEM's comments are totally right.) – jcmeloni Mar 8 '13 at 19:46
  • 3
    Bottom line is that software developers tend to be pragmatic. If they have nothing significant to report then they will choose to get work done instead of being diverted doing useless tasks (and believe me even if it only takes 5 minutes to fill out your form, the diversion will take far, far longer before they are again productive). I think you have bigger problems than people not filling out forms if you can't count on your developers to raise issues when they occur. Someone who doesn't raise issues is far worse than people not filling out status reports that don't help get the job done. – Dunk Mar 11 '13 at 21:51
27

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."

  • 1
    I'd say I've have done everything you listed and great feedback so thank you. We actually used to do emails, and switched over to team web pages (with restricted access) to post updates and streamline the process. I have sent them samples of good entries (similar to the one in my OP), and myself make daily updates like that. They are not fighting me, I think mostly they are forgetting to do it. I just don't want to 'nag' since the most important work (coding) is being done well. – atconway Mar 8 '13 at 19:40
  • 1
    If you do think it’s forgetting, could you deploy something that reminds them to submit their update if they have not submitted anything and their scheduled hours of work are coming to an end? If they naturally use the team webpages anyway, they could be prompted through that and given the option to submit their update as part of the prompt; otherwise, a solution that provides the same functionality as a desktop application could also work (obviously, they could kill this process, but at that point it isn’t an issue for forgetting anymore). – Matt Mar 8 '13 at 19:49
  • Also, +1 for "not want to make their colleagues look bad". Especially potent if it is posted publicly and they don't want to be perceived as "ratting out" their colleagues even if it is just a simple statement of fact. – Matt Mar 8 '13 at 19:55
  • @atconway, why did you switch away from emails? You could send an email to the team during your ‘communication session’, and then members would answer (using ‘Respond to all’) with their updates. It'd also make obvious to everyone when someone doesn't respond, which may help with discipline. To me it looks like it's pretty easy to forget to post updates with your current workflow—it may look not important, but IMO matters. (I also work in a remote environment, and have observed similar problems.) – Anton Strogonoff Mar 9 '13 at 0:18
  • @AntonStrogonoff - the issues with emails is like most of us there are already too many in our inbox. Filters, yeah I get it, but they were being lost among 1000 other emails. The biggest reason though was for centralized transparency for outside management that wanted a 'drive by' view of the project's status outside the more formal project plan. – atconway Mar 11 '13 at 12:39
11

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.

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.

  • 1
    +! for practical ideas to help address the issue. Also use alarms/reminders and talk about your own usage of the them. – Michael Durrant Mar 8 '13 at 22:21
3

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.

2

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.

1

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.

  • JIRA is being used! However at this point not every task has a JIRA associated with it necessarily to comment on, thus the use of the centralized team page. – atconway Mar 8 '13 at 22:29
  • @atconway: Where I work, nothing is done without a JIRA. Sure, I can create a JIRA myself, write down what I will be doing, do it, mark the JIRA as resolved, but there will be a JIRA. – gnasher729 May 5 '18 at 22:55
1

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.

0

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.

  • 1
    This does not answer the question of how to get people on board with these tasks. – Erik May 7 '18 at 9:25
-4

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.

  • 3
    This was the case when no files was checked into version control, so why do you suggest checking that log? – Petter Nordlander Mar 9 '13 at 6:14
  • Sure, that's what I'm talking about in the next sentence. – Anton Strogonoff Mar 9 '13 at 6:46
  • 1
    The comments from source control commits are usually fragments and do not offer the detail typically required. I don't want to result to reverse engineering code either. Lastly, the comment you made just ask, isn't that what I did? I should not have to baby sit and ping people for updates. We are all paid professionals and this is as easy as getting up in the morning and brushing my teeth. You think my parents still need to tell me to do that on a daily basis? (rhetorical question) As well it's to easy of a task but yet holds merit for me to constantly have to remind people to do. – atconway Mar 14 '13 at 1:56
  • 1
    Communication is significant part of team lead's job. Pinging people for updates if necessary, dealing with a lot of email indeed come as a part of it. Same as other lower-level management jobs. – Anton Strogonoff Mar 16 '13 at 14:32
  • Completeness of commit messages depends on programmer's discipline, I guess. – Anton Strogonoff Mar 16 '13 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.