How Communication and Selectivity Influence Your Programming Culture

This is the fourth post in a five-part series (check out Part 1, Part 2 and Part 3) where I’ve been examining what it takes for a software programming or development organization to cultivate the right kind of company culture.

As I’ve said previously, creating the proper culture is crucial for success in this industry. But doing so is also no mean feat; a surprising number of pieces must be assembled in order to complete the culture puzzle.

Hopefully, by looking at the constituent components of a successful culture, we can gain a better understanding of how they’re formed and implement them in our organizations. For this post, I’d like to discuss the elements of communication, empowerment and employee selectivity.

Communication

An emphasis on communication is vital, and it has to be encouraged at all levels: among virtual teams, among distributive teams, within management. All sorts of things can be done to help facilitate communication. For instance, although it can be a challenge at a distance, it is critical to establish a regular framework for meetings — a daily standup or a weekly status report, say, or at the very least quarterly meetings between team members so that collaboration can be accomplished.

In fact, teamwork and collaboration are absolutely vital. They encourage innovation, they help promote interpersonal benefits like fairness and mutual respect within the organization, and, yes, they definitely improve communication. There are various ways to foster this type of environment, but one of the most obvious (and perhaps overlooked) is for managers to reward teamwork over heroism.

You know what I mean by heroism: The hard-working programmer who sleeps in his or her cubicle, misses holiday get-togethers, basically becomes assimilated into the company like some kind of occupational Borg — all to nobly get that one project feature completed. It’s not at all uncommon in the programming world, and in fact I’ve been there several times myself.

Now, mind you, I’m not saying that employees shouldn’t work hard. What I am saying, though, is that there’s a difference between working hard and pretending to carry the company on your shoulders. When I think about one company where I was missing holidays and generally being a martyr employee, what was definitely missing there was a culture of teamwork. People were arguing all the time, there were personality issues between people. It was very divisive — not a very fun place to work. In contrast, if there's open communication, then people feel comfortable in sharing and working together, goals are better defined, and there’s less chance workers will feel they have to play the role of the hero.

One last thing: How communication is promoted within a company will inevitably be influenced by the culture of its workers. The breadth of this is way beyond the scope of this post, but if you’re curious about how cultures can influence communication, my post “The 7 Ways an Indian Programmer Says ‘No’” will give you an idea of some of the considerations involved.

Empowerment

A lot of what goes into empowerment is simply trust — trusting team members to independently do the things that would be expected of professional programmers at that level. At the same time, you also need to verify quotas or establish other means of ensuring that the work is getting done and goals are being met.

Because of these two competing interests, fostering empowerment can be a bit of a balancing act. Probably the most important takeaway lesson is this: Don’t micromanage. Besides inhibiting employee development (and leading managers to run themselves ragged), micromanaging can actually deter a company’s productivity and efficiency. (For a real-life illustration of this in action, see my post “PresidentWare — When Leading By Example Goes Too Far.”)

Selectivity

I actually wasn’t sure what to call this element. By “selectivity” I mean, “Don’t hire jerks or bozos.” Somehow, though, I don’t think you’ll find a “jerks and bozos” chapter in any HR manual. But you get the idea. And let’s face it — we’ve all encountered these people before.

I once worked with a guy who was a jerk, and he basically did nothing to enhance the culture or working environment of the organization — in fact, he made it worse. He was loud, he was a blowhard, he liked to tell you what to do, he’d make inappropriate comments … and the thing of it is, I realized all of his jerk behavior was just sort of a defense mechanism to project authority, because he didn’t know what he was talking about. Regardless, he was insufferable, and the worst part about it was that the CEO there didn’t want to do anything about it.

Don’t make that mistake. Jerks and bozos can’t be tolerated within your organization. They’re distracting, they take away from the productivity and shared goals of a group, and they can be toxic to a company’s culture. Send out the clowns.

And on that greasepaint-tinged note, I’ll bring this post to a close. Next up, our examination of the components of a successful programming culture will be brought to a conclusion as we discuss excellence, focus and environment. Stay tuned.

Click to read part 5