Communication patterns for senior developers

Question

I've been running a weekly "tech lead" meeting at our company for several months. It's become quite mundane, and more of a status update than anything else. I'm looking for ideas to make this more dynamic:

• These are the guys who I think can generate great ideas and vision
• They also have depth no one else has in a particular domain and body of code/architecture
• This is one of the few chances they have dedicated time to interact with each other, so I want to make that as productive as possible

I'm an engineer, not a manager, but it seems like a waste of talent to have these guys sitting around for an hour telling me what they did last week. To make it even more difficult, there are folks that dial in from remote locations as well. I was hoping make it something less formal, like a whiteboard discussion party, but not sure how much structure would be needed. If you've ever read "A Beautiful Mind", I'd like something akin to the afternoon tea parties they had at Princeton where they talked math on the chalk board.

Answer 1

I agree, dedicated face time should be reserved for creative input. You can get updates on progress from an emailed weekly form letter.

Some ideas:

• Do a brown-bag style presentation. Have each lead present the overall architectural approach for his/her piece of the pie, focusing on challenges and how they were addressed
• Select new/interesting/important technologies and techniques and have a subject matter expert do a presentation on how it was applied in their area
• Discuss soft-skill and peripheral issues like team management. Leave names out, but create a forum where constructive ideas can be shared on build management, project management etc.

Answer 2

Have you tried putting together an agenda and stating some expectations of what should be discussed, e.g. the architecture and what challenges are coming up rather than what was done last week in terms of tasks? Or what are the cool things they would get excited discussing? Another aspect is try to send a message before the meeting that you'd like to try changing the meeting to be more like this or that and see what kind of feedback you get as it may be that the other leads would like it to change but may not want to come forward with the changes.

Another part is how much regular interaction do you have with these other leads? If you talk to them for say 20 minutes a day then you may be able to slide in various messages about what you'd like to do with the meeting while if the interaction is more limited then this may not be a good idea.

Answer 3

I think the challenge is to keep everybody engaged. Set time aside for presentations that the tech leads can volunteer for, and let them submit subjects. Ask them to present projects that are reaching an important milestone. Use webex to do this online for the remote people. Do you need Weekly meetings, or can you do them bi-weekly? That could help, too.

Answer 4

Maybe a little friendly competition is needed. Nothing too serious, but something to provide a bit of focus. You could offer a prize for the best 5 minute presentation, awarded by a group vote. It doesn't actually matter what the presentation is about, although something techincal is probably best. Once the ice is broken you can try and drop the contest aspect and just see if the momentum carries on.

Keep the presentations short though - we did something similar once with 1 hour presentations (1 per fortnight) but the meetings overran... a lot.

Answer 5

I've found that we get the best back and forth going in these meetings when we have someone "teach" a technique. Maybe it's something new - maybe not. Sometimes we'll go through a bit of a code audit together, and we'll talk about what's good and what's bad and why some things are done the way they are.

Answer 6

1. Don't allow dial ins
2. Pick a contentious topic and have someone prepped to argue it ("We should move all our applications to ruby." "We need a common messaging framework". "PL/SQL should be banned")
3. Get a meeting room with a huge whiteboard

Answer 7

Have your developers discuss something they're passionate about.

I'd probably start by sending out an e-mail and having each developer send me back a list of three topics they want to talk about and share knowledge about. And it could be anything from techniques to tools to testing. Doesn't matter, as long as they want to talk about it and have some passion about it.

Then I'd start picking and choosing which topics and which people are going to present/talk at the next meeting. I'd be on the lookout for topics that multiple people suggest, because those may get some interesting conversations going if people have different opinions on the same topic.

But mostly, what I'd try and cultivate is a mindset of shared knowledge. I'd be looking for people who can explain to me what sort of obstacle they faced, how they overcame that challenge, what techniques/tools they used to overcome it, and if they think those techniques/tools are going to be applicable to their development environment in the future. And hopefully they have some passion about their solutions and a willingness to share that knowledge.

I'd also have them list two or three things that cause them agony/pain/frustration in their environments. What I'd be looking for here is a chance to expose common problems and headaches, and then see if anyone has already had success dealing with the same or similar issues.

Mostly though - knowledge sharing. Their has to be an understanding of what this time is about and what everyone is there for.

In a way, it's like a support group for developers.

Answer 8

Firstly I'd separate the status updates (or remove them completely if that's not what's required).

Secondly, I'm not going to give any answers, I'm going to give a load more questions.

Generally people who are good at something love to talk about themselves, what they do, their decisions and justifications and essentially the stuff that motivates them on a day to day basis. Do these guys have wiki's you can trawl to ask them relevant questions? Do you get one on one time with them to know what makes them tick? Knowing the individuals and knowing about the individuals would make the job of loosening these guys up a whole lot easier. Do they prefer a debate to a status update? If so, start a debate.

Do this in the morning or before lunch whilst people are fresh, not when they're knackered after a long week.

As these people are your stars, it is really important that you show them how much you value their time. Timebox the meetings, be extra diligent about it. Also if people are going over their problems/issues, ask what they're doing about it. Jot down quick reminders to yourself and in subsequent meetings, ask how it's going. Don't force everyone to speak.

If this meeting is a forum that you run, put on your moderator hat and take of your engineer hat. Offer no advice or contribution during the meeting. Drive the meeting agenda, keep things flowing. This is your chance to listen. Especially, bring to bear people problems or problems with the business. Leave the technical problems to the guys as they probably have that covered. Of course they can and will raise tech issues. But talk about How do you assess your staff? Is that effective? What can we do to improve knowledge of X? Should we rotate staff between our teams? Talk about the things that you find hard, not easy.

I thoroughly recommend not wasting peoples time asking them to prepare status updates or presentations on their area, etc. etc. If there is something you need to know or want to hear, ask that question. Clearly the status update is not being valuable to you. What is it you want to hear?

Hope that helps!