My parents always taught me to be modest when speaking about myself, and to let my results speak for itself. However, I found that in a team environment, proactive communication works much better.
How do you share your day to day with your team? What tools, methods, or habits do you use to solve this problem?
- Always check in with your manager. Let them know your status before they ask.
- Make sure to deliver your stuff on time. If you can't do it, let your manager and other related team members before it's too late. Explain the reasons why you failed and learn your lessons. Try to avoid the same situation happen to you again. If it's your fault, accept it and move on. Try to do better next time.
- Share big and important updates with your team. It can be something simple like "Hey everybody, I did this and here you can take a look". If you use Slack you can post this to a public channel or you can send it via email.
- Add screen recordings to your Merge Requests. You can use Gif tools like, LICEcap or recordit.co.
- Be responsive to your mails, issues, TODOs, Merge Request comments etc.
- Always make sure that you have assigned with something to work on and you know what to do next.
- Try to be available when someone needs your help.
- Last one, maybe the most important one is doing a weekly meeting. If you don't have a weekly team meeting, you should tell your manager to start doing one. It's the most easiest and productive way to share important updates and sync up with other team members. At GitLab, we have a shared Google Doc and everyone can add their items to that list. Then people talk about their items then pass it to next person. You can also do daily stand-up meetings. It should be something quick and every team member should have 1-2 minute to talk about their updates and answer the questions below. You can also do this in async way by posting answers of these questions to a Slack channel.
I. What did you work on yesterday?
II. What will you work on today?
III. Is there any obstacles?
- Add screen recordings to your Merge Requests. You can use Gif tools like, LICEcap or recordit.co.
Also, that last meeting you talk about is usually called a stand-up meeting and when using Scrum project management it is supposed to be every day. I don't think I've ever heard of it being done once a week. Not that it is abad thing, I'm curious if some other companies are only doing it once a week.
To be fair most workers are never going to do on their own what the business wants or what is good for the team. They don't understand it well enough as they are neither business people nor managers and it's not up to them.
Really? Business is so magical that someone with a Computer Science degree couldn't possibly understand business.
As a manager or CEO it is your job to make sure everyone in the company understands the mission and what is needed to get there. And that everyone is empowered to act on a daily basis to move that mission forward.
A leader realizes that the people on their team have insights and knowledge that they do not. A good leader empowers not dictates. You sir, have some lessons to learn.
There is a reason so many great companies are founded by software engineers. Based on your logic those should all fail because Software Engineers should just stick to coding not thinking about what is best for the business.
For us, weekly meetings are more of a phoning home than a game plan meeting. I can see situations in which stand up meeting might be useful, -> when there is mutual overlap between engagements.
In answering your question though, the need for stand up meetings, imo, is dictated by the size of the group working on the same project.
It's always short, maybe around 3-5 bullet points, with a link to something showing the end result of the task. (Github is good enough for a technical audience, but you probably want to link to the actual end-result for nontechnical audiences)
The big thing though, is the attitude you have towards yourself and your teammates when presenting this stuff.
You shouldn't be presenting it as proof that you're working and not sitting at the beach or something. You also shouldn't present it as some sort of validation, like "Bob got praise from the CEO, I did good stuff too, I want praise!". Instead, you should approach it as "I've been working on this thing that's related to what you've been doing. I kind of feel like you might not know about it, or not know the extent that it impacts your work. Here's some info. If it's old info, I've wasted the minimum amount of your time I can. If it's new, I've just made your job that much easier".
And just send them out when you feel that disconnect. More often than not, your instinct is right and the other team members really could use that info.
To date, I've only ever received positive feedback on these sporadic unscheduled status reports :)
It's particularly valuable when meetings that happen entirely in one office get the result shared out to remote folks who might not have even known it happened. The biggest complaint we have from remote workers is FOMO, and often just a one-liner about a meeting's result puts a lot of that to rest.
a) make an effort to share things other than work - interesting articles you read, participate/respond in watercooler chats, post side-projects you may be working on, your favorite hobbies, post when you are stepping out and are back again, etc. This is counter-intuitive and not a direct solution, but you end up seeming like a human rather than some remote contractor. Once that happens, people start taking more interest in your work automatically.
b) get to know your colleagues, start meetings with a little bit of small talk, explicitly ask for feedback and don't hesitate to speak up if your team takes a decision that is not very remote-friendly (I've messed up plenty here!). Many teams will go out of the way to integrate you if you tell them how.
c) try writing summaries at the end of each day, week ... even if nobody is paying attention initially. Daily summaries are private and for standup while I record weekly updates on some internal wiki. I like cartoons, so I typically include some cartoons in my weekly summaries.
d) attend standup and come prepared. Your updates should be much longer and much more detailed than someone who is not remote. Days you miss standup, you should try posting your update on Slack.
e) turn on your camera for all meetings. It's another one of those habits that make remote workers much more 'real' and relatable.
f) make sure you have good audio/video and Internet connection.
Basically my activity is visible on the source tracker through the PR is submit and review, the bug tracker, Slack discussions, and we have a daily team meeting where everyone shared what he/she's doing.
We also have a Geekbot on slack so everyone can share what he's done in the day and what he's planning to do the next day.
We have automated slack notifications for GitHub commits, and the team leader and all other developers have full access to the git logs to see what each of us has done. We also use Trello to keep track of tasks.
Some teammates use https://github.com/phw/peek.
For GIFs/videos, my company has a CloudApp account which makes it super easy to record screen captures.
- Asynchronous standups with Geekbot in Slack (https://geekbot.io/). Any shared doc will do here, really.
- Occasional demos over video chat of new functionality to internal teams. It helps that my entire team attends.
- Our API has a chatbot that we can use to query it, so I can show new features for that part of the infrastructure directly in our team channel.
- Ask people for code reviews, and rotate who you ask.
- Ask people to pair program with you over a screen share, or offer to pair with them.
It helps if your team is 100% remote. If it isn't, maybe talk with your team about trying to get people to be more disciplined about making decisions via chat or team meetings rather than only with the people in the office. One thing a few coworkers and I did when we were 3 out of 8 who worked in the office was catch everybody up on IRC whenever we had a side discussion. It's unrealistic to expect everything to happen over chat mediums with that kind of team, but something like that can help.
(edited to fix formatting)
Here's the template:
Hey {{ manager.name}}, here’s my status update for today.
1. I got the free email, created, scheduled, and ready to be sent. 2. I fixed the job creator bugs related to the timezone issues 3. I added a few dynamic rules to the email creator to make things easier in the future.
Here’s the document where I document those dynamic rules: {{ link }}
Tomorrow, I'm going to implement the automatic country-tagging based on the user's timezone.
---
A simple daily summary like that really helped increase my communication with my manager and help keep us on the same page. I even ended up creating a #status-update channel on the Slack we use.
The gantt charts and reports allow each member to ensure they can validate their work progress, and the project manager/leads being able to visualize it as well at any time.
Myself and two others also use Jira/Jira Core separately for operations and software issue tracking.
Wrike and Jira both integrate with Microsoft Teams as functional, browsable tabs and serves to provide connected dashboards in real-time.
We have team members across four countries so weekly meetings involve screen sharing, annotation, and task creation/assignment in Wrike done on the fly as well.
Regardless of your software choices, my tip is to ensure you have a way of reporting/visualizing progress and being able to integrate the project management tool with your communication tool of choice.
Since then, I've moved onto a totally different area of work, and if I'm doing my job right, my work should be almost imperceptible to the rest of the team. Occasionally I have to ask the team to adapt to a new process, etc. which isn't helpful since they only really see the negative aspects of my role, but again, my manager is happy, so I'm happy.
You asked about tools, etc. and I'll cover that, but I wanted to share that I don't think it's of vital importance that everyone knows what you are working on. It's understandable to want to know what everyone else is working on, and if that's the case, bring it up with your manager. Let them know that you'd like to know more about the rest of the team and work out a solution with them. However, it will never be perfect.
So, in terms of tooling for us, we use Slack for day to day communication (somewhat ironic considering we work on an email client), and we have a few different channels for our work. The two most important one are our general one for the app where we can ask questions, share advice, etc. The other is our "syncup" channel where we post update of what we are working on, what we worked on, etc. It's basically a standup channel. The hardest part is remembering to update it regularly. In addition, we have a full team meeting once a week via video call.
So, basically, use Slack/Hip Chat/email/whatever for regular updates with everyone, and for the bigger picture stuff, you only need to convince your manager that you are getting everything done.
If using agile, create work items/PBIs for everything and document decisions in your tool (or, less optimally, in slack/teams/other persistent group chat tool). I obsessively look in these tools to understand what my team is doing/ has done.
Go through work items/PBIs as a team frequently (we nominally do daily, it’s more like every other day) to update remaining work. If I as the L1 manager see your work melting away I’m happy and you have great evidence of productivity.
Communicate what is happening in the rest of your life. If I know my team member has family visiting or a sick kid I can mentally process that better than a simple “my productivity will be down for a few days”. Even worse is not communicating at all- I have seen team members disappear for days and screw up our sprint commitments. I understand there are cultural issues here at times, but team members who don’t communicate are a problem: the customer and L2+ bosses want to know reasons why things slip and this information often gets communicated up the chain. Why work isn’t happening is also important.
Don’t miss commitments and communicate risks or issues that might cause a miss early and loudly. And do so in writing (preferably in the chat channel). I have had people burn down a PBI for a whole sprint only to discover it half done, now we have a trust issue and I’m not sure I can trust the information I do have about productivity.
Note- I don’t really track my teams PRs or code commits, I track completion of user stories/tasks. One of my team members talked the customer into using an off the shelf service to implement a feature last week. No code commit, but I know her productivity is very high because she knocked off her features like crazy.
Demo both code and features to team. This is great for knowledge transfer and keeps the whole team aware of what is going on.
Hope that helps.
Ed- I work in a very “enterprisey” world, YMMV in more consumer or packaged service oriented world
Tooling wise, we use Flowdock, Phabricator and Google hangouts for meetings. PR are to have GIFs attached.
-An asynchronous daily scrum session in Rocket Chat (awesome free, self-hosted tool).
-A channel in Rocket Chat dedicated to alert about commits. Commits are actually the most important criteria for measuring an engineer's output.
-GitLab board. (Previously Trello board).
-If everyone speaks in a public channel (even if only speaking directly to a single person), one's output can be judged if she is making and answering questions.
However, the majority of people do not want to reach back, and to those people I don't press the issue with repeated attempts. I think that a lot of people are put off by small talk, or are just too busy for it; I hope with them that not having a memory of me as being annoying is the best relationship I can have.
Sometimes they will just say "Sorry I'm just really busy" - this is great information too just as a barometer. It's less often, but a poke with a joke can get you onto some side work that improves your reputation if you're able to genuinely assist someone having a bad month.
I have the option to work remotely but I take the 40 minute commute in, because I get a lot better mileage off people by reading their body language, faces, where they are looking, holding their arms, how far they stand from me, et cetera. It's like running a program with the -debug flag, for me, and remotely I have no access to it.
And I hate to say it, but I feel that you hope one level up the stack just by being present. It's almost a digital caste system. Some useless kid texting his friends in the conference room has equal clout as the seasoned principal dialed in on the phone.
Also - since we're in this thread - is it just me, or does a time delay on a conference call make the speaker seem less intelligent? I get embarrassed when I learn I am on a 1.5 second audio delay. I will often dial in over PSTN to get that second back.
I agree with OP about letting results be the message, but it is a frustrating way to communicate technical ability because there is no short term payoff. Team members that give impressive, meaningless, daily updates fall flat at the end of a development sprint during a demonstration. Make that the time for your results to speak for you to the people you want to impress, because that is the only time during the sprint that they are probably paying attention to you.
To try and round out my claims above, I've also been the person being annoyed by a chatty remote coworker. Being gracious to them in times of duress is the same game triggered by callback.
I don’t see how one can do better than that, since anyone can lie/rationalize under pressure of a Skype session; it’s better to see concrete progress, but this requires trust in both directions.
As long as I don't go over the estimates too much everything is okay.
Of course these are never accurate, but with the right granulation(max. 2d per task or subtask) they help with communicating what is it that you do.
It's my job to work out how it gets done and to abstract the necessary information for the SM/PMs.