So, I'm hoping you've seen the Social Network by now. Aside from the elegant, Oscar-winning soundtrack and the superb, Aspergers-like performance from Jesse Eisenberg, it should be valuable watching for any technologist - especially those who are thinking about going maverick and launching their own startup.

One thing that came out of the movie is that building relationships, rather than database tables or system architectures, is often the hardest part for anyone trying to get ahead in technology. This is particularly true for technologists trying to turn their ideas into commercial ventures, because they need others to help them spread the word. Relationships are everything in that situation. How can you network and ask people for an 'in' if you don't already know them? 

There are a few ways to help build a community around your startup concept. Here are five tips to help get your idea from inside your head into the business world.

Use social networking

Some social networks are now emerging that can help like-minded technology entrepreneurs to leverage each other. It is possible to create or join groups on LinkedIn that serve as sub-networks of like-minded people. 

Other networks are emerging dedicated to the startup community. Fowndr is a relatively new, invitation-only network designed to connect entrepreneurs together, enabling them to share ideas and resources with each other.

Still others include StartupSpace. And then, of course, you'll find real-world entrepreneurial events via meetup.com. You can never have too many of these networks - as long as you monitor and maintain the profiles that you register, and use them effectively.

Twitter is an obvious channel, providing you keep your startup's Twitter profile focused and on-topic. Use it to point to blog posts for your startup (you have a blog, right?) and make a point of following useful and relevant Twitter users, to get yourself noticed and build up a following of your own.

Build a demo

Ideas are cheap. Execution is everything.

Have registration conversations

In west-coast self-help language, these are conversations that not only inspire your target, but which compel them to jump on board and do something to help you. It is all-to-easy to end up grovelling for someone to help you with your idea. Don't.  Instead, establish a commonality between the both of you. Find out what it is about them that interests them in your project. Explain why you're committed to your idea, and what makes you passionate about it, because without that, you won't be able to get them involved.

Ask them for exactly what you want, even if it sounds unreasonable. You'll often be surprised at the result.

Take up shared space

I'm a freelancer. I love working in coffee shops, people watching, and soaking up the atmosphere over a latte and a laptop. However, the thing about working on your own is that it makes relationship building rather difficult. 

Look for shared working spaces - telecottages, startup hubs, call them what you will. One that I'm considering taking space at here in Vancouver is The Network Hub, but similar spaces are cropping up in various cities. The advantage of these places is that they give you a healthy collection of like-minded individuals, with skills in areas that you'll need help with. Want a designer for your logo? A copywriter for your web site, or a coder to help you get your tech startup off the ground? These places have a habit of harbouring all these folks in one spot. It's like a social network in its original, physical form, that often ends up with a night at the pub.

Give your project away

This is perhaps the hardest thing for entrepreneurs to do. After all, your project is your baby, right? Sharing ownership with others feels like giving away your secrets, and letting others benefit from your hard labour. But there is such a thing as entrepreneurial karma; give something away, and it will come back to you seven-fold. By sharing your project with others and giving them ownership, you'll receive investment in time, money, and active participation. They will be more inclined to contribute their skills, and to bring other contacts in who will help to grow your community.

Follow these basic steps and you'll find yourself further along the road to success. As an entrepreneur currently building up a community for my own project, I can attest to their value.

I recently spoke with a Scrum Master of a team of 10 people. He is struggling, as is the team. They are having trouble connecting as a team. They are ok when they work as smaller sub-teams, but not as a team of 10. Well, that's not entirely surprising. There's research backed up by data to explain why.

I've observed over the years that teams of larger than 9 people didn't have what I call the "intimacy" of teams 9 people or smaller. Teams of 3 people or smaller didn't always have the ideas needed, but teams larger than 9 people lost something that was common to smaller teams--an ability to easily communicate with each other. There is a reason for that: the number of  communication paths in the team.

The number of communication paths in the team do not increase linearly as the team size increases;  team communication paths square when the team increases linearly. Here is the calculation where N is the number of people on the team: Communication Paths=(N*N-N)/2. That means you have these communication paths for these team sizes:

4 people, (16-4)/2=6
5 people, (25-5)/2=10
6 people, (36-6)/2=15
7 people, (49-7)/2=21
8 people, (56-8)/2=24
9 people, (81-9)/2=36
10 people (100-10)/2=45

That means the number of paths for up to 8 people is still manageable (24), but once you get to 9 people, it becomes 36 paths, which is high. For 10 people, the number of paths is 45, which is unmanageable for most of us. Can some people manage this number of communication paths? Sure. But not many of us, which is the problem. That's why "teams" of 10 people don't work.

If you have a group of 10 people, they will naturally divide into smaller sub-teams of people who can work together. They will not divide themselves evenly, as 5 and 5. Oh no, that would make life too easy. If you are very lucky, they will divide by features. If you are not lucky, they will divide by architecture or by function, or even worse, by clique.

So what does that mean you should do if you have a large team? Here are some ideas:

1. Organize by feature. If you have a feature team that's relatively small, as in fewer than 10 people, great. Keep the team that size and stop worrying. You're done.
   
2. If you have already organized by feature and the team is still larger than 9, first see if you have enough people on the team. Do you have enough testers, BAs, product owners, writers, whatever you need? If not, determine what you need. I often see that teams on the verge of becoming programs (collections of projects) do not realize they have to scale, and are trying to "make do" with who they have, which doesn't work at all.
3. Once you have enough people, and you've organized by feature, now, ask the people to organize the way that makes sense so that they can get the work done. Do not tell them, "Every team deserves 1.35 testers," because that's how you can divide the testers up. That doesn't make sense. Ask the teams to discuss it and let you know what they need and what does and does not make sense. They will let you know.

