Case for Social Networking

As a technologist, I first started using Social networks in 1993, on Compuserve (it was not called social networking then). Most technologists have a similar example, like Prodigy or The Well. I am now a regular LinkedIn user, and our technology wiki is indispensible. The benefits to my company are clearly tangible.

It is entirely possible that large companies could significantly benefit from an internal social networking tool (call it a wiki for arguments sake). But how can one explain the benefits to an executive? Its a tough sell.

While I personally believe social networking will revolutionize corporations, I'm not sure I have a sound argument and reasoning. A tool just like Myspace and Facebook for the office? Won't that mean employees wasting countless hours instead of working? What if our employees post incorrect information? Who's going to monitor it?

My argument hinges on:-
1) Wiki is more productive than email
2) Wiki information being self-correcting, like wikipedia

I believe social networking will displace email, in part, as a workplace tool. Conversations in email will move to an intranet wiki, and staff email time will be freed up to spend on a wiki growing a corporate knowledge-base. But will it? How can I prove it? Plus, it may take years for it to happen. This argument also presupposes that email in its current form is often unproductive as a workplace tool, which goes against everything we said to get email adopted in the first place.

And how can I prove that information will self-correct? Wikipedia is not like a company, so proves nothing. If executives believed in "the wisdom of crowds", then crowds would be running companies. And my prototype company examples, Google and IBM, are atypical. If anyone has a better argument that has worked at the executive level, let's hear it.

Thinking in lists

I am a prolific list maker. It's my tool for collecting tasks &/or needs and tracking them. My lists are not ToDo's, I find that too defeating and overwhelming as I try to get them all done. Instead, these lists are things I am tracking, whether they be bugs, ideas, major projects, date deliverables, meeting points (one list I have is things I want to do before I get old :-)

My list-making came from an early experience, where I wrote down bugs and feature requests/ideas on a list, using pen/paper and numbering them sequentially. I lost the first list after 680, started a new list which I used for years (and regulalrly photocopied as a backup). I stopped in the 16,000s. Now, I think in lists and will sometimes even write emails as a list.

I found the experience very empowering. It allowed me to have an open conversation with any staff/client/executive/team member and record the results, without making any commitments. It allowed me to separate the information gathering from the commitment making. And "Jon's List" began to take on mythical proportions at my company, with every sales rep wanting to take me to lunch.

Again, the key for me was not to think of these items as ToDo's. They were list items which had many different facits. And yes, I crossed them out when done, or "Z'ed" them if no action needed, but it was still not a ToDo list. I can now think beyond lists, and my lists today are much more modest in size, but it's still a critical tool for me.

Commitment to delivery

Most technology groups are cross-functional with lots of projects to deliver, and find themselves inundated with new requests, status update meetings, change requests, and the like. Given that technology teams can get very busy, its important to make sure a project will drive to conclusion.

If you want a project to stall, one sure way is to have noone on the team committed to delivery. There needs to be one person, just one, who will drive the project to conclusion as obstacles mount. Without this person, the team will sense there a lack of owner (and no reward for outcome), and shift their focus and priorities to other projects.

This is reasonable behavior, and to be expected. After all, your teams are often being asked to do too many things, and need some mechanism for prioritization. The issue is that the project may be important and beneficial, and you'll need to get someone on the team to "own" it.

Make sure all your projects have "owners" on the team, those who'll stake their reputation on getting it delivered.

Plans & People

(I'm back. My train rides have been preoccupied with Harry Potter, book 7, and I am a slow reader. With that done - no spoilers here - I can get back to blogging).

When I think about what I do as a CTO, what is most importance to me is plans and people. What! Not technology, you say? How can that be? Well, technology is a fundamental skill that any CTO needs, but the members of a CTO's team are masters of technology. CTOs do not need to be the expert technologist in the room. CTOs need to be leaders.

When I was at University, I had no concept of this. As a programmer, I still had no concept of this. As a project manager, plans suddenly seemed important. For me, the CTO realization, that its not the technology, was a slow one, but something I eventually figured out.

When prioritizing my time as a CTO, planning and people are where I put the majority of my time. Without these, there is no technology at an organization. And planning is as much an art as a science. Imagine if as a programmer you were told 3/4s of you code would be thrown away? That's what happens with planning. Yet, it crucial. Simple, but true.