Startups face time pressure and resource scarcity, they need to cultivate effective collaboration among everyone on the team to compensate. They need to act as if the business is everyone’s business. Jack Stack’s “The Great Game of Business” offers some useful models for fostering a shared understanding of the current challenges to enable effective joint action.
The Business is Everyone’s Business
“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. ”
Jack Stack “The Great Game of Business” (page 72) see also http://www.greatgame.com/
Edward Carrel left a great comment on Hacker News in response to “Project Manager’s vs. Developer’s View” this quote (the thread is here)
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.
Related Blog Posts
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“
Great article Sean.
Recently, a developer I work with sent a mail around to the (small) team that blew me away. After a glitch with an internal system he sent a mail which read: “Who’s job is it to fix this?”.
When you have someone who can’t take personal responsibility for something that falls directly within their skill set, I’d be wary of their direct involvement in the bigger picture.
Certainly, their opinion is as valid as anyone else’s. Even just ensuring that every section of the business knows what everyone else is doing works well – internal newsletters, some sort of internal social network on yammer or ning etc helps.
My feeling is that there are two types of people – one group just need to be told what to do, the other need to be given the space to develop great ideas (be they business, technical etc). Mixing these types up may be disastrous. If you have too many of the first type, it might be that your hiring process needs attention:
http://www.apeofsteel.com/1218/how-to-run-a-company-into-the-ground
Pingback: SKMurphy » The Business is Everyone’s Business (Part 2)
Pingback: SKMurphy » Quotes For Entrepreneurs – March 2010
Pingback: SKMurphy, Inc. » Five Serious Financial Mistakes Bootstrappers Can Avoid
Pingback: SKMurphy, Inc. Delegation Needed For Growth - SKMurphy, Inc.
Pingback: SKMurphy, Inc. Podcast with Pete Tormey: Bootstrapper's Delegation Checklist