One of the biggest problems in organizations is the notion of what constitutes fair treatment of people. Too many managers--and HR departments--think that treating people fairly requires that we treat people precisely the same way, equally.

Well, we aren't all the same people. We don't want the same things. What you want and what I want from a job are different. You might want time off to go to your children's plays. Maybe I want to take three weeks of vacation a year. You want a book allowance. I want to go to a conference. You want to be part of a team on a well-defined project. I want to be like Captain Kirk, going where no one has gone before.

We both want to work on projects, but the kind of project is different. We both want to work on teams, and the teams are different. Why would the company want to treat us the same way?

And yet, this equal treatment is something many companies strive for.

It's craziness. That's because no one has considered what we really need: fair treatment, not equal treatment.

When you start treating people fairly, instead of equally, you

• Help people discover which work challenges them.
  
• Help them learn about and achieve their career goals.
• Help people provide you feedback about what they want, not what you want

And, you start creating win-win situations at work.

So stop with the equal, and go with the fair treatment, ok?

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.

When I work with people who want to clean up their meetings, they tell me what their problems are: presentations in meetings and serial status meetings.

Ban presentations from meetings. If you have to have a presentation, send the presentation in advance. Ask people to read it in advance. At the meeting discuss the issue. That's why you have the meeting. You don't need the meeting for someone to read you slides.

But the more serious problem is serial status meetings. That's where you go around the room and ask for status. This is built into our work culture all over the world. It's a huge time-waster. If you do this now, stop. Ask yourself why you do this. You may have good reasons: you want to know what people are working on and you want other people to know what everyone else is working on.

But, that's precisely the presentation problem. If you want everyone in the group to know what each other is working on, you either have everyone email each other their status in advance of the meeting if the group is not agile, or, if you are agile, you have standup meeting every day, so you don't need a serial status meeting. That takes care of everyone else in the group.

Now, how will you know what's going on if you are the manager? You have one-on-ones with everyone in the group. You have a 15-20 minute one-on-one with each person every week or every other week, where you have a private discussion about their general progress on their work: are they happy on their projects, do they want other work, what kind of career development do they want, or what progress have they made, what issues do they have for you, what issues do you have for them? This is your opportunity as a manager to build a trusting relationship with your employee, for you and the employee to investigate communities of practice, to give and receive feedback and coaching, if necessary. One-on-ones are a valuable and underutilized management tool.

If someone else, such as your manager, conducts serial status meetings, ask for a one-on-one and give your manager feedback. "Mary Manager, you may not realize this, but when you go around the room asking for status, it's not interesting to us, it's only interesting to you. Instead of doing this at our group meetings, how about we email our status to you, and we use our group meetings to solve our problems or discuss our group mission, or only meet as a group to solve problems every other week? We can have short one-on-ones with you every week or every other week with you instead. What do you think?"

We live in a world of rapidly moving technology trends, and fast-paced consolidation. What will the data centre look like in the coming years, as we begin to deploy these new concepts? The signs are that there is plenty of room for improvement in the way that we manage our equipment and vendors are inventing ways to help us.

We have spent the past few years consolidating servers to virtualise our computing capacity. Some of us have also virtualised storage through the use of storage area networks (SANs). A few people are also starting to address data centre networking, using high-speed, lossless ethernet to run everything from fibre channel through to iSCSI, and virtualised server traffic over the same backbone.

But the real magic will happen when we begin to put all these things together. For example, storage management tools have focused largely on the management of physical units and their support of various logical unit numbers (LUNs) in the past. They haven't particularly addressed virtualised servers. Similarly, the hypervisor management software used to shunt virtual machines around hasn't been developed with storage management in mind. More often than not, administrators will buy separate tools to accomplish these tasks well. 

And then, there are the links that tie them together. Network management software focuses more on maintaining link quality, rather than acknowledging the other two pillars of the data centre environment. 

Atop all this sits the application portfolio, which is what the computing infrastructure is there to support in the first place. And yet, for the most part, the datacentre infrastructure isn't intimately aware of application performance. Just ask the datacentre manager for a service level agreement on email delivery or screen response time, and see what he says.

The consolidated data centre will change this. The idea is that all these pillars become highly aware of the others. Storage resource management software will begin to understand the data that particular computer servers need to maintain performance. Management of the virtualised servers will be tied intimately to application performance. And it will be done, ideally, in an environment where everything has been consolidated, and where inefficiencies and over-provisioning problems have been driven out of the system.

It's a nice idea. Cisco has been working on it extensively as part of its UCS initiative (and annoying server vendors in the process, by muscling into their markets). Conversely, server experts such as HP (with its acquisition of 3Com and 3PAR) and Dell (with its $1 billion acquisition of Compellent, and other purchases such as Equalogic) are muscling into the networking and storage markets. And IBM? Well, IBM has pretty much two of everything.

