Great feedback so far, everyone. Thanks, keep it up. Will. The communication point is the only one I perceive. It has to do with lack of active developer knowledge on various systems, so dev-to-dev communication - I have my system and no one else really "knows" it, certainly not like I do. It's expected to a degree, but for the hit-by-a-bus scenario. The communication point comes from the complexity of our software and our loss of ability to add features fast enough. This is a technical debt situation, especially for some of these projects. Customers are getting agitated, developers are getting frustrated. My manager thinks we need to reorganize our group, so I'm looking for pointers to see how others do it.
Projects are generally over-documented, CMMI style, so a lot of fluff and specifics, but not always something that says "here's the system, here's how it works, you are up to speed in 15 minutes." It's like we have application silos, but we should be one single silo. I like the wiki idea. We had weekly status meetings, but it end up that no one cared what the status of the other projects was. I don't care if a project I don't touch is working on a feature I've never heard of (and i'm willing to take blame if I should). Thanks for your thoughts. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Fri, Sep 2, 2011 at 12:40 PM, Wil Genovese <[email protected]> wrote: > > Nathan, > > I guess I have questions. Usually there is a reason (real or perceived) > when a manager starts making such 'threats'. The only stated reason so far > is 'communication'. > > What does he mean by communication? > Whom is he expecting the communication to be with? > Is there something other motivation? > > If it's general knowledge sharing, then start by pointing to the > documentation for each project. You have that right? if not, then he's right > to be concerned. Each project should be documented enough for a person with > no clue about the project can come in and get started. This is never fun to > do. It's something we are trying to do here at CF Webtools. We have an > internal Wiki that we upgraded and are making an effort to document each > clients site. With our developers spread around the country it's becoming > important that we do this. > > If it's communicating the projects, status, progress etc, then maybe short > meetings or status updates once a week are needed. > > IMHO some managers just need to quantify things. Provide the material he > needs so he can do that and quantify you're jobs. > > If true cross training on these projects are needed, there are valuable > tools to use. Besides documentation, tried pair programming. Take someone > that has never worked on a project, put them at the keyboard and have the > other person sit next to them and guide them along. Once each person has > enough of the basics for each project, then maybe a project updates to the > team to keep everyone informed will help. Or hey, try project swapping. > Swap projects for a week or two. > > > -- Just my random vague thoughts > > > > > > Wil Genovese > Sr. Web Application Developer/ > Systems Administrator > CF Webtools > www.cfwebtools.com > > [email protected] > www.trunkful.com > > On Sep 2, 2011, at 2:12 PM, Nathan Strutz wrote: > > > > > Hi everybody. > > > > 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. > > > > 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? > > > > nathan strutz > > [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:347198 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
