Skip to content

Open Teams

[UPDATE: New Slides posted, the link is below.]

Dear Reader,

Pop Quiz: How many of your developers wake up in the morning excited to work on your project? If the answer is not “all of them”, you probably need to look at how open source projects attract developers and motivate them to write code for free.

 

Put yourself in your developer’s shoes for a moment.
You are a professional developer, you work on a project all day at work but you live to get home and start working on your passion, an open source project. Suddenly, instead of slogging through the day, you are actively engaged in a project that may be much more complex than the one you are working on at work. Worse yet, you may actually have more responsibility, more input, more voice on your open source team than you do at work. You wish your day job excited you as much as your open source project. You wish you could be as engaged in it.

Ok, back to the real world, you are a manager again; you lead a team or a project. Don’t you wish, your developers could get as excited about what they do at work? Have you ever wondered why they don’t?

A good place to start is to look at how your project and team is structured. Good Open Source projects master four key meta attributes that few corporate development teams seem to be able to grasp, let alone implement.

  • A meritocracy
  • Transparent in decision making
  • Location Independent and flexible on timeframes
  • Open Lines of Communication

These four meta attributes are essential for an open source project to succeed. Without all four, most projects don’t get off the ground. However, when it comes to corporate development teams, we see an almost 180 degree turn. Corporate teams are, for the most part:

  • Top down driven
  • Opaque in decision making
  • Rigid in location and time frames
  • Hierarchal in lines of communications

Even with these meta attributes not all open source projects succeed. Implementing them in your corporate environment won’t guarantee that your next project will succeed. However, it will give you an edge that other teams don’t have. With open source projects, nobody is forced to join. Only a few very lucky people are paid to contribute to them. Developers join because they want to. Wouldn’t it be great if you could say the same about the project on which your team is working? Wouldn’t it be great to say that all your developers are there because they want to be? Have them eager to be at work? Have them blog about how great their project at work is? You can but you have to turn your project into a project they want to work on.

I guarantee you that if you can’t get your developers excited about your project, don’t get excited about your project, they will find one that excites them. Hopefully for you, it will just be an open source project.

[Update: This is the opening monologue to a presentation I did recently for MIH titled “Open Teams:What corporate IT can learn from open source projects“. (PDF warning)

This is also the talk I gave at PHP Benelux 2010.

While I get the most enthusiastic responses from developers when I present this talk, I would love to present it to management as well. If you are interested in me presenting this to your company’s IT management, drop me an email and lets make it happen.]

Until next time,
(l)(k)(bunny)
=C=