If you have a small team, a team of 3 or fewer people, watch out for insufficient ideas to solve the problems. That doesn't always happen, but it sometimes does. Too few people can be just as bad--although differently bad--than too many people. Team size matters.

I was interested to read Martin Fowler's piece on Cross Platform Mobile. Fowler is Chief Scientist at ThoughtWorks, which does software development and IT consultancy:

I think cross-platform mobile toolkits are a dead-end. It's just too hard for them to really mimic the native experience. If it's worth building a native app, it's worth building it properly, including an individual experience design for that platform.

I do not altogether agree, though he makes a good case and I accept that there are significant obstacles to success. I recommend his piece; all the issues he mentions are real and considerable.

On the other hand, I see it more in terms of acceptable compromises than a binary choice. An Aston Martin is better than a Ford, but a Ford will get me to work and costs less.

The question then becomes: how much compromise do you have to accept if you build a cross-platform mobile app?

Another issue: Fowler says web apps are a capable alternative route, but he adds:

When you do the web app, don't try to make it look and feel like a native app - make it look like a mobile web app

It sounds like good advice; but is there a UI standard for mobile web apps? I am also not sure what this advice means if you wrap a web app as a mobile app using a tool like PhoneGap. Even if you do not want to do this, it may be necessary in order to get access to more native features of the device. Should such an app aim to look more like a web app, or a native app, or is the whole idea a mistake?

Another tricky problem is that with multiple form factors, it is not clear when to apply mobile standards and when to apply desktop and laptop standards. An Apple iPad is a mobile device, but its screen resolution is 1024x768, which is pretty much a full size screen.

There is also a cost involved in not doing cross-platform development. If you only need to support, say, Apple iOS, then fine, get stuck into Xcode 4 and Objective C in the Apple-approved manner. If you need to support more than one platform though, the case is more difficult. Creating an "individual experience design" for each platform means that you have two code bases to maintain, and ensuring parity of features and fixing bugs in both become issues. Multiply the platforms, and it gets worse.

Adobe's Creative Suite is an interesting case. It works on both Mac and Windows, but the UI is more tilted towards consistency between the two versions, rather than looking native to each platform. Dreamweaver CS5.5, for example, looks nothing like a standard Windows application, with its buttons in the top frame of the main window.

However, I would rather have that, than what Microsoft has done with Office on Mac and Windows. The UI is different, the release cycle is different, the features are different, and in general I find it a better experience on Windows than on the Mac, whereas I am equally happy with Creative Suite on either platform.

My guess is that Adobe, with its own internal cross-platform tools, succeeds in sharing more code between the two than Microsoft manages, which is why it is able to deliver synchronised releases. It has tilted the balance towards consistency across platforms, rather than looking native, and that is a valid compromise.

That said, I have been conducting my own experiments with cross-platform toolkits and it is not going all that well. Each toolkit has involved compromises, even with a simple app, and performance has been an issue.

I can also see that the way navigation between difference screens in your app generally works is different on iOS than on Android. Which do you choose?

Cross-platform toolkits may not be desirable then; but they may be inevitable (like death and taxes) unless you have huge resources or are willing to lock-in to a single platform.

I also believe that performance issues will reduce as devices get more powerful, and that web technologies which are common between all the main mobile platforms form a runtime that goes a long way towards solving cross-platform issues.

Does your company have a Chief Information Security Officer (CISO)? If so, what do they do? Investigating incidents is a big part of a CISO's job. Liaising with the compliance team is another. But perhaps one of the biggest challenges in creating a culture of security within an organisation involves user engagement.

Building a user engagement strategy is a long-term, holistic process for an individual. It involves building relationships with multiple levels of management inside an organisation, and effectively speaking a variety of languages, both technical, and managerial. How can you structure an engagement strategy for maximum effect?

The first step in any engagement strategy is alignment. When first joining an organisation, a CISO might spend months identifying and engaging different stakeholders to understand their needs and concerns. A CISO must understand business strategy, and identify major changes within the company, including acquisitions and moves into new markets. Financial limitations and competing initiatives within an organisation are also extremely relevant here.

An alignment process will help a CISO to target and high initiatives together. Once that he is complete, service delivery is the second key component. How can a CISO build on that foundation of alignment to create relevant services for stakeholders? Think about not only reducing costs and risks, but also adding value to the business in other ways of information security initiatives. For example, delivering the ability to use a panoply of different endpoint devices might help the business to make staff more flexible.

Credibility is the third of four engagement areas for a CISO. Producing statistics and case studies to illustrate the benefits of an effective information security campaign is important if you are to maintain the support of senior management. Nothing says 'success' like demonstrating that achieving a level of security incidents are below the average your industry.

Finally, engagement involves using those around you, and giving up some of the ownership of the project. This is just as true in information security as in other organisational areas. Assuming that you are the smartest person in the room will make you the dumbest. Deferring to experts in a particular field may end up making your project stronger - but you have to identify those key players first, and understand what makes them tick.

Clearly, then, a CISO more than just a technologist or a bean counter. To succeed in this field, you must be a strong, well rounded individual with a robust technical and organisational discipline. No wonder that good CISOs are so rare.