private override

23Feb/094

Re: How do you stay AND grow? A commentary

This post started out as a comment to How do you stay AND grow?, but it got a little lengthy for a comment so I decided to write a post instead.

The original post, was in response to Uncle Bob's Multi-dimensional Seniority.  The following is my response to Daniel:

I think the metaphor of apprentice -> journeyman -> craftsman breaks down a bit when we get to talking about the fact that each is "mentored" under only one.  While that is true in the skilled trades world (and mostly holds true in the software world as well, as far as technical mentoring), the software world is so much more than technical talent and ability.  I'm sure you've read Peopleware, and are familiar with this idea.  That being said, getting exposed to lots of different people over various organizations will up your game in the arena of interpersonal relations (I know it has for me).  Now, I'm not saying you can't also grow these skills from within a company (I know I certainly did at my previous employer/Daniel's employer, more than I ever knew myself to be capable), but now that I'm with a totally different set of folks, I'm learning totally different skills, which I don't think would've ever happened had I not changed companies.  However, I'd be willing to bet with a sufficiently heterogeneous set of technical teams in a given company, you would be able to achieve the same result.  Technical teams will not only differ based on their preferred technology stacks, but each stack usually draws a unique set of interpersonal skills as well (e.g. "The Ruby Community is so helpful and nice to noobs like me!" or "The Java Group are a bunch of haters, and are too good to answer silly beginner questions").

To answer the question of

Can a company foster an environment where its developers get exposed to different technologies, development environments, languages, etc. so they don’t have to leave the company to do that?

I like what Google has done to infuse this learning and growing with their 20% time.  20% time is ALOT of time dedicated solely to learning/growing, but I'll bet you spend about that much time now, or at least somewhere between 10 and 20.  We also have a program to take classes at work (real homework, real projects - just like school), taught by your colleagues.  Almost invariably, the classes are on technologies/languages that we don't currently use in production.

The last question Daniel poses is interesting.

If a company desperately wanted to do whatever it needed to to keep their developers growing without having to leave the company, what would that company need to do?

I doubt you'll find many, if any even, companies whose goal is to do whatever it takes to keep their developers growing and not leaving.  As much as I love the idea of software craftsmanship, I can't imagine myself being the owner of a software shop, and having that be my primary goal.  Possibly, I suppose, because I have no problem with packing up and leaving when something better comes along.  Don't get me wrong, I have company loyalty, but a number of things usurp that (in my book)... have you read Who Moved My Cheese?

Maybe my real question is why do you (read: y'all) need to stay?

Comments (4) Trackbacks (0)
  1. Interesting thoughts.

    If someone offered me a million dollars a year to be a COBOL programmer, I would probably sell out for a year or two. :) On the other hand, I might take a pay cut if working with cutting edge technologies or in a team position (leadership) that I thought were going to substantially improve my career. Odds are good though that if you are smart enough to work with the technologies or skilled enough to work well with a team, you won’t need to take a pay cut, unless you take your initial inexperience due to learning being the penalty.

    I believe in the long run most people are evaluating opportunities and estimating what their expected value of doing these are and trying to maximize these values. Sure, you take a knowledge hit with working with ancient COBOL codebases or something, so you need to hedge this opportunity cost with more money up front (since presumably what you are learning will be worth less in the future.)

    I’m assuming, of course, that family structure and such are not an issue and that it’s fairly easy to change jobs and that the person is not risk-averse. I think that’s what WMMC was about — realizing that change is good because continually doing the same thing is more risky.

    My perception of the 20% time is that Google employees are working on projects that Google owns when they get done with them. Then they get bonuses based on the value of these projects. Plus there’s the satisfaction of knowing that you made a sweet project.

    So I guess my answer would be that you either pay higher for developers because they are less efficient with using older technologies and they need some reason to stay because they are less happy (the good ones might not anyway) or you foster a culture of learning, which from the developer’s and company’s perspective seems to be a win-win.

    Thanks for the post!

  2. There are other aspects: A desire to change jobs from time to time implies the need to either change communities, add a commute, or telecommute; or that you choose a city large enough to provide multiple options (did I miss a possibility?)

    Why would you not do one of those… It could be a matter of personal priorities – if someone values a smaller town, doesn’t want the commuter lifestyle, wants to root down into a place rather than go place to place… you see how that would be a motivation to ask “Can I stay and grow?”

    In my post I asked with a defensive tone: “Does staying have to be bad?” I think now I would expand on that and say, what advantages can staying put have for an individual? As a starter idea, I wonder if there’s a kind of industry leadership presence you can attain that way… This line of thought may not excite my techno-nomad (endearing term : ) friends, but I think it’s worth asking.

    Thanks for the post!
    -Daniel-

  3. One thing my company does that I’ve really come to love (it wasn’t hard) is ‘Friday Time’. We take a break from doing normal task work and use the time for research or technical tasks. This gives us time to experiement with new technologies, refactor existing code and find other things that might help us work better. To check that we are using this time effectively we have technology related goals. Basicly, research a technology, use it in one of our products if it good and present back to the group on the technology. For example, I did a couple small Silverlight projects, WCF and Autofac. We aren’t currently using Silverlight, but we are using WCF and starting to use Autofac.

    It does take a good deal of time, but I think in the long run, it’s worth it.

  4. In Up or Out: Solving the IT Turnover Crisis, Alex Papadimoulis argues that people leaving is inevitable, and that it would be healthier for everyone to bake this assumption into their activities.

    One commenter claims that IT employee goals don’t fundamentally coincide with company goals in the way that happens with lawyers and sales professionals, and thus IT staff should naturally expect working relationships to only last as long as there is a happy overlap.


Leave a comment


No trackbacks yet.