views:

443

answers:

7

I am a reasonably experienced C# developer (about 5 year experience) that has recently been put in charge of my first development team as technical lead (varying between 3-5 other developers). Over the last 4 months in this role, one dilemma that keeps arising is trying to find the right degree of sharing awareness of the communication that goes on between the project manager, account manager, clients, designers, CEO and myself (especially via emails).

On the one hand, I know the more awareness each developer has of the overall direction of the project, the better they can understand the scope that their particular functionality has in the big picture.

However on the other hand, a lot of my time seems to be lost in the sea of emails between all the different stakeholders and managers, so I like to think that isolating the developers to just "what they need to do their current bit of work" will keep them free from interruptions.

I have considered just BCCing all the developers so they can filter these emails and essentially "opt in" to all the emails, but I'm concerned that some of the developers will just see this as extra noise to deal with. It may open the door to "too many cooks" if all the developers want to contribute to too many discussions. Yet on the other hand, other opinions can help me reach better decisions (i.e. House MD style).

Phew... so much to consider. Anyone have some wise guidance in this area?

+3  A: 

One way might be to not forward all those emails and once a week compile all the relevant information, design changes, and so forth into a weekly meeting. I definitely wouldn't send out a barrage of emails to the developers. Of course, if something critical is discussed, then that should be put to their attention. However, try for a weekly recap and discussion of relevant details.

BobbyShaftoe
Project Wiki with weekly updates.
Simucal
Yeah, a Wiki would be a good tool here.
BobbyShaftoe
+5  A: 

The engineering team needs to understand the business reasons of why they are asked to do things on a macro-level. The engineering team will gain understanding and motivation from this. But too much chatter is a no-no, as you note, part of your job is to filter, and part of that means not exposing them to tons of noise. Your developers likely have opinions and insights as to how to do particular things or why to pick particular technologies, and they should be fielded for their expertise in those areas.

Definitely don't create a culture of BCCing.

One option is to have separate mailing lists that interested parties can subscribe to, but of course, not all chatter will be on those lists.

And of course, a regular company meeting is a must. Let the engineering guys know why the business depends on delivery of a stable, complete product (or whatever the upcoming milestones require). 20 minutes, no slides, no bullshit is what works for me. Your team & situation may vary.

Mitch Haile
Agreed. Communicating why certain things are needed can definitely motivate developers. User empathy is often missing from developers, but can really help improve many aspects of development.
sjbotha
+3  A: 

I'd be using a Wiki, you don't want to add to the email storm, and your developers can also contribute and change things. It's also really useful for sharing documents, and if done well it will become self-supporting.

BTW Cut/Paste from email to wiki seems like an odd thing to have to do, does anyone know a lightwieght .Net wiki that I can email content too?

MrTelly
I would recommend copy+paste. You'll be able to do much better by selectively putting stuff in yourself.
sjbotha
but why do I have to use two environments, it'd be so much easier to email to the wiki, especially from outside the organisation
MrTelly
It would be easy to write some kind of plugin for a Wiki to do that. Although, that would be better for creating new Wiki topics rather than being able to modify current ones.
BobbyShaftoe
If there's too much information then no-one will read it.
sjbotha
emailing itself is a communication anti pattern for 90% of the scenarios
Schneider
+3  A: 

It sounds like you're technical so I would give you this advice: Follow Joel Spolsky's advice on what Program Managers do. Basically, try to isolate your developers as much as possible so they can be as productive as possible.

He just mentioned this briefly in this recent article, How to be a program manager, but he has gone into more depth on this topic before. Look through his past writings for more info:

Once the spec was finished and the development team got down to work, I had two responsibilities: resolving any questions that came up about the design, and talking to all the other teams so that the developers didn’t have to.

If you aren't technical then you need to select someone from your team to help with the design work and they will have to interface with the customer a little to figure out what the requirements are and what the best design is.

EDIT: On Joel's home page there are two sections titled Tech Lead and Program Manager. Look at the articles there for some more info on program managers, especially Human Task Switches Considered Harmful.

sjbotha
that sounds like a horrible idea. why would you talk to other teams? to negotiate interfaces, establish requirements, clarify things... playing chinese whispers via email forwarding is a total waste of time. developers need to be directly involved in requirements as much as problem solving
Schneider
A: 

