> I have a little management-type dilemma that I can't solve. I'm no manager,
> so I'm trying to collect info about how other people do it.

Actually, no, you're a manager (whether you like it or not!) Sorry about that.

> I work in a small group of CF developers (7 of us) inside a big company
> (100k+ of us). The way we work is that pretty much everybody owns one or
> more applications in our group's portfolio of programs (probably 10 apps, 3
> or 4 are big & important). My manager has noticed that we don't communicate
> enough and has started threatening drastic measures, moving people around
> and putting us where we don't want to be. I am not sure of his motivation,
> but it may be partially the hit-by-a-bus protection, wondering if his apps
> will be supported if one of us eats a piece of public transportation.
>
> So my question to the list is this: How do you organize your teams of
> developers successfully? Please let me know what you do, or what you have
> seen that actually works.
>
> I'll start us off.
>
> I asked my friend Mario, who says they have a team of core developers that
> do R&D at a higher level, overseeing the technical direction of their
> applications. Those R&D projects are flowed out into application development
> teams, and then they have a lot of other developers who do front-ends and
> integration work. Regular flow-down meetings help people share ideas and
> copy & adapt similar projects.
>
> Mario's team compositon sounds awesome, but he has a lot more people than I
> do. What do you do?

Mario's approach seems a bit ... ambitious ... for your current
environment. You might try something simpler: having a second
participant on each project who participates in periodic code reviews,
for example. This is something that could be scheduled to occur once a
week, and the owner could brief the second participant on the changes
made that week, and that participant could review them and ask
questions. Of course, this will only work to the extent that they take
it seriously - there's no enforcement mechanism here to ensure that
real knowledge transfer is happening. On the other hand, you could
probably do this without much disruption of your current efforts. You
could even go a step farther and make the second participant
responsible for documentation (which would be reviewed by the owner
for accuracy and completeness).

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on
GSA Schedule, and provides the highest caliber vendor-authorized
instruction at our training centers, online, or onsite.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:347193
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm

Reply via email to