14 thoughts on “Open Teams

  1. Ah yes, that sounds all too familiar. Although I agree with the general consensus of your blogpost, I think you’re overlooking one thing though. When it comes to projects at work, there usually is a client involved. A client that wants to see results at the end of the day. That means that programming an application (at work) should be done with speed of development in mind. Of course, that doesn’t mean your day job should be a hack session, but the fastest solution is usually preferred over the most flexible solution.

    I’m busy with a few open-source projects as well (of course! After all, I’m still a developer). I feel there’s a big change in mentality, not only on the motivational side of things, but also on the implementation side. When contributing to one of the open source projects, I always go for the cleanest, leanest and most extensible solution to a problem, because there really is little time pressure. When I’d do this at my current project at work, we’d be behind schedule and the customer will not be pleased — at all.

    There’s a _very_ big difference in the targeted audience: your customer doesn’t really care if the application you wrote has the best argh-itecture in the world, it just has to work and it has to be shipped on time and in budget. Open source software is the complete opposite: the better the architecture, the more people are able to use (and possible adjust) it. The audience will rather wait for the best solution, not the quickest.

    That’s the only real difference I find in my life: I have a good boss, and good customers, so decisions are already transparent, I can work from home (after a bit of nagging) and I communicate with everyone, there’s no hierarchie, as such. Lucky me. :) I’ve found this article to be rather insightful when it comes to being a developer in the real world: http://thedailywtf.com/articles/programming-sucks!-or-at-least,-it-ought-to-.aspx

    At the end of the day, I’m still happy that I can come back tomorrow. :)

  2. @Laura,
    Coming from someone of your stature, I can’t tell you how much your praise means. Thank you!

    @berry__
    I disagree with you one one point. Whether an open source project or a commercial project for a client, internal or external, quality software takes as long as it takes. You can rush it but only at the cost of quality. Investing in top notch developers can significantly reduce the time it takes to create it but even then, a deadline set without the involvement of the team is a pipe dream. Yes, you can push your team hard and hit it, but for how long? Even now, with the economy in the tank, good PHP developers are still in demand. Keep them interested, keep them passionate about the projects you have for them or someone else will.

    @Ivo! :)
    [Disclaimer: Ivo is the CTO for Ibuildings, my current employer. So you’ll understand if I disagree with him less. :) ]
    I think the entire Open teams post and talk shows one of my biases when hiring developers. With very few exceptions, I look for developers who have side projects. Those are the developers you want because they write code because they want to, not because it’s a job. So yes, while many developers (i disagree with your 90%, I personally think it’s more like 50%) don’t go home and write more code, a lot of us do. It is those developers that I am talking about in this post.

    Yes, I believe your supposition is correct, however in larger teams, it quickly breaks down because management is usually not interested in investing the time that it takes to find out what motivates their current team. I had one boss who decided that money was the ultimate motivator. he “put a bucket of money on the table” and said, if you finish by X date, the team can split this. (It was a significant amount) He did not understand what motivated the team. He also didn’t understand that his tactic was demoralizing because the team knew there was no way that the milestone could be hit. I however, take responsibility for that because in this particular case, I had given management the false hope that it could be hit.

    If IT management is willing to put forth the effort to find out what motivates their teams and individual developers then yes, developers who don’t code for fun be motivated as well. So far in my career, I’ve had two bosses who put forth that much effort.

    =C=

  3. I think the ‘developers that go home to work on open source projects’ are generally the more motivated developers in the first place, but not the most common type of developer.

    About 90% (my guess, based on observations) of the developers go home to do non-programming things. I’m wondering if based on your above observations, something similar can be done to motivate those develoeprs? If ‘developers-with-a-passion-for-open-source’ can be motivated by ‘applying-open-source-principles-in-projects’, would there be a generalization possible into ‘developers-with-a-passion-for-x’ can be motivated by ‘applying-x-principles-to-projects’ ?

  4. I have to agree with Ivo. In my case I have to say 60% of my co-developers go home and do nothing. Actually that 60% is usually the same group that complains when a change in methodology is introduced. Point to new procedures as a waste of time and question the skills of the developers who put these new procedures on the table. A couple have requested some sort of pay or bonus if they attend a User Group meeting.

    Now in the 40% group there are those who have no time and have kids to take care of but they usually spend their free time “enhancing their worth” by learning new skills that they try to introduce to their projects at work. The rest of them try to be as active as possible in the community (OS Projects, IRC, Forums, User Groups).

    The 60% has a higher turnover rate except for a few who seem to have entrenched themselves in the company. When the 40% group does have a turnover the entire company seems to suffer for a bit until a worthy replacement is found. It usually takes 4 to 5 hires to find one good employee.

  5. @Jin,

    You touch on a whole ‘nother subject here, best practices in hiring developers. That’s an issue for another blog post. However, I will concede this point and make it when I present this talk. Remote working is not for every developer, not even for every developers that wants it. Like any other responsibility (check back next week for a post on responsibility) it is one that has to be earned.

    I have no gripe with any company that has a telecommuting policy that allows developers to earn the right, my problem is with companies that just won’t allow it at all.

    As to your 60%, my only advice is, assuming you are in the US or have favorable labor laws, cut them lose. You aren’t doing your company any good by employing 6 out of 10 developers that you can’t trust to get the job done when you are not watching over them. I don’t know about that language you are working in but in the PHP community, there are always developers willing to consider a better offer from a company who believes in them. Make your company a company that developers want to work at and you’ll have no problems filling 100% of your head count with developers whom you can trust.

    Thanks for the comment!

    =C=

  6. @Cal

    Thanks for the advice. I wish I had the power to let go of the 60%. I would even go for the couple of rotten apples that is ruining the rest of the bunch. I welcome any advice on hiring Web Developers (PHP); I don’t have final say in new hires but I do have an influence. Also I would like anything I can forward to my boss.

  7. @Jin,

    Most of the advice I can give on the subject is available in section 1 of “Nerd Herding“. Hiring the best is difficult but not impossible. Feel free to pass that article up the line. However, local labor laws, not withstanding, if your upper management is not willing to cull the herd without my advice, I’m not sure they will be interested in my advice.

    Your problems seem to run deeper than just a few lazy developers. Either their are things I don’t know or your management has issues to work through.

    Hiring developers is difficult. I’ve never hired an accountant or a plumber so I can’t speak for any other profession other than developers. Hiring good developers is difficult. In my last job as a hiring manager it would easily take an investment of 20 man hours per hire on a good day, more on a bad one. :) My record is not spotless, I’ve hired a few that I regret, but for the most part, the teams that I built using the methods I described went on to stay together long after I left.

    If I can do it, so can you.

    That’s the generic advice I have for you. If you are interested in more detailed advice, contact me via email cal at calevans dot com.

    Thanks again for the conversation!

    =C=

  8. Hi Cal,

    As you know, I firmly believe in having an open source (community) mentality in companies. Unfortunately financial reasons (for the biggest part) make it very hard for managers to implement this within their teams.

    Being the outsider, working as a PHP consultant, gives me the freedom to bring that open source mentality to the table to show managers and developers what they’ve been missing all this time. And this works for the most part, but it’s very depending what size your customer is.

    Up to a mid-sized company I can passionate people into open sourcify their mentality. But huge enterprises are so rusty with too many (responsible) managers, that I just do my thing to go home and contribute.

    Cal, in a perfect world this would be fact. Until we’re there, I contribute what I can.

  9. Pingback: Jose da Silva :: Why should(n't) companies embrace a telecommuting strategy.

Comments are closed.