Open Teams

What Can Open Source Teach You?

By Cal Evans

Originally published in php|architect magazine

Part 1: January 2011
Part 2: February 2011

Part 1: What Can Open Source Teach You? (January 2011)

Pop Quiz: How many of your developers wake up in the morning excited to work on your project? How many spend their time thinking about new solutions and creative new features to help your customers? The answer is most likely not "all of them", and that is a shame. Open source projects thrive by inspiring developers to be passionate about their work. Wouldn't it be nice if you could do the same? Let's take a 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. Better yet, you may actually have more responsibility, more input, more voice on your open source team than you do at work. You get "geek cred" and respect from your peers because it doesn't matter who you are; the only thing that matters is what you contribute to the project. You take pride in the contributions you make to the project and even list them more prominently on your resume than the work you do at your day job. You have that glow inside that every developer gets when they see a project they are working on come together and work. Your open source project gives you more day-to-day satisfaction than your day job, and you wish your day job excited you as much as your open source project. You wish you could be as engaged in your day job as you are in your open source project.

OK, back to the real world, you are a manager again; you lead a team or a project. Don't you wish you could inspire the passion for your projects that they have for the open source projects on which they work? Don't you wish your developers would get as involved with 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, managed and motivated.

The Four Principles of an Open Team

Good open source projects master four key Meta attributes that few corporate development teams seem able to grasp, let alone implement.

A Meritocracy
Transparent in decision making
Location independent and flexible on timeframes
Open Lines of Communication

The Old Way

These four Meta attributes are essential for an open source project to succeed. Without them, 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
Hierarchical in Lines of Communication

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? To have developers who are eager to be at work? To have your team members 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 they 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.

So let's take a look at the four traits in depth, first looking at the trait itself and how it plays out in an open source project, then looking at how corporate IT teams can benefit from it.

Meritocracy