The reason that these vendors are growing through acquisition and fleshing out their portfolios is because they want to be able to offer all parts of the data centre portfolio to their customers, and they want to be able to integrate them effectively to add value.

Some vendors have gaps in their portfolios. Cisco's home-grown storage presence is non-existent, for example. But in such cases, they are serving the market through partnerships. Cisco and EMC have been in bed together for some time. This gives Cisco access to EMC's storage and virtualisation expertise, while EMC gets to embrace Cisco's networking prowess.

This idea of a consolidated, high-performance data centre, in which storage, servers, virtualised operating systems and applications all talk to each other over a single, standardised high-speed transport layer is utopian, but deals and partnerships such as these show that the vendors are committed to making it happen. It will take a while to emerge, especially as cash-constrained companies still reeling from the financial crisis are unwilling to rip and replace legacy equipment.

IT professionals working in these environments would do well to watch for this coming trend. It will change the required skill sets necessary to tackle administrative tasks in tomorrow's data centre. Will your CV reflect what is needed?

In Manage It! Your Guide to Modern, Pragmatic Project Management, I explained a schedule game called "We'll go faster now." That's the game where the project team thinks they can improve their speed, even though there is no data that says they can.

There's a similar management game, called "Double Your Velocity." Say a team is new to agile. They estimate they can complete 72 points in a two-week iteration. In the first iteration, they complete 30. Ok, they figure out what's wrong during the retrospective, and they complete 55 points in the second iteration. They learn more about their estimation, so they estimate the stories better, and they refine what done means, so they plan for 63 points in the third iteration. They make it! They keep proceeding, and eventually, they settle in at around 67-68 points per iteration.

Now, a senior manager wants to "help" the team. I see this often masquerading as "motivation." A senior manager comes to the team, gives them a pep talk, and says, "I want to see you double your points for the next iteration." Depending on the team, they may ignore the manager, flip the manager the bird, or placate the manager by doubling their points for each estimate.

This is a management velocity game. It's a game, because management can't motivate people to do more work. Teams can see what's slowing them down, remove those obstacles and maybe they can finish more work. But this business of "motivation"? What a bunch of nonsense. (Tell us how you really feel, Johanna :-))

The real problem is when the manager thinks that the placating team has increased velocity based on his or her actions or pep talk. That's when the team might think they can go faster now, or they keep playing with their estimation points.

Velocity is personal to a team. Period. Mucking with the points does not make the work get done faster.

I meet managers all the time who they they are responsible for other people's work. "It's my job to make sure the work gets done."

Oh, boy. Those managers are wrong. Managers are responsible for:

• Creating an environment in which people can do their best work. This includes deciding which work to do now and which work to postpone or never do.
  
• Providing a system in which people can get and give feedback.
• Building capacity in the organization.

That's it. That's why I say managers manage the system.

Knowledge workers manage themselves. They learn how to break their work down into smaller tasks, so they can make progress. If people don't know how to do that, the manager or colleagues provide feedback, and someone might teach or provide coaching. But it's not the manager's job to manage the people. It's the manager's job to manage the system.

If you're a manager, think hard about the system in which your technical staff work. Are you creating an environment in which people can deliver good work? Can people give and receive feedback? Are you thinking strategically so you can build capacity in the organization?

If you're not a manager, and your manager doesn't know how to do these things, consider coaching the manager. It's likely your manager doesn't realize what his or her job is. Provide a little feedback and a little coaching.

When you think about management, remember that managers manage the system, not the people. The people manage themselves and their work. Just wanted to make that clear.

At last week's Agile conference, I spoke with a number of managers who weren't sure what their jobs were, now that their teams had moved to agile. They knew they weren't supposed to reassign people in the middle of a sprint, or even break up a team that's working together well, but they weren't sure what they were supposed to do.

Giving effective feedback, and coaching other people in how to give effective feedback is a great thing to do. Chances are quite good that few people in your organization know how to do so. In Behind Closed Doors: Secrets of Great Management, Esther and I suggest this model of feedback:

• Create an opening to deliver feedback.
• Describe the behavior or result in a way the person can hear.
• State the impact using "I" language.
• Make a request for changed behavior.

You need to create an opening so you know that the other person has time and is in the right frame of mind to hear you. A one-on-one is a great opportunity to give and receive feedback.

When you describe the behavior, avoid using labels. "You always break the build" just begs for one exception. "I noticed that you broke the build  Monday, and twice on Tuesday." People can argue with data, but it's much harder to argue with data you can measure.

When you state the impact using "I" language, you can explain the result personally. "When the build is broken, I hear about it from everyone. I suspect you do too. It's an obstacle I can't remove without you. I feel helpless, which is not a feeling I like."

When you make a request for changed behavior, you can ask to problem solve. "What would it take for you to avoid breaking the build?" Sometimes, the person you are giving feedback to doesn't realize they have an impediment that you need to resolve. One developer said, "I don't have virtual machine with the environment and I have no other machines." He went on to explain what he did have and what he needed. I hadn't realized that his build problem was really my problem to solve. Oops.

