They say the secret to a successful marriage is good communication. I’m not entirely sure who “they” are, or even the current state of their plans for world domination via a complex scheme of pulleys and hamster wheels, but on this point I’m inclined to agree. The same is true of a successful software company.
The Clique Effect
If you’ve worked at a software company that’s bigger than a couple guys working in a garage, it probably won’t be news to you that the tendency for people to form “us” and “them” peer groups didn’t get beaten out of them in High School. Welcome to Human Nature 101. Whether it’s management vs. code monkeys, developers vs. testers, full-timers vs. interns, or even that smelly guy in the end cubicle vs. everyone else, the typical software company is filled with human division. While these groups may communicate very well within themselves, communication between groups tends to be overly protective and “need to know”. Sometimes there’s a genuine need to protect strategic information, but a lot of times this comes down a form of insecurity (“I’m more important than you because I’m privy to this information and you’re not…”) and just plain comfort level (“I don’t know you or understand your job, so I won’t go out of my way to talk to you”)
The thing is that the more information people have, the better they can plan. The better they can plan, the more likely the plan is to succeed. The more likely the plan is to succeed, the better it is for business. By stifling the flow of information, we inherently hobble the ability of the company to plan and therefore succeed. When I work as an architect, I always try to understand not only the immediate requirements of a component, but also what it might need to do in the future. I don’t necessarily intend to implement any of the future functional requirements, but knowing what they might be helps me come up with a design that will allow us to easily plug that stuff in later instead of spending unnecessary time re-writing a huge chunk of code. By knowing more sooner, I can reduce risk and overhead later. The same is true for project planning, and a successful project plan needs everyone’s input.
How Do I Make This Better?
What you’ve got to remember is that the company isn’t about you succeeding, it’s about everyone succeeding. There’s no down-side to stepping outside your comfort zone and making an effort to reach across the human divide. If you help others succeed at their jobs, there’s a pretty darn good chance they’ll a) think you’re awesome and b) go out of their way to help you succeed at yours.
The next time you have a choice between emailing someone or walking downstairs to talk to them, tell yourself you probably need the exercise anyway. Heck, if you work for a software company then the chances that you do are pretty high, and I’m sure your slowly atrophying muscles will thank you for it. Start inviting other groups for lunch and get to know people. Getting to know people socially will grease the communication wheels in the work environment. If you’re having a conference call with a customer about requirements for a feature that you know Developer Dave in Sector 7-G is working on, invite him to sit in. By all means tell him to keep his mouth shut if necessary… sorry, but it’s true that most developers are terrible at talking with customers… but listening to the customer directly will help him understand the requirements better than getting the info second-hand. Without launching on another topic completely, it will also increase their personal investment and feeling of ownership in the feature… which increases morale and productivity… which further reduces risk.
The key thing to remember is that no matter what role you play in your company, you’re all part of the same team and trying to get to the same finish line. Unless you’ve been led to believe that you’re in an 80′s movie starring Patrick Dempsey or a guy named “Booger”, leave the high school politics and cliques to the cheerleaders and jocks.