The Growing cc

I was used to work in small companies, start-ups, or just plain small companies… Soon thereafter I joined my current job, I started to notice what I’ve come to realize is a common practice: The Growing Carbon Copy List, well at least in this company.

This is how it works, I would send an email to one of the QA engineers assigned to the project, something along the lines of :

Hey Mr A. can you please send me an update on the progress of the QA cycle ? in particular on the Regression Test Plan execution as I am worry we might be running late.

As a reply I would get a a quick note: “I’ll send you the information by tomorrow” and a couple of people added to the cc: like his Manager, and the other QA engineer. Later on his Manager would send an update, and now the CC list would also include the Dev. director, and of course his comment will include now the VP of QA… so by now the innocent question has been made visible all the way to the top, Well just one step before the CTO or CEO of the company.

Don’t get me wrong, I am all about visibility and letting stake holders know what’s going on, but it needs to be done in a sensible fashion. I thought I was the only one thinking that this was a problem, but a few months later I was talking with the QA VP, and she happened to mention somthing that I connected to this practice: I usually don’t fully read the emails, as I get too many, unless I am on the To: field. Which I think was her way of saying If I am not on the To: I’ll go to the archive directly.

Sometimes I even remove people from the cc: as I think the topic is going into too much detail, just to find out on the next answer that they’ve been added again.

In the end I suspect is a self defense mechanism, maybe a way to keep a supervisor apraissed of how the time is spent ? maybe a way to “prove” that I was against that from the beginning, or just a I told you so (even if you were not interested at the time). If that’s the case, maybe is a “strange” work environment where people feel the need to self protect using these growing cc list.

So when to use the Cc ? My rule is to include someone in the Cc: when likely that person will become involved in the conversation, either on the email, or even later in a phone or face to face conversation. And I usually even include the reason towards the end of the email, like:

Mr S. I am Cc-ing you as I think we’ll need to include this one on the next release of Product Y

email at work is just one of the many communication tools available today, and even though it is so easy to include anyone on that innocent cc. field, always ask the question: Is this person really interested on this email ?

Of course I’d be curious to know your experiences on these growing Ccs, or is it just me going crazy ?

Offshore Inspiration

I’ve been working with our offshore team for the past 20 months, it’s been an interesting experience, and I would say of mixed success, and I mean that by my standards of success.

The project started by getting new developers on the team back in Shanghai, and of course a few training weeks, a few trips for face to face sessions, and another set of trips to move releases along when they start to run a bit late… I’ll most definitely write another post some time about the whole setting up an offshore team. Now 18 months later, we have had 3 succesful releases out, all of them on time, feature complete, delivered to the customers, so a success by any “external” measure, and I take pride on that .

With my past teams though, pride and ownership of the code has taken place, usually after a few months working together, maybe a succesulf release or two, maybe after working on a particularly hard problem, maybe after praise from the rest of the company, maybe just a combination of all.

This ownership and pride, usually comes in the way of:

• Taking care of the code, keep a clean code base. For example fixing those deprecated calls, and not just the one that you happen to find, but see if it’s used somewhere else.
• Checking out what other are doing, it is “our application” not just my lines in that application
• Refactoring as needed instead of copy/paste small pieces of code here and there
• Doing some “backburner” projects (Hey, what if I change this ? maybe I can get some more performance out of it)
• Enhancing the “misc” “util” kind of classes, so other benefit from commonly used tools.

With the current team, these actions usually take place propted by myself or Mr C. (another senior engineer based on the US). One of the common tasks for myseld and Mr C. is the code review, checking in what was checked into source control by the offshore team, and provide feedback and recommendations on the implementation, we have noticed how the team has grown, we’ve stopped sending the same feedback time and again, and usually later feedback goes more on the design and clarity of the code, so we know that they can take the feedback and make it part of the standard development, however the other part of the feedback goes into the ether, when we say, maybe that should be refactored to support the new xxxx or make a utility class thta can be used from X and Y… that’s the feedback that I believe is more about inspiring the team to make things better, not just make them work, and that’s the one where we have not been so succesful so far…

 Of course I’d be curious to hear your experience and how have you managed to inspire your remote teams, or if you are on the remote side, how have you been inspired to do so, to take ownership and pride on the product being developed.