Thinking about why I haven't blogged in a while, I realized I put a lot of effort into writing things at work. Things that aren't really confidential, but often somewhat project specific. When we first started building this team over a year ago I explicitly did away with most reports to help us discover what shape the team should be. A few weeks ago I finally asked the Ubuntu One team to start writing weekly reports to help broadcast knowledge across timezones and teams, and it struck me that some of the reasoning and content might be interesting to other people who are trying to manage distributed engineering teams. So here is a lightly edited version of the email I sent internally a few weeks ago. Do you manage or work on a distributed engineering team? I'd love to hear your feedback and suggestions. Here's hoping that I fixed the comments on my blog this time around :)
These weekly engineering activity reports will replace the weekly reports that the ops+ team was doing, and replace the daily standup summaries that the foundations+ team was doing. Each team is totally free to conduct their standup meetings using the format, time, and medium that works best for them - the standup is about your immediate work group doing planning for the day, the weekly report is about telling the rest of the team (and company, if they care to look) what you have been doing. I hope the status reporting we used to do on team lead voice calls can be done away with, and we'll be able to spend the voice calls really solving problems rather than catching up with old news - also the whole team will be able to read the status, not just the people who were live on the call.We humans operate at a variety of different cognitive and affective
levels. We think about things like lifelong values, short and medium
term goals, and immediate activities - but not at the same time. It's
vital to spend time thinking and working at each of those levels. One
of the things I love about this team is that we are a team of doers,
not a team of talkers or dreamers or empty unimplementable ideas. The
risk though, is that we never slow down enough to jump up a level or
two and do a weekly review, and think about how our activity that week
supports our goals for the next 3 months, directions for the next 5
years, and that patterns that are emerging. Over time I have found
that forcing myself to do a weekly review, and write a report even if
it's only for me really helps me find and maintain balance and job
satisfaction. I value the ability to move fast, to adapt to change,
to be non-linear, to just do it rather than wait for a committee. But
I've come to accept that taking a few minutes to switch back out of
action mode to reflect on the bigger picture is not just useless
overhead, mental paperwork, it's a critical part of the process of
being a creative person who actually ships. Don't worry, I still
endorse the cult of the done!Also, I've increasingly seen and been told that people don't know what
the rest of the team is working on - this is a both a testament to how
hard communication is in an environment distributed over both
timezones and geography and a tribute to the incredibly diverse set of
projects we are privileged to tackle. But it can also lead to feeling
isolated, to not really having a shared understanding or vision of how
all the parts fit together. It's my hope that by doing these weekly
reports together, we'll have a lot better understanding of and
appreciation for each other. I've talked with the 4 team managers about these reports and gotten unanimous support.This next section is trying to clarify some intentions based on
feedback and questions from them:The goal of this report is not to find scapegoats, to assign blame, or
to point fingers. I don't think we have a problem with people not
doing work. I think we have a big problem with people working their
hearts out somewhat invisibly, and not getting sufficient credit for
their work. The goal of this report is to massively increase
transparency, and often transparency can introduce some feelings of
vulnerability. That means if you have a bad week and get nothing done,
everyone else will know - and I think thats a good thing. Not because
people will point fingers, but because bad weeks happen and everyone
should be able to know the real hard truth of whether progress is
happening or not. It means if you spend 75% of your work helping
salvage some other part of the project that ran into big trouble and
doing customer support, and didn't meet your own plan for the week,
everyone will know and join in appreciating you for seizing the
opportunity to contribute to the overall team when it made more sense
than sticking to the plan. It means if you spend two weeks doing work
on an upstream project that massively improves our standing as thought
leaders, and land zero branches in our own code, everyone will
understand what you are up to and why it's the right thing to be
doing; rather than silently wondering "why is Joe not producing any
code?".A report is not a substitute for real time proactive action. It is
yesterdays news. What does this mean? If the DB server is going to
run out of room in 1 week, and Mary puts that in the report, and then
the DB crashes next week, i wouldn't accept the excuse "but I wrote it
in the report, and nobody did anything" :) There should not be items
like "Joe: the release was late because the QA team did not give
feedback" "Tom: I couldn't give feedback because the tests were
busted, so the release didn't go out". Instead, there should be items
like "Joe: missed the release due to a very short testing window,
worked with Tom on the phone to debug test problems, escalated a lucid
failure to the platform team, and finally got things uploaded 1 day
late."The report is going to be read - but maybe not the same day you write
it. Maybe the most valuable thing that comes out of your activity
report is when Susie Newhacker joins the company in 6 months to work
on a project, and scans through a bunch of weekly reports and
discovers a bunch of valuable links and branches that you reported on
this week. Maybe the most valuable thing is when you can approach your
manager and say "look, we really need to change my core hours or
change how rollouts are scheduled, I got pulled into emergency
firefighting/debugging 6 times in the last 4 weeks and missed
appointments with my family/friends each time".This email has gotten surprisingly long, but I hope it helps explain
why I'm requiring weekly reports and why I'm convinced they are not
just useless overhead. As we get some experience doing them, feel free
to propose additions/deletions/changes to the template. I'm looking
forward to the first activity report from everyone on Monday.
And here is the template I'm using for activity reports from each person on the team (managers also do a more big-picture report that talks about progress of various projects toward the overall roadmap):
- Number of branches landed
- One or two sentence description of each branch here, with a link
- Number of code reviews worked on
- Bugs or blueprints worked on and summary of each, with a link
- Number of packages uploaded to PPA or Ubuntu or Debian
- Upstream project contributions
- Please list any absence last week and planned absence in the upcoming 3 weeks (including travel, sprints, conferences, and holidays)
- Any other activities or achievements
- Did you get pulled into any emergency unplanned work? What was it?
- What is your plan for this week?
- /dev/commentary - this is your chance to highlight something that the whole team should know about - a tip, a joke, a book, a blog, a tweet, a concern, some interesting news, a wild idea. More than a sentence, less than a chapter, links welcome.