Friday, May 16, 2008
TED: Secrets of success in 8 words, 3 minutes
Richard St. John has a nice little talk featured on TED where he talks about the secrets of success. He interviewed several members of TED and came up with the following list of features:
- Passion, love for what you do
- Work hard and have fun
- Push Yourself
- Persistence, through C.R.A.P.
Crap stands for Criticism, Rejection, Assholes and Pressure.
Never knew they could say words like that and publish them.
Sunday, April 27, 2008
I Need a Good SharePoint Admin. What should I be looking for?
"SharePoint represents the first true class of products by Microsoft that completely blurs the line of Admin and Developer. [...] So when asked, by my customers how and what should I be looking for in an finding an administrator for SharePoint, my response is always STOP looking for an administrator and start searching for the NEXT GENERATION IT STAR that can code and administer your solution."
According to Technical Account Manager Gregory MacBeth from Microsoft.
Good to see more and more people are getting it.
Monday, April 07, 2008
Splitting TechEd US into two weeks stinks for SharePoint professionals
Andrew Connell, a MVP on MOSS, is not pleased with splitting TechEd into two weeks: "The problem I have with it is that you go to one of these major conferences, as an attendee, to get good exposure across the board. ...professionally I think it's a bad idea to separate the two because it almost tells devs/admins they don't need to know about the other's world. In some apps this might be true (for instance, I [possibly incorrectly] consider Exchange more in the admin/IT pro camp than I do in the dev camp), but for SharePoint it isn't. Even if you are a dev like me, you need to be aware of some concepts and how they work such as site collections and splitting up content databases or how admins view CAS and such. Admins need to understand how developers utilize CAS and deploy custom code."
I totally agree with him. Developers and IT Professionals should be working with each other. Especially with products like Sharepoint. There will always be a cross-over, and widening the gap is not the answer.
Besides going to the usual IT Pro events I also attend more development-centric events like MSDN Intracks and the upcoming DevDays, scheduled in May, including the Geek Night! I wonder if there will be someone from the team Coding4Fun, would like to have a chat with them. Anyone else going as well? Give me a ping!
Wednesday, March 26, 2008
It's Always Your Fault
Jeff Atwood has a great article, called: The First Rule of Programming: It's Always Your Fault.
An excerpt: "You know the feeling. It's happened to all of us at some point: you've pored over the code a dozen times and still can't find a problem with it. But there's some bug or error you can't seem to get rid of. There just has to be something wrong with the machine you're coding on, with the operating system you're running under, with the tools and libraries you're using. There just has to be!"
It is far more likely that something you built is causing the error than, say, the OS, hardware or Network: "of total errors reported, roughly 95% are caused by programmers"
I can't count the number of times I had to deal with resistance to take ownership or cooperate. No, it wasn't the codebase, there has to be something wrong with the system or the network. Even when faced with cold, hard data to prove otherwise. Or, the other way around: no, our network and systems are sized just fine, the application is causing all the issues! They are at fault, not us.
The way I usually deal with these kind of issues is to get everybody together in one room and break down the boundary. This is an issue we have to solve together. After all, what are we really talking about here? This is not about who's at fault here, this is not about personal abilities. This is about a technical issue. Heck, it might even be because of some weird interaction between the network configuration and the code for all we know. Who knows? Hmm... couldn't that be the case?
Once the defenses are down, people are focusing on the issue and willing to work together to solve it, we can really get down to business. And call for pizza of course!
Tuesday, March 04, 2008
Being a Gentleman in Business
Differences should always be solved with the best interest of the client in mind. This will ensure a good relationship with your client from which both of you will benefit. It is often that I see people or companies struggling and fighting however. Fighting to keep the client which they tend to see as solely theirs, obstinately refraining their employees from transferring to the client and putting their feet in the sand in spite of sound judgement which should be telling them otherwise.
And you know what?
It is okay to defend your hard earned rights and that which you have worked hard for to let grow and flourish. It is okay to not let other people willfully take advantage of that what you have created. It is okay to keep people to their end of the bargain, promise or obligation! But... does this include hanging on to agreements which will end up hurting everybody, including yourself? Blindly clinging on to that -what you perceive to be- opportunity which you alone have seized and is by birthright now solely you and yours alone? The client you're squeezing every penny out of because it is your belief that he or she is yours alone for the taking? The employee who you helped to blossom and now whishes to go over to The Dark Side, leaving you alone in the cold?
Well, wake up and smell the coffee!
The client who needed your guidance has grown up and is ready for their next step. They don't need you anymore. And your employee, once a fledgling and now a fully grown soaring eagle, has found a better working environment: the client he or she currently works for. So what do you do?
- We're in it together. You recognize the fact that everything changes over time. You sit down with the client and try to find a solution from which you both will benefit the most. You nullify the contract with the client and even help them get everything adjusted. And after talking with your employee you find out that they really like working there and that he/she will get paid more. You suggest a settlement with the client.
- Me! You cry:"foul play!!" and think to yourself: this is rightfully mine! So you heed the client to the contract and threaten with legal prosecution if they don't execute their part of the contract. Sure, there is always a way out, but it will cost them. Dearly. After all, this is your money they are talking about! Apply same scenario for your employee.
Now, what will you choose?
Sadly, I've seen it more often than not that #2 is chosen. This is so bad. For a number of reasons. A sample:
IT is a small world and you will run into the other parties again. What if you need them? What if you depend on them? Will they refer other parties to you? Will the client hire you again?
- With power comes responsibility.
A lot of power and trust is invested in you, both by the client and your employees. Think carefully how you will use this power and trust. For the better good for everybody, or only for your own good? To use a metaphor: what will get you more friends in the playground: if you look out for one another or if you keep all the sweets to yourself? What will make you a better manager? To keep a good balance between all forces involved, or to relentlessly pursue your own goals, without listening?
- Team spirit.
Most of the time you will be involved with some kind of team. Perhaps your own team or a project team. How will your actions reflect on your team?
Luckily I've also witnessed some very applaudable behavior from several people and companies. And if you ask around, those companies and people will end up with a more stable base of loyal customers and employees. True, this approach can cost you some in the short run. But it will pay off in the long run. And you'll also sleep better at night.
Addendum: Wharton University's Business Journal has a good read on the subject: "In the Game of Business, Playing Fair Can Actually Lead to Greater Profits", where the paragraph title 'Fairness over Profit Maximization' sums it up rather nicely.
Saturday, April 16, 2005
Juggling with three Sharepoint projects, switching to another team, being headhunted for the position of Product Consultant within an international company while I am still in the process of negotiating my current transfer; who said IT was boring?
The position of Product Consultant has left me pondering the following question:
"What is the definition of a Consultant?"
After consulting (...) a few of my superiors I came back with a wide array of answers. I wasn't satisfied with the answers I got. And I have gotten the suspicion that I won't get a good answer either.
My Definition of a Consultant
In my (limited) opinion a 'good' Consultant should have at least the following skillset and be knowledgeable in the following area's:
- Know Technology
Whatever the area of expertise, whenever we are talking about a techno Consultant, he or she should have a firm grasp of the technologies involved. What are the pitfalls, what are the opportunities, how to asses, use and implement it etcetera.
- Know People
Your expertise isn't going to be of any use when you aren't a people person. How else will you motivate others, how will you get 'the question behind the question', get the feel for the politics involved?
- Know Management
Knowledge of the technologies involved, coupled with interpersonal skills alone isn't enough. Management-type skills are obligatory! How else will you succeed at managing your projects, choosing which development methodology is best suited for this situation, how to get a grip with an escalation gotten out of hand?
In my opinion these three area's are obligatory for any consultant.
Subscribe to Posts [Atom]