Giving effective feedback, not beating around the bush, being clear and firm, not labeling people, is the mark of a congruent team member and team manager. Learn how and you'll have a much happier team.

I was speaking and teaching last week at the PMI Regina's PDC (Professional Development Conference). I taught an estimation workshop and we had some illuminating discussions about what to do when people on your project can't estimate. We all agreed people tend to be either optimistic estimators, where they think the work will take less time, or they will be pessimistic, where they think the work will take longer. Rarely does someone change. Our discussion about what to do when someone consistently miss-estimates was the part where I saw servant leadership.

One project manager said, "I don't want to crush someone's hopes or ignore their hard work, but how do I explain that each and every assignment he's been late on and I just don't believe his estimate?" Good question.

People need feedback on their estimation, and a project manager might be able to help the person see where this estimation suffers from the same problem as the previous estimations.

That's where the servant leadership comes in. A PM who's not a servant leader will think, "Hmm, your last 5 estimates have been off by 50%. I'll add 50 %," and be done with it. But a PM who is a servant leader gives feedback and asks for a re-evaluation, "Joe, you might not know this, but your most recent 5 estimates have been under-estimated by 50%. I don't want to blindly pad your estimate. I'd like to help you learn to estimate better. Is that ok?"

If that's ok with Joe, now you have a way to help the other person learn to estimate better. I like breaking tasks into inch-pebbles (one- to two-day tasks that are either done or not done), starting with user stories, or using Delphi estimation as a way to help people learn to estimate smaller tasks and see when that work is actually complete. One guy I worked with said, "I always thought it just took a few minutes to set up a new branch. But when I tracked what I did, I realised it took me closer to an hour, by the time I was actually done and ready to start writing code and tests. Who knew?" Until he created inch-pebbles he had no idea how complex his work actually was.

Great project managers serve the project and the people on the project. They don't take estimates at face value, without understanding how the estimate came to be. But they don't autocratically change the estimate without providing feedback.

If you're a leader in the organisation, whether you're a team lead, a project manager, or a manager, think about how you can serve the project, the organisation, and the people. You'll get better results if you remember the people.

As public awareness and government agenda put pressure on companies to adopt more environmentally sound policies, opportunities for those who fancy “saving the world” are on the rise. Green technologies such as videoconferencing, virtualisation and power management are all hot topics at the moment and as adoption rates increase, demand for IT staff to maintain, run and manage these systems has risen accordingly.

Green IT has come to prominence over recent years as businesses look to cut energy costs and the need for business travel. Many organisations have already begun to implement green initiatives; with a number of larger companies even having dedicated CSR (Corporate Social Responsibility) teams to oversee the companies green goals. For the business the benefits are clear, allowing them to reduce overheads, cut carbon emissions and communicate their green status to their customers and stakeholders.

For IT professionals, the benefits are also there for the taking. As companies invest in a greener future, they need staff with the right skills and attributes to handle and oversee the smooth running of new technologies and new systems.What is also encouraging, is that the green IT market is constantly expanding, meaning a steady stream of jobs should be available in the years to come. If you are thinking of taking a fresh direction in your career, getting up-to-speed on green IT could set you on the right path to better, greener things.

You may have heard "there's no room for project managers--or any other kind of manager for that matter--in agile." Well, there is. Sort of. The role for managers and project managers is much closer to a form of servant leadership. It's certainly not command-and-control project management. Here are some ideas that may help you move closer to an agile approach for project management.

Ask the project team to explain what their deliverables are to get to the next milestone. Forget this business of assigning people tasks. The people on your team are grownups. You can treat them like grownups. You don't have to--and you shouldn't--assign them work every day. Not only should you not assign them tasks, you should ask them--as a team--to tell you what they have to do to get to the next milestone. Let them fight it out, ahem, discuss it. The more discussion, the more confidence you have in the schedule.

Use iterative or rolling wave scheduling, so you don't try to create an entire schedule before you know what's going on, or worse, once you realize the original schedule was someone's pipe dream. Once they've reached one milestone, it's time to estimate and plan to get to the next one.

Make people on the team estimate their own work, or, even better, estimate their work as a group. A group's estimates are bound to be better than an individual's, and much better than a manager's estimate. Group estimation is a form of Wideband Delphi, an estimation approach that's been around forever, and works like a champ. When people create their own estimates, they tend to track them, because their estimate is part of their deliverables.

Consider using timeboxes to help focus people on the work they have to finish now, not the work for later. Timeboxes are a time-honored approach to finishing pieces of work. Use them.

The more you move from command-and-control to guiding/steering the team, the more they will produce. And, the more you practice ideas like these, the more flexible you are as a project manager, which makes your value go way up. And, it's easier to find a job.