My prior employer had a company-wide MediaWiki instance along with other social/collaborative tools (blogs, forums, etc) in addition to the expected deployment of SharePoint. To help span the various notifications, an internally-developed aggregator was created to roll up the various activity feeds that are produced into a social-oriented view. At my current organization, this level of open authoring tooling is not as prevalent.
Coupled with a rollout of JIRA/Greenhopper, I introduced Confluence to help development projects with their documentation. That said, we’ve seen an explosion of grass-roots content creation and collaboration. Looking for information on this phenomenon led me to read Andrew McAfee’s Enterprise 2.0 which really addresses this subject matter well. What’s “Enterprise 2.0”? Well, check out this three minute video from the author.
If that sparked your interest, or you just have trouble falling asleep at night, check out my review of the book.
I’m continuing my push to enable & encourage further collaboration and I’d love to hear about your experiences of how collaborative tools such as wikis and blogs have made a difference in your organizations.
I came across a great quote the other day; “Give as few orders as possible. Once you’ve given orders on a subject, you must always give orders on that subject.“ Brownie points to anyone who can source that quote (hint: it is from a SciFi book).
I’m not talking about Saint Philip Neri’s (paraphrased) quote of “he who wishes to be perfectly obeyed should give few orders” which itself was directed at government and its influence on citizens. I’m talking about encouraging autonomy and responsibility by not micro-managing your team.
Working by this approach simply means to tell folks what you want done and get out of their way to allow them to find a workable solution by themselves. Many of us might think we follow this approach, but it falls apart in a hurry when someone comes back with a solution that isn’t exactly what we were thinking the implementation would be. It takes a solid leader to hold their tongue and simply ask questions that validate the solution presented actually solves the problem. If it meets the requirements and was completed within whatever constraints have been established (company standards, team’s best practices, etc) then its a job well done.
If it doesn’t meet the requirements I highly encourage you to coach your team member in such a way that they are still in control of much of their destiny and how they choose to solve the problem. Every time we tell a person how to solve a problem, we’re telling them to stop thinking on a problem like this as the official (aka “boss approved”) way to handle this particular case has been set.
I’m not just talking about what tools, patterns, frameworks, etc to use; I’m talking about how to give a coarse-grained problem to someone and letting them decompose the work effort into the needed tasks. If you have to break down the problem into discrete tasks then that person will start looking for you to break it down that way for them in the future. They’ll do this because they now feel like you want to micro-manage them in this way and they will now wait for you to give them direction on similar work in the future. Your team is not going to scale like that.
This doesn’t mean we give our teams complete autonomy. Again, there are constraints that make sense in your environment and this varies, but on the things that allow flexibility — give that flexibility back to your team members. When you eliminate the flexibility by making choices for them, then the team will stop searching for a better way and just use your way going forward. Worse yet, folks will start waiting for you to do the work you really want them to tackle and get better at.
Your team is bright and they want to help you. Give them an assignment and encourage them to tackle even tougher assignments by offering them as much flexibility as you can give and being careful to coach, not direct, them through the tough spots.
