Nathan, I've only seen the hit-by-a-bus scenario happen once, but thankfully it was a slow moving bus and she was only bruised and only out a couple of days. Yes, it really happened.
However, the 'terminated' or 'just up and quit' scenario is more likely and I have been the person that has to handle the fallout. Simultaneously taking on the former employees project fully and training someone else to do the project that I had been doing full-time. Based on that experience I can tell you that cross training in each others projects would have helped. Status update meetings had almost no help other than I knew the other guys project existed. A setup docs explaining 'How to get setup and going' in the dev environment would have been useful. The details on the production environment would have been nice. Maybe we each should have cared a bit more about each others work during those status updates. Peer reviews would have been useful. We all like to think our code don't stink. And it might not, but I can tell you that I don't always know the best way to get something done. Peer reviews help with many aspects, such as helping each other learn more techniques. Preventing the reinvention of wheels, because the guy next to you knows how to do something you've never had to do. ----- Having just saw another post to this thread by you stating that the team is all remote, then I have to say Skype and screen sharing are great tools. Acrobat Connect is also great, you can screen share a three way conference call for free. Wil Genovese Sr. Web Application Developer/ Systems Administrator CF Webtools www.cfwebtools.com [email protected] www.trunkful.com On Sep 2, 2011, at 3:01 PM, Nathan Strutz wrote: > > 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:347202 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
