Geeks With Blogs

News





The SharePoint Hillbilly Fewer Big Words... More Pretty Pictures...

So, the similarities between the tech bubble of the late 90’s and the current hiring frenzy of SharePoint people is too similar to ignore. It seems as though if you put SharePoint on your resume SOMEONE will hire you. This of course is good and bad.  Bad because people who don’t know what they are doing are creating huge messes, and good because those who know what they are doing can make more-money-than-they-are-worth cleaning up those messes.

Another artifact coming from this SharePoint Bubble is that there are many SharePoint “Go To” guys and gals out there that are getting snagged up to work in higher profile settings. You know the ones I’m talking about. They are THE person in their organization that “gets stuff done” in SharePoint. They are their company’s rock star. If something is getting done in SharePoint, it is most likely this guy or gal doing it. Very often these inter-company gurus are doing exactly what they SHOULD be doing, and capitalizing on their efforts to boost their career. They are leaving their organization, taking a nice pay increase, and diving head first into bigger and better things. 

Many times these talented people find themselves in an environment totally alien to them. They are no longer “the” expert, but are now part of a team. Many times they are moving from the corporate world to the consulting world and they find out their actions have farther reaching implications. They find themselves tripping over other people, getting frustrated that they aren’t producing as much as they’d like, and coping with greater responsibility.

Well.. fear not… things don’t have to be so frustrating. With the right attitude and work ethic these people can seamlessly integrate into a team and have a huge beneficial impact. 

Some quick tips for those of you considering such a move or who have made such a move:

Cowboy… don’t be one…

If you aren’t Eric Shupps… or if you don’t wear a cowboy hat on a daily basis, you are most likely NOT a cowboy. Stop acting like one. You are part of a team now. You are not autonomous. The actions you take impact more than just yourself. You can’t go off on your own because you have a really cool idea and not tell anyone what you are doing!  Don’t get me wrong, it’s really cool that you have the passion to go play with “x” to solve “y”.. however, if you are supposed to be working on “z” this is not a good thing!  Get your work done first so that other people not are waiting on you, then go play.

Consequences of being a cowboy:

  • Hat hair and musty cow-like smell.. oh yeah.. not that cowboy
  • Missed deadlines because you weren’t doing what you should be doing
  • Team members missed deadlines because they are waiting on you to get your work done
  • Wasted time because you decide to research something that was already researched
  • More wasted time and frustration from your bosses because you work on something that is NOT a priority

Communicate! How else will you know who to blame?

Now that you are part of a team, make sure you communicate effectively with your team. If only there was SOME tool out there that would make collaboration more accessible!!!  But seriously, let people know what you are working on. Let them know when you need help. Know what others are working on so you can help them. This is probably the biggest thing you need to learn to do is communicate effectively and LEARN to communicate with the different team members. Sometimes it can seem like everyone has their own way of communicating. 

Learn to communicate simply and succinctly. No one wants to read a 5 page email, especially one that can be summarized in two sentences.

Some consequences of not communicating well? Wow.. there’s a lot.. including:

  • Missed deadlines
  • Multiple people working on same item/issue
  • Overwriting someone else’s work
  • Work doesn’t get done because “someone else” was doing it
  • Reinventing the wheel when someone else has already done the same thing

Which bring us too…

The Wheel… don’t reinvent it…

Did I mention you are part of a team now? Take advantage of it…learn from those who came before you. Before undertaking any new task, find out what others have done. If you are coming into an established organization there are usually some standards and practices in place to address common development issues.

Consequences of reinventing the wheel:

  • Missed deadlines
  • Wasted time developing something that was already written
  • Developing something poorly that has already been written better
  • Did I mention wasting lots of time?

Directly related is…

Wheels… don’t spin them…

I already did a whole blog post on how to stop spinning your wheels… so.. you have no excuses… just don’t do it..

Stop Spinning Your Wheels… Sage Advice for Aspiring Developers

 

Consequences of spinning your wheels:

  • Missed deadlines
  • Team member’s work can’t get done
  • Wastes valuable time

Consistency… consistency… CONSISTENCY…

Your new mantra is “I’m part of a team now.. I’m part of a team now”… part of that is learning to code consistently with the rest of your team. Use the same naming conventions and code structure. DOCUMENTING these should be a priority so that everyone is on the same page.

I don’t care if you found a new cool method for doing “x”… unless there is a real benefit, don’t use it!  And if there IS a real benefit, sit down with your team and COMMUNICATE it! Many times there is a very good reason for why things are done a certain way and the method you found was not used!  Or maybe no one thought of your method and here’s your chance to teach the team something and PLAN how to implement your cool new method and make it CONSISTENT throughout the code.

Consequences for not being consistent:

  • Missed deadlines
  • Overly complicated code that other developers can’t understand
  • Introduced errors because of lack of understanding of previous methods
  • Wasted time as team members have to learn multiple ways to do the same thing