Traditionally, corporate IT teams, like the corporations they support, are top-down hierarchies. Those in a position of authority, regardless of how they got there, hand down assignments to those below them. New developers have no idea how those in authority got there. This is one of the root causes of distrust of upper management and the inevitable management jokes. (Well, that and the stupid decisions they make, sometimes you just can't make this stuff up.)

Earning a Seat at the Table

Open source projects resolve this problem, but not in a way that most corporate IT departments like. In open source projects, you must earn your voice in the project by what you do; you must earn your seat at the table. Let me illustrate this with two examples.

There Once Was a Man...

In a company where I worked as the Director of IT, the CEO decided that it would be a good idea for the company internally to adopt the slogan "Over Promise and Over Deliver". He had signs printed up and posted them all over the office. (He actually got upset with me because I wouldn't post them in the developer area.) Here was the problem though: I had developers working till two or three in the morning already. We were already trying to deliver on the promises that he and the sales team had made. He had no background in software development so he had no idea the ramifications of promising a client a new feature on a given deadline without discussing it. He was out the door by six o'clock and home with his family while the development team, myself included, worked through the night. He didn't talk with the developers about his plans to over promise and what that would mean to them; and he didn't have a hand in the over deliver part.

I use this gentleman as an extreme bad example. In a Meritocracy, he would not have the power to over promise or over deliver. In a true Meritocracy, he wouldn't have any power at all because he didn't contribute to the project. He didn't earn power so he wouldn't be allowed to wield it.

In real world IT shops, of course, there will always be people who wield power without contributing to the project. As a manager or team lead, it is your job to protect your team from these people. If a decision is handed down from on-high without discussing it with the team first, then it's your job to fight it. It won't win you any friends up the corporate ladder; I can tell you that from experience. What it will do though is show your team that you are committed to the ideals of an Open Team. Even if you don't always win these battles, you have to fight them. The reward is that you earn your seat at the table. Even if you aren't contributing code, your contribution to the project will be noted. Beyond "geek cred" though, you win a happier team: a more committed team, a more productive team, an Open Team.

I need to stop here and say that I always make an exception for people who have founded companies and put it all on the line for their dreams. As we just discussed, you don't have to be a developer to earn a seat at the table. You do have to do something though. Upper management who are hired to help "take the company to the next level" have to earn a seat at the table.

Well run Open Source projects do not hand out seats at the table to anyone who asks. You have to earn them; PHP is a Meritocracy, here's a quick example.

There Once Was a Woman...

In 2007, I was in Chicago at php|tek when I met Elizabeth Marie Smith. Liz is an amazing person. A scant nine months before we met, she had started teaching herself C. She did so by taking PHP extensions in the PECL library and fixing the ones that didn't work on Windows. In PHP, you are welcome to fix anything but when you do, you have to submit a patch to someone who has karma. Those that have karma have it because they fixed something previously and someone liked what they saw.

Liz had been fixing things and submitting patches for a while. At the conference, I watched as she finally met Wez Furlong in person after having worked with him online. She told him she had a patch for an extension he originally wrote. She wanted to give it to him and have him commit it. Tired of accepting patches from her, Wez popped open his laptop, signed on, set her up an account and gave her the karma necessary to commit her own patches. Liz earned the right to participate in the project. Not only that, but she also earned a voice in future decisions regarding the language itself.

(Side Note: Liz went on to work for OmniTI, the sister company of the company for which Wez is a Director, Message Systems)

Contrast this with the way projects are handled in corporate IT teams.

In the last large team I worked on where I didn't hold a management position, projects were assigned to teams without regard to the team's desire to work on the project.
The team lead would usually be the architect, designing the big picture of the project, breaking it up into chunks and assigning them based on his or her opinion of the individual developers.
Developers wrote the code they were assigned. They had little choice with regards to how interested they were in the project or how fulfilling it was personally.

Given this methodology, is it any wonder developers long to get home where they can participate as equals in a project instead of being treated as code monkeys?

So how do you avoid this? How do you turn your corporate IT department into a Meritocracy? Find out in Part 2 of this article in next month's issue.

Part 2: Motivation Does Make a Difference (February 2011)

Part 1, in last month's issue, covered how open source projects attract developers and motivate them to write code for free. That's nice, but you are not an open source project. You have employees to keep track of, upper management to keep happy, and deadlines to meet all while accounting for the bottom line. How can you take these ideas and make them work for you in the corporate world?

Practical Meritocracy

So how do you avoid this? How do you turn your corporate IT department into a Meritocracy?

If you have multiple teams available, let the teams select which team gets the next project. It could be that you have a real interesting project coming down and all available teams want it. If so, let the teams decide which team gets it. If all else fails, at least listen to each team give a reason why they should build the project before you just hand it out as a prize.
Let your teams self-organize. Instead of assuming your team lead is the smartest man in the room, let the teams decide who will play what role. Yes, you still have to have a responsible manager assigned to the team but unless they are playing an active coding role, their job should mainly be subservient. Management should not equal powerful. Management is just that, managing the process: filling out the necessary paperwork, attending the necessary meetings when required, fetching coffee. In a Meritocracy, management is not more important than coding.

Turning your teams into Meritocracies will go against hundreds of years of management theory. However, remember: these are not factory workers, they are not interchangeable pieces. Developers are more artisan than engineer and should be treated as such. Allowing them to have a say in what projects they work on and what pieces they build will make them happier developers and in the long run, more productive developers.

Transparency

Leaders of corporate IT departments, like leaders of other departments, tend to hand down decisions that affect the lives of developers with little explanation. We showed an example of this in the Meritocracy section. These decisions range from the trivial, like corporate dress code standards, to the most complex, like layoffs. More often than not, the decision is not accompanied with an explanation of why it was made. On tough decisions like layoffs, some explanation may be given but it is almost always superficial, rarely delving into the reality for fear that giving people too much information may lead to other interpretations of the data.

Contrast that with Open Source projects: again, we will use PHP as an example. When a decision is made about PHP, regardless of the complexity or the number of people it affects or the area of PHP it involves, the decision is made in public where everyone can see not only the decision, but also the discussion that led to it.

Decisions in prominent open source projects are discussed publicly. To many, this is akin to making sausage, in that it may not be something you want to see. However, everyone who contributes can have a voice in the process. At the end of the day, a vote is taken, again in public so all can see, and the decision reached is final. This transparency in decision making helps to clear up misunderstandings and gives everyone who contributes the right to be heard, even if the vote does not go their way.

Listen to Your People

In corporations of course, this style of decision making is impractical and possibly even illegal in some instances. I am not advocating that when the next round of layoffs comes around, you open a mailing list, discuss it, and "vote someone off the island": not at all. However, before you get to the point where you need to have the next round of layoffs, why not open a mailing list on how you can operate the company more efficiently? If management is doing its job right in hiring the best and brightest it can find, why not put those brains to work on the problems facing the entire company? Encourage and reward open and honest communication, even if you don't like what is being said.

Let me stop here and issue a warning. If you do this, and you take any punitive action against someone for a post, regardless of what was said, you might as well take it down. People will participate as long as they feel safe from repercussions. If things are being said that are untrue, the list will begin to police itself. If it doesn't then maybe what is being said is true and you just don't want to face it.

The Downside to Transparency

The downside to doing this though, is that you have to be honest with your people. You can no longer smile and tell them "Everything is OK" when you know it's not. You either trust your people, in which case you tell them everything and ask them to help: or you don't trust them, in which case you've got bigger problems facing you.

Be forewarned though, if your company is in trouble financially and facing layoffs, if you lay your cards on the table and ask for help, people are going to ask the hard questions. The first one that is going to come up will be why the CEO is making 10x more than the most senior IT person? If you are going to run a transparent organization, you either have to have a valid and convincing answer or do away with the issue.

Transparency in the Big and the Small

So far we've only talked about the hard decisions, the ones that affect the entire company. How about the smaller ones? When issues like dress code and remote working come up, these are decisions your teams should make for themselves. A corporate edict, in the form of a memo, dictating that all employees must dress to a certain code, without a logical reason for that decision being made, is not going to have the effect you desire. On the other hand, a discussion on the problem you are trying to solve; say, customers visiting campus think you are slobs, may introduce better solutions to the problem. Even if the answer is eventually a campus-wide dress code, having the discussion in public vs. in a closed conference room means that everybody is heard and you will have more buy-in and less grumbling. Buy-in is good because then you don't have to enforce these decisions, they will enforce themselves.

Again, the downside of transparency is, if the reason you wanted to set a dress code is because your CEO likes to see everyone in button-down shirts, you may not get what you want. Transparency in open source teams serves a very important role in that it filters out the crud. If you propose an idea in an open forum that is obviously self-serving, you will be ignored. If you do it enough, your voice will be marginalized. In an Open Team, the same thing will happen. Since everyone can be heard and have a vote in the process, obviously bad ideas, or even ideas that do not contribute serious value to either the project or the team, will be largely ignored. Be prepared for this, it will happen.

Transparency in Projects

Finally, transparency in open source teams means that when a deadline is set for a milestone, everyone understands why the date was selected, understands their role in achieving that milestone and agrees that it is either doable within their current work/life balance or it is important enough that they are willing to put forth the extra effort to make it happen. For Open Teams, the same process must be followed. Regardless of whether you use Scrum, XP, Agile or another methodology when setting physical milestones, you have to have buy-in from your team. They must understand the reason for the deadline and agree that it is possible to hit it. Everyone on the team needs to have a voice in the discussion and a vote in whether or not to accept the deadline. The upside to this is that once committed, the team will move heaven and hell to hit the deadline. Peer pressure, team camaraderie and pride will motivate the members of the team because they were asked and they agreed on the deadline. The downside is that if the decision is not based in sound logic and technical reasoning, i.e. marketing wants to roll this new feature out next quarter, allowing your team to make the decision means that you may not get all the decisions you want. Be prepared to discuss your reasons for wanting a deadline, defend them, but then work with the team if the vote does not go your way, to find a deadline that everyone can agree on.

Transparency in open source projects gives everyone the complete picture. Decisions will still be made that are not universally accepted. However, even if a decision is made that a developer does not agree with, at least they understand why it was made. The end result is that developers not only feel that they are part of the decision, they are the decision. This involvement beyond just committing code is what fuels the passion developers have for projects.

Location Independence

Why companies feel that everyone should be in the same office is not a mystery. The technologies that make remote working feasible have only been with us for about twenty years. Even so, it is only in the past five to seven years that they have become widespread enough to be considered commodities. The fact is though, for software development teams, there is very little reason why team members have to be physically located near each other, except for the obvious one. Managers still feel that if they can't see you, you must be goofing off.

In a recent talk I gave on telecommuting I made the bold statement:

"If you manage an IT department and your team leads won't support remote working because they aren't comfortable managing remote workers, get better managers."

While that is a great line to deliver, especially in a room full of developers, there is another side to the coin that needs to be explored. If a manager is not comfortable allowing a developer to work remotely, maybe there is a reason. Could it be that the developers themselves just aren't trustworthy when it comes to managing their time? Remote working is not a right; it is a privilege, one that, if given freely, comes with a lot of responsibility. Most developers who want to work remote are so intent on being allowed to that they don't stop and think of the responsibility that comes with this privilege.

The Reasons

Beyond the issue of comfort and control though, there are some very valid reasons that all corporate IT departments consider when deciding remote working for some or all of their developers.

Ecology

I consider myself a conservationist. I believe we were given the earth to use, but we also have to take care of it; we have to find the right balance. I feel it's important to talk about this. In most cases, every developer you allow to work remotely is one less car on the road that day (assuming they are working from home). You can count that as a win whichever way you like:

Less pollution
Less oil consumed
Less need for road improvements and more roads

The ecological impact of one developer not having to drive to work is very small. If enough companies start implementing a remote working policy however, the small impact adds up to a big win for us all.

Commute-less Working

Closely tied to ecology is the fact that remote workers don't have to perform the time honored tradition of the daily commute. As touched on above, this has ecological ramifications but it also impacts the developer's happiness and well-being. The US Census Bureau estimates that in the US alone, workers spend 25 minutes commuting each way. That is almost one hour per day wasted. Remote workers don't have wasted time. They can spend that hour per day on things that they want to do instead of what amounts to an unfunded mandate to travel to work.

Happiness and Focus

As we build layer upon layer of reasons why remote working is important, closely tied to commute-less working is a developer's overall happiness. Allowing those developers who thrive in a less structured environment to work remotely contributes to their overall happiness and job satisfaction. A developer's happiness, their peace of mind, however you want to phrase it, is important: a developer who is distracted by other issues is not as productive as one who is focused. While remote working is not a guarantee of focus, it does eliminate many of the traditional distractions that office life brings with it.

Additionally, remote workers need not work from home, because they carry their projects with them wherever they go, they can work from airports, coffee shops, parks, any place that can provide adequate bandwidth and connectivity. This behavior should not be discouraged as long as productivity goals are being met. Varying the work environment is a great way to stimulate new ideas and keep projects fresh.

Health

Remote workers can better equalize their work/life balance. Keeping a good work/life balance leads to healthier developers and less burnout. Even on projects that are in an intense phase, the ability to easily step away for a moment and clear one's head can make the difference between finishing on time and not.

Economics

We discuss the most obvious reason last because it should be the last reason any company implements a remote working policy. Physical space in an office building costs money. This is money that could be better spent elsewhere. Floor space, utilities, etc. subtract from a company's bottom line needlessly. This is not to say that a remote worker is a free worker, far from it. Companies have to balance the cost savings against a few additional expenses. Companies should incorporate a "communications allowance" into any remote working policy. Take some of the cost savings realized by not having to take up as much office space and give it back to your remote workers to help them cover costs like bandwidth, additional office supplies and other miscellaneous expenses that arise from them having to supply what the company normally would. In large part, this will negate most of the cost savings you would realize. Additionally, for far-flung teams, managers should try and gather the team together once or twice a year for some "face time". In teams where most remote workers are distributed across your geographical region or even around the world, this can quickly add up and overcome the cost savings.

Responsibility

Even without the economic advantage though, building location independent teams have enough serious upsides that all corporate IT departments should, by now, have a policy regarding hiring remote workers or for allowing existing developers to work remotely.

We discussed one of the downsides earlier, the comfort level of the team manager and the responsibilities of the remote worker. In closing out this section though, it would be good to revisit the second point, developer responsibilities.

While remote working is a lifestyle choice and one that should be supported by all corporate IT departments, with it comes responsibility. Developers have to be responsible for their goals, for staying in contact with their team and team lead and most of all, responsible for the perception that they take their privilege seriously. The last one is very important. It is irresponsible for a developer to claim they are remote working while at the same time posting pictures on social networking sites that prove otherwise. The lesson is not "be careful what you post when", the lesson is "If you are lucky enough to be allowed to remote work, take it seriously." Yes, remote workers can be more flexible with their hours and that is a win for everyone. Developers have to make sure that management is aware when they are not working a normal workday. Within reason, most team leads won't care as long as the work is getting done in a timely manner.

Practical Location Independence

Using technology available today; broadband, VoIP, Instant Messaging, emails, wikis, content management systems, source code control systems and others, it is easier than ever to fling your recruiting net wide and not worry about where people are, but about what they can do. Before you take the leap though, make sure you have the systems in place to support remote workers.

Communications

Skype and Instant Messaging clients, like the open source Pidgin, are ubiquitous today. It's not a matter of finding one but of finding the right one. Work with your remote workers to select and standardize a communications platform that will support your needs. It's okay if one product doesn't support all of your needs, just make sure you select the minimum necessary and ensure that all platforms selected work on all of your supported operating systems.

Policies

Before you hire your first remote worker, consider the policies necessary to support and manage them. Do you need to offer a "communications allowance"? (hint: yes) What do they do if they need support on issues like hardware or connectivity to remote systems? Will you require them to visit the home office on a regular basis for some face time and if so, how often? All of these things and more need to be considered and written down before you start building a location independent team.

Systems

Are your Development, Testing and Staging systems accessible by your remote workers? If they are firewalled, have you made sure that your firewall client works on all supported operating systems and tested it with both static and dynamic IP addresses? Remember, location independent does not mean working from home every day, it means that where the work gets done is irrelevant. Make sure that your support team is up to speed with what you are doing and that they have the necessary tools to support your remote workers.

Open source projects rarely have the luxury of having all, or even most of their developers in the same geographic area. Most projects are world-wide and because of this have had to overcome the problems of remote developers. The problems are not insurmountable. They do, however, require attitude adjustments from both management and developers. Once corporate IT teams overcome this hurdle, they are well on their way to reaping the benefits of building Open Teams.

Open Communications

It should be obvious by now that all the points discussed so far focus on open lines of communication. You can't have a distributed, remote workforce without good lines of communication. The same goes for a transparent organization and a Meritocracy. All of these traits of good open source projects are possible because at the core of any good project, is a central nervous system of project communication lines.

Practical Open Communications

From a practical standpoint, the tools necessary to encourage open lines of communication are the same tools that good open source projects use.

Technologies Do Not Make Communities

Mailing lists, chat rooms, forums and blogs are all great tools to help build open lines of communication. They alone won't do the job though. Technologies do not build communities, people do. You, the team lead, the IT manager, the CEO, have to get involved and stay involved. You have to encourage good contributions and ignore the bad ones. You have to be the poster child for the open communication you are fostering. This may mean that you have to install the necessary clients on your smart phone to allow you to stay involved. "I'm too busy" can't be an excuse for not participating. If you don't participate, both in listening and talking, then it won't happen.

Attitude is Everything

More important than the tools though is the attitude. The concept of open lines of communication is a top-down philosophy in the best open source projects. Whether a language, a Linux distribution or an end-user tool, the founders have to be willing to allow all participants to speak equally. They also have to allow the community to police itself when it comes to new ideas and new voices. A thriving community will recognize a good idea or an intelligent new voice faster than the founders may. The same factors that come into play when Eric S. Raymond said "Many eyes make all bugs shallow," also come into play when a new idea is floated. Those actively working on the project are the best judge of a new idea and the impact it will have on a project and its schedule.

Corporate IT teams don't often enjoy the freedom of thinking up their own features and roadmaps. The importance of open lines of communication, however, is not diminished. Teams need to know why a feature is being requested and need to be free to discuss how it will be implemented and where on the roadmap the best place to implement it is. There is no better judge of the impact of a feature request than the developers working on the project. More importantly, all team members should discuss the impact and the strategy for implementing the feature request. Allowing the team to decide the how and when of implementing new feature requests allows them to stay involved in the project at a Meta level and not just as the developer.

More than the Sum of Its Pieces

The concept of open lines of communication is more than just implementing the technologies that allow your developers to hide and talk about the project. Open means open and anyone involved in the project should be able to see the conversation taking place. Whether that is upper management or the client, internal or external, the concept of open has to be one that applies equally, like the other concepts. This does not mean that everyone will or even should have a voice in all issues. Stakeholders should feel welcome to discuss the why and what of a feature request without fear of being belittled or trivialized. However, developers need to feel the same freedom to discuss the how and when about the same feature without the stakeholder overriding their concerns.

By fostering open lines of communication, and all parties learning what that means and how to properly participate, open teams can enjoy a closer relationship with their project's stakeholders. This closer relationship will pay off not only in developer attitudes but in a better built project that everyone - developers, stakeholders and IT management - are pleased with.

Conclusion

Corporate IT departments can change. They can start building open teams, and in doing so, reap several key benefits:

Better built projects
Better relationships with their stakeholders
More satisfied developers
Cost savings and thus higher ROI per team and project.

However, re-tooling an existing IT department to form open teams will not be easy. We have more than a hundred years of top-down hierarchy to tear down. Many of those in power won't want to give it up for the sake of a better department. This has to be a top-driven process. Those leading teams have to decide if your team will be an Open Team and make the necessary changes or champion those changes to management.

More importantly, each department and corporation will have to decide what the terms mean. It's easy to preach Meritocracy with little or no concern for existing team structure, HR policies and local labor laws. These concepts are not black and white end points. Each corporate IT department will have to figure them out themselves.

It's not all bleak though. You don't have to blaze any new trails to get to Open Teams. There are already hundreds of excellent open source projects out there that you can mirror. The important thing is that you see the benefit of Open Teams and start working towards making your team an Open Team today.