“A business should be run like an aquarium, where everybody can see what’s going on–what’s going in, what’s moving around, what’s coming out. That’s the only way to make sure people understand what you’re doing, and why, and have some input into deciding where you are going. Then, when the unexpected happens, they know how to react and react quickly. ”
I’ve never understood this bright line boundary between the patchwork of people that make up a technical group, and the patchwork of people that make up a business group. Presumably, the technology being developed is part of what makes the business viable; it isn’t just a bunch of people playing with text editors on company time, while the grown ups — the business folks — do everything that earns money.
It serious just seems like an artificial division to excuse the two groups for not listening to each other.
This becomes even more painful when you are one of the people who wants to be involved in whatever makes up this nebulous “business side”, and are told to go back to writing code.
My view: the business is everyone’s business, and any time you start developing bright line boundaries to either protect turf, enforce a hierarchy for its own sake, or excuse non-involvement, the least of your problems is one of your techies wanting to play with technology that seems superfluous to the untrained eye.
It reminded me a few paragraphs from an E-mail I sent to a client recently.
You have created a significant business opportunity with your accomplishments: you have happy customers, strong technology, and the demonstrated ability to close new business.
But I see the need for closer cross-functional coordination between sales, marketing, development, and customer service with clear agreement on both near term and long term strategy.
These four teams need to work together more closely to leverage your significant strengths and accomplishments. Closing new business opportunities and increasing penetration at existing customers is going to take more communication and continuous collaboration.
I think there are several things that work against effective cross-functional collaboration:
- Time pressure: trust is built over time and developing a working consensus on a course of action takes extra time until everyone is in at least rough agreement on goals, roles, and process.
- Different perspectives: software is easy to change and update; customers are much less forgiving and typically not interested in the reasons that you let them down.
- Shared improvisation requires rehearsal, and rehearsal takes even more time. But you often don’t have a second chance with a customer.
- It requires you to admit your dependency on others with fundamentally different strengths. Many founders in particular have very strong skills in at least one or two areas and can fall victim to favoring their strengths instead of taking advantage of different approaches that require other people with talents that the founders lack.
- Software is the promise of a relationship but relationships are much more ambiguous than test results, transactions, or program output. Different groups live in different world with different score keeping mechanisms.
Figuring out the right team and company scorekeeping mechanisms and building trust and shared improvisational skills all take time. But I agree with Ed Carrel that the business is everyone’s business.
See also “The Business is Everyone’s Business (Part 2)” and these related blog posts:
- “Kierkegaard on the Art of Helping Others to Understand”
The helper must first humble himself under the person he wants to help and thereby understand that to help is not to dominate but to serve, that to help is a not to be the most dominating but the most patient, that to help is a willingness for the time being to put up with being in the wrong and not understanding what the other understands.
- “Use Wikis for Team Projects”
Wikis dissolve voice and authorship. Use them where there are rewards and incentives at a team level, where a team is being held accountable for a result.
- “Three Tips for Minimizing Misunderstandings Among Co-Founders“
Trackback from your site.