Ask them what they'd prefer. I assume they would rather not be cc'd on every email and would opt for a short verbal update on a regular basis.

danswain
+6  A: 

Answering late, but still believe there is something to add to the superb advice given so far. To answer your question we need to go a level higher, hence the long response.

You’ve been made a tech lead responsible for team and although many aspects of your everyday job might seem to resemble your dev days the way you need to go about them has changed. In software development environment there is usually not that much of a tangible change when you appointed a tech lead (you’re probably still seating at the same desk, wearing the same outfit) as opposed to becoming a foreman on construction site or a factory. The flattering change though is that you now get invited into all these meeting and start getting all these e-mails and phone calls from people outside the dev team.

The lack of tangible change might trick your mind into thinking that you just need to keep treating your job mostly the same. This is not the case and you need to be conscious about your actions and re-actions in the new capacity. It might seem you’re now a bit “more respected” externally and you might be inclined to share some of that “respect” coming your way internally, play a bit of democracy and generally be fair.

Well, this is not that much about fairness or respect, the new job is to:

  • Direct the dev team (mostly by personal example and creating imagery depicting the goal).

  • Be an abstraction layer between the team and other organisational units.

Pretty much like in programming you often create an abstraction layer to encapsulate and hide complexity, the same happens in organisations. You’re the layer, the interface that has to encapsulate the dev team. And any good encapsulation from an outsider point of view:

  • Hides inner complexity that is not relevant to the task at hand (such as concrete implementation of an algorithm) from the outside observer.

  • Makes things that could affect the outside user explicit (exceptions that can be thrown, any limitations and constraints etc).

  • Always gives meaningful feedback.

  • Acts consistently.

These principles are equally applicable to the team’s outward communication. It’s not an easy task to follow these principles; actually it involves a lot of concrete work, such as deciding what details are internal and what facts need to be communicated and when, how the feedback needs to be best structured and be presented in a consistent manner and who should be notified externally of what, and who needs to followed up and when. This is a lot of work, even if some of it seems to be just trivial admin.

Now to internal, inward communication. One way is to broadcast. But it clogs the internal network and everyone has to spend their time on deciding whether the communication bears any relevance to them. It is like having a very generic algorithm that regardless of input always does the exact same amount of work. It’s sure possible, but why would you want to do that? A more efficient way is obviously to adjust processing depending on the input and here it has to be someone’s job to make a decision how the team should go about something, to dispatch, or convert the input:

  • Decide what sequence of actions needs to be taken,

  • or just acknowledge and store for future reference,

  • or follow up,

  • or put an issue off for a later review and then make sure it is reviewed and fed back into the decision-making loop.

This is not a small job either and someone has to do it. Obviously now it’s your job to manage the outward and inward communication, and you have to spend some of your brain’s processing power to do it well, so no one else has to and devs can concentrate on their tasks.

There are some other good reasons for not CC-ing or BCC-ing everyone regardless of your job title:

  • TO means “take action”, CC — “take note for future reference”, BCC — “eavesdrop or mass mail”. You should be careful when you use one or another e-mailing a group of people:

    • E-mailing a single person is a straight forward “TO”, when E-mailing a group of people only “TO” these who you need to take action (including a simple acknowledgement). This is default meaning, in any other case explicitly tell them what is expected (i.e. FYI, no action needed etc).

    • CC only these who you want to take note of the information for the future reference. If you expect a number of e-mails to go back and forth before an agreement is reached or issue is resolved don’t “CC”, it’s best to send a summary confirmation later to other parties that need to be notified. Besides saving everyone’s time and avoiding misinterpretation due to someone taking note of a non-final communication that will help make exchange more personal, flow more naturally, and reduce formalism and red-tape. Often CC-d e-mails treated formally and this isn’t always a good thing (but sometimes exactly what you want).

    • Using BCC is almost never ok. The knowledge of someone eavesdropping on your conversations if come to light will easily ruin your trustworthiness. It is simply a question of “when”. And should your team worry then that you might be BCC-ing their conversations to someone else? Mass mailing through BCC in most cases is also wrong, it creates an impression that e-mail is specifically addressed to the recipient.

  • Forwarding, CC-ing and BCC-ing require little effort, but multiply noise and dilutes signal. It is worth to give some thought to what exactly you need a person to do and what they should know to act on your communication before composing it.

  • Some conversations are best taken completely "off line" (phone or better still face-to-face), because it gives you more room for maneveour. Broadcasting or formalising in writting is just like putting yourself into a corner. You can always confirm in writing latter.