Prioritize! Learn to do it…

A crucial skill that many developers have to learn is how to prioritize their time and tasks.  Many times your tasks will get prioritized for you, but this does not negate the necessity to learn this skill! All too often our mangers will change priorities on us without thinking about the impact to our other tasks. Being able to effectively understand priorities will allow us to COMMUNICATE the impact of these changing priorities. Also, having the ability to prioritize will help you meet all your deadlines and not bottleneck the rest of the team.

Consequences of miss prioritized work:

  • Missed deadlines
  • You become the bottleneck for other people
  • Loss of visibility of important tasks

Production…. develop for it…

I address this somewhat in my “Stop Spinning Your Wheels” blog post as well.. but an important aspect to not being a lone ranger anymore is learning to develop for production.  More than likely at your former job you would log directly into your production server, make some tweaks, and come away the hero!!! Yay! Go you!  Well… You can’t do that anymore. Often times you will now find yourself working in a more structured development environment that must be deployed to a production environment. There are nuances you need to understand and take into account. For instance, learn to ALWAYS use relative paths for your URLs otherwise things that work in development will break in production. Avoid hardcoding scripts in your pages in SharePoint Designer (what happens if SPD is locked out of the production environment and you need to tweak something?).  Don’t hard code strings in your code,etc.. etc.. etc…  This one goes hand in hand with Consistency as well.

Consequences of not developing for production:

  • Missed deadlines
  • Broken functionality
  • Inability to maintain code effectively
  • Frustrated team members trying to figure out what you did

Copies and Backups… A lesson you only need to learn once…

So, yes, this is hopefully a lesson you only have to learn once. If you are modifying someone else’s file, project, code, site, etc… make SURE you create a back up first utilizing Source Code Control, taking a site collection backup with stsadm, or simply making a copy of the file and working from the copy. Failure to do so can be catastrophic. Sure, 90% of time this may not be an issue, but what happens when that other 10% occurs and SharePoint does what she does best and decides to totally corrupt your file or site to where it is unusable and you have no way of going back? There’s nothing quite like that dread that sets in when you realize you have destroyed something with no way to recover it… 

Consequences are vast and many including:

  • Missed deadlines
  • Lost work that must be re-developed
  • Loss of site and data that cannot be recovered and you better start looking for another job

Deadlines… it’s not a suggestion…

Anyone else notice a theme with the consequences? If you don’t get a handle on working effectively in a team environment you are at the very least going to start missing deadlines left and right. And you know what? That’s OKAY to happen every now and then when you are learning… BUT COMMUNICATE this with your team! If you give a deadline, you must either meet that deadline or inform your team well in advance that you won’t meet the deadline so everyone can adjust their expectations… Many times expectations will have to be adjusted for clients so this can become a VERY big deal. A deadline is not a suggestion, it’s an expectation. Learn to meet them and to recognize the warning signs for when they will be missed.

Patience… have some…

Finally… a big one for me personally. Be patient with those learning to work in a team environment. Encourage them and don’t chastise them (unless they keep making the same mistakes over and over and over, then feel free to thump them on the head). You might actually learn a thing or two yourself.

So.. these are just some suggestions to help make your life easier and lessen everyone’s frustration level. Some of this may be common sense, and some of this may be foreign to you. Regardless, if you find yourself failing in one of these areas, give it some thought and try to improve. Let’s face it, we should all be striving to improve our skills all the time.. if we aren’t growing then we are getting stale and ineffective.

Also, this is just what I was able to come up with off the top of my head, what suggestions do you have for being an effective team member?

Posted on Wednesday, May 11, 2011 12:48 PM | Back to top


Comments on this post: You aren’t the Lone Ranger anymore… Working Effectively in a Team Environment

# re: You aren’t the Lone Ranger anymore… Working Effectively in a Team Environment
Requesting Gravatar...
Haha this is all sound advice! I think communication is the oil that makes all the other components run smoothly. My office has five different teams, but there's at least one communicator in each, and without them hasseling everyone else for project status updates and development opinions we'd definitely spend a lot more time spinning.
Left by Claire on May 12, 2011 10:12 AM

# re: You aren’t the Lone Ranger anymore… Working Effectively in a Team Environment
Requesting Gravatar...
How nice of you to write an article about me! Seriously- could not be more timely. I will refer to this often as I embark on my newest SharePoint adventure.
Left by Nancy on May 17, 2011 9:51 AM

# re: You aren’t the Lone Ranger anymore… Working Effectively in a Team Environment
Requesting Gravatar...
Nice post with good points.
Left by NLV on May 24, 2011 12:48 AM

Your comment:
 (will show your gravatar)


Copyright © Mark Rackley | Powered by: GeeksWithBlogs.net