To discuss this topic in a blog type format is damn near useless, but I'll respond anyway. First, let me state that my comments are from the viewpoint of a "developer" of almost 9 years. I've never been a lead, nor do I have plans to be a lead/manager in the near future. It was Ralph W. Emerson who said, "The man who knows how will always have a job. The man who also knows why will always be his boss."
1) More experience != more knowledge, in the realm of developers. Just because someone has the title of "Senior Software Engineer", it doesn't necessarily mean they are good at software development. More often then not, it just means they might have some select useful business knowledge. I have seen this be a problem at multiple jobs. The people acting as "project leads" don't even understand the technologies they are leading, let alone the future direction of those technologies.
2) Every job I’ve ever had included coffee for free. I've never met many leads that like to talk, in fact, most have approximately zero people skills. (not that I confess to have any either). Leads that like to talk are called managers, and managers typically have no useful technical information at all.
4) It's been probably 5 or more years since I've been out for a co-worker "happy hour". I went out to lunch with a few people on the first day of my new job and it was the most awkward situation I've been in for quite awhile. Developers don't socialize very well. The last thing I want to do is spend 1-2 hours after work talking about work. I'd rather be with my family or at a gym working out.
5) The whole concept of information flowing hinges on the fact that developers actually communicate. Often times they don't. In fact, a lot of times developers are only interested in one thing. Coming into work, getting through the day, and going home. I've gotten one-sentence emails from someone sitting in the cube next to me, as opposed to actually talking.
Had to take a break to eat dinner. Even if I had an actual train of thought going here, it's long gone. I guess the last thing to say is that in general, it seems a lot of your points are valid for a very large organization. I've never experienced that, so I have no point of reference. In addition, a lot of what you talk about here seems to infer that you think most developers know how to talk, the concepts of information sharing, and in general, have good people skills. It's been my experience that the majority do not.
Lastly, you also seem to assume that everyone has the same level of passion about technology that you do. That is also often not the case. A lot of people just want to get through the work day, collect their pay check and go home. And I’m not talking just the “low-level programmer”. I’m talking all the way up to seniors, to leads, to managers and more.
Anyway, this response likely made little to no sense, but there ya go!
6:06 PM
A coworker (further up the corporate chain than me) emailed me a statement/question today noting that some of her developers were feeling isolated from the rest of the company because their project didn't intertwingle (courtesy of Peter Morville - see my post on Ambient Findability) with other projects at the company, particularly outside their department, so they were feeling sort of on their own and isolated. I think this coworker asked me because I've never really seemed to have that problem. If someone has technology or theory, and I can figure out how to get them alone for a few minutes, then I can figure out how to insert myself into at least enough of a discussion to learn the outline of what it is they have and how I might apply it to what I'm doing, now, or in the foggy future. If it's of no use to me whatsoever, then I file it away until such time as I can give it to someone who can use it. It's not trading, it's not networking for the sake of networking or promotion, I just really like talking technology when someone gives me a chance, and I'm very aware that there are a million things I don't know, and any single one of them is likely to make what I'm working on better, or give me a foot in the door at some point to find that piece of information that makes my project and/or code better, or at least more interesting. And that piece of knowledge may be code, or it may be domain-related. To that end, I always try to make myself available to other programmers and coworkers if they can use what I know, even if it means a little bit of extra time beyond my normal 8-9, because that knowledge sharing isn't part of my current project.
So I'll post what I told the coworker, and I'm interested in what other people do if they're willing to share. I don't claim these all work, or that any of them work in all cases, and I absolutely don't claim that I do all of this in some sort of calculated manner. I'm too lazy to be calculating, which might surprise people who know my puritanical attitude to work, but in a sort of spiritual way. I don't have the time to calculate--I do things because I like people and I like tech and I like having fun. If I had to work at it, I wouldn't do it. Truth is, I like talking technology, and I like talking about technology over beer and coffee the best.
1.) Talk to someone with more experience or at a higher level (technology position wise) when you have a good question. They're not as busy as you think they are (or if they are, they'll still talk to you if they perceive you're interested and paying close attention), and most of them really like to talk about what it is they're working on, what frustrates them, and what they'd do differently if they could. They're a gold mine of information, and churn up a lot of contact names for things you might be working on. Conversely, they'll often learn something from you, particularly if you work in a group that's outside their normal stomping grounds.
2.) Apply #1 to selected tech and project leads from other groups, the ones you think are competent and laid back (even fast talkers will generally let you ask questions and get clarification, but some people will not, they just like to hear themselves talk and won't even give you a chance to steer them towards mutually useful information - stay away from them). Get 'em a cup of coffee if necessary - if your tech people are stingy, and you're the lead or manager, give them a coffee card or two and tell them it's for networking purposes and you expect them to buy two cups at a time. Ask those leads what they're working on, technologies, etc. If your people are uncomfortable "cold calling", then figure out where the corporate wikis are, read a few pages so you have some base knowledge, and then go out to coffee. Leads like to talk. They like to talk about leading they like to talk about technology. If you don't feel you have something to talk about, ask them about their favorite blogs, their favorite sites, what kinds of training they like and from where, what specific conferences, "how do I get my boss to let me go to that when s/he says there's no training budget", what works best for them. Read a book on what you think is their area of interest (like leading geeks or ambient findability) so you have information.
3.) #1 and #2 lead to more opportunities - people sharing what they have, etc. You just have to touch base now and then, not all the time, and everything keeps cycling and everyone is happy. You don't want it to become a job, or to take up all the time on your job, you want it to be those extra 15 minutes during the day, and you want it to be fun for you and for them.
4.) Make some opportunities for #1 and #2. Find a developer and invite them to coffee. Walk with them to some place they like to frequent - coffee at the other end of the building, afternoon walk, water upstairs, anything. Some developers have their own happy hours (drinking alcohol isn't a necessity, but allowing others to is - no one cares if you don't drink, that's why happy hours have appetizers and meals), and you can be certain that there are never enough people and that they're interested in a new brain. They're always happy to add a person or two that seems like a good fit (i.e. don't be irritable because you're a low-level programmer and you're not invited - sometimes leads and up meet and take information back to their group. If that's the case, create your own happy hour at a different level, and find people on the liminal of moving up that will bring down the things you need from those other areas). Send out a general request to your contacts to see if they're going to a particular tech event, or even a non-tech event if you've talked enough to identify their hobbies. Invite a group of people to lunch - if it's a big enough group, enough of them are moving between jobs over the years that it will stay fresh. You always talk shop with coworkers, it doesn't matter where you are.
5.) Per the drinking advice in #4, information flows down; follow the cohort system. If you get your leads engaged with other leads and architects and finding information, they'll generally bring it back to their best developers, who in turn will disperse the ideas to the group. While that doesn't seem like engaging your lower-level developers, it is, as long as you let them know that information is reaching them from other groups and other people in other groups. You don't have to say "Jim Smith the Architect said...", but you can say, "Information Architecture is working on this", "The Large Database group recommended this", "This other group is doing this, and their lead is really interested in this aspect of it..." If you're not specific about who it is, no foul. You've still told them that their project is reaching beyond the boundaries of the group. If any of your programmers seem to be reaching for more, you've developed a network that allows you to hook them up with someone that's a good fit and you've created an mentoring network. That's just identifying talent - flow with it.
6.) Again, ask for help. Find an infrastructure bit that needs to be improved and send someone out to canvas for what's out there. For instance, if you're not fond of your automated build process, pick someone and tell them to ask around. If you know a starting point, so much the better. What you're looking at doesn't even have to be a build process in your technology area - there's something to learn in Java from looking at a .NET build process or a Team Services installation (and vice versa). Even if it's an area where you're sure your implementation is cool beans, where it's the end all of solutions, it doesn't hurt to go ask for alternatives. Web 2.0 isn't just SOA, it's innovation and new models and a changing paradigm of how to do things - you don't learn those things without other people.
7.) Have some of your group do an interview or two. That's scary - and you could lose an employee to a different group, so that's not really one you may want to follow if you're a manager. But the individuals who interview will learn volumes about other groups and their ideas. If someone does leave, and it's on good terms, get them to report back about what they're doing. Not some surreptitious maneuver. Put a programmer on them to talk to them about what they're doing over an event or coffee or whatever. Blatant is fine - let them know you want information, it's flattering. Those first 3-6 months someone is in a new position, they're excited about what they're doing, particularly around the 3 month mark when they've gotten over the paranoia that they don't know what they're doing and they're in over their head and get a real idea of what's in front of them and how they can make a difference. Tap that energy and expose your developers to it so they can cycle it in their own position.
8.) Last one, although there are more, but I'm wearing out. Teach your developers to mingle. Not crappy mingling like in the mingling book I read which warned against work-related topical mingling, but work-related, developer-related, mingling. At work - learn to recognize the other developers by sight, even if you don't know them or work with them, and take some time to sit down with them at lunch, or say "hello" to them in the coffee line if they're alone. Ask them about REST and microformats and their current project. If you talk to 1/6 of them, you'll always know someone the other 5/6 know, so you'll have conversation fodder. If you talk to 1/12 of them, find the next 1/12 that know the first 1/12, and then you have access to the other 5/6. You have to start somewhere, it doesn't matter how small. Do the same thing at the coffee shop - the non-work coffee shop. If you see developers working on their laptops and they're not engrossed (don't interrupt - rude, and it takes an effort to snap out of code brain), talk to them about their technology focus, who they work for (not what they're working on, that can be sensitive), and offer details about yourself first so they know what the boundaries are. The more you talk to other techies, particularly the ones you're not comfortable with from your own close-knit group, the better you get.
"Networking and Mingling, Developer Style"
1 Comment -
To discuss this topic in a blog type format is damn near useless, but I'll respond anyway. First, let me state that my comments are from the viewpoint of a "developer" of almost 9 years. I've never been a lead, nor do I have plans to be a lead/manager in the near future. It was Ralph W. Emerson who said, "The man who knows how will always have a job. The man who also knows why will always be his boss."
1) More experience != more knowledge, in the realm of developers. Just because someone has the title of "Senior Software Engineer", it doesn't necessarily mean they are good at software development. More often then not, it just means they might have some select useful business knowledge. I have seen this be a problem at multiple jobs. The people acting as "project leads" don't even understand the technologies they are leading, let alone the future direction of those technologies.
2) Every job I’ve ever had included coffee for free. I've never met many leads that like to talk, in fact, most have approximately zero people skills. (not that I confess to have any either). Leads that like to talk are called managers, and managers typically have no useful technical information at all.
4) It's been probably 5 or more years since I've been out for a co-worker "happy hour". I went out to lunch with a few people on the first day of my new job and it was the most awkward situation I've been in for quite awhile. Developers don't socialize very well. The last thing I want to do is spend 1-2 hours after work talking about work. I'd rather be with my family or at a gym working out.
5) The whole concept of information flowing hinges on the fact that developers actually communicate. Often times they don't. In fact, a lot of times developers are only interested in one thing. Coming into work, getting through the day, and going home. I've gotten one-sentence emails from someone sitting in the cube next to me, as opposed to actually talking.
Had to take a break to eat dinner. Even if I had an actual train of thought going here, it's long gone. I guess the last thing to say is that in general, it seems a lot of your points are valid for a very large organization. I've never experienced that, so I have no point of reference. In addition, a lot of what you talk about here seems to infer that you think most developers know how to talk, the concepts of information sharing, and in general, have good people skills. It's been my experience that the majority do not.
Lastly, you also seem to assume that everyone has the same level of passion about technology that you do. That is also often not the case. A lot of people just want to get through the work day, collect their pay check and go home. And I’m not talking just the “low-level programmer”. I’m talking all the way up to seniors, to leads, to managers and more.
Anyway, this response likely made little to no sense, but there ya go!
6:06 PM