Moving to the second part of a tech lead responsibility (directing the team through personal example and imagery depicting the goal). To accomplish that you don’t need to pass on to the team every single piece of information that happen to end in your inbox. You have to create a story and any good story is an abstraction of real events that consists of only relevant and interesting detail for a particular audience. Creating this brief story on the basis of your everyday experience and judging what is relevant and interesting and then presenting it regularly to the team is also quite a job.

But don't forget that by directing the team and serving as abstraction layer you help developers and outside world to interact more efficiently, accomplish more and tackle greater complexity, the job has a point.

Totophil
Wow, thanks for the comprehensive reply! You have been a little too general in your response though. I was specifically seeking guidance on the level of management communication to make available to the developers and in what way to do it.
Brian Hinchey
Brian you welcome. You say "level of management communication to make available to developers". First part of the reply deals with it: you're becoming a part of management team, not a manager yet,but you're a "petty officer" now. It's "not them and us", you're a part of "them" now.
Totophil
You asking about "in what the way to do it". The answer: aim to add value to the communication process (not necessarily the message itself); do not serve just as a thin messaging layer. Analyse, collate and organise information then look for best ways of presenting it, try to anticipate re-action.
Totophil
Don’t forget you need to add some value to communication in the upward direction as much as when communicating to your developers. Practically that mean you need to learn about available communication tools and techniques: when to e-mail, when to pick up a phone and give a call, when to mention
Totophil
"off-the-record", when to present to the entire team, when have face-to-face conversation. When to be formal and when informal and when hint.
Totophil
Sorry, if the tone might seem a bit patronising this is not intended, I should really have told a story illustrating the points but the reply would have been 3000 words longer...
Totophil
+1  A: 

I'm seeing this question one year after it's been posted, however I can add my experience with some specific data for my case. For 2-3 developers on the project, I mostly do one-on-ones. Lot of times I do this over the IM or phone since most of my team spends a lot of time in home office. Meeting from time to time is inevitable, mostly when project is starting (1-2 developer meetings tend to be enough to kick off reasonably complicated project), but as a rule, all communication with the rest of the company goes through me and developers get a digest. Only exception is when I connect developer directly with the user (not management!) to work out details of the project.

I tend to avoid regular meetings (weekly or daily) and schedule meetings only when at least two of these happen, in this order:

  1. Important info comes in (depending on urgency this can wait up to a week)
  2. Developers are in the office, preferably for other reasons (developer-to-developer meetings)
  3. Client is available (not much choice there, but I try to do meetings and connect developers with single hands-on expert on the client's side later)
  4. I need design advice (since I'm a technical lead, I'm responsible for most of the high-level architectural decisions)

For teams of 4-8 people (8 people usually means two teams) I found out that short 30-minute meeting roughly once a week is more then enough to keep everyone up to date. This, of course, is in addition to one-on-ones which I do daily for junior developer and about twice a week for senior developers.

For one-on-ones, I prefer that developers contact me when they're looking for more to do or when they're have questions on task they just started doing. This is also a great way for me to keep eye on how things are going without developers needing to think about keeping me up to date. I tend to avoid e-mail when IM is enough, otherwise switch to phone (when there's something to explain or discuss) and to e-mail when:

  • Customer reported bug via e-mail
  • There are a lot of important small details and developer will probably go through that e-mail a lot of times during implementation

There are also developer-to-developer meetings when they need to coordinate on something (for example, when Java and Javascript developer need to work out interface details).

This way of working means that I have to respond to IM as fast as possible, and that I usually deal with a lot of interruptions so that developers have to deal only with interruptions for me or other developers. Which is OK, since important part of my job is to make developers effective.

If I need peace for coding (and can afford it) I found that delegating client communication to non-technical project managers and even beta testers (who are much better with distractions than programmers).

Domchi