What factors should I consider when evaluating a job offer to work with a specific software platform?

Question

I am currently working as a .NET 4.0 developer for a company, and would like to aim to grow in my career and reach a leadership position. I currently am not the lead developer, however I am his "right hand", and get given some of the more important tasks.

My boss knows of my goal, and has let me know that there is an open position that I could apply to (and he said I have good chances of getting this job). This is a new project that uses Sharepoint, a web application platform developed by Microsoft. I would start alone and be solely responsible for the project, and eventually hire new people to work under me.

I'm considering this position, but am not sure of how this will affect my career as I don't see very many job postings for Sharepoint developers, although there are plenty for .Net developers.

That's the real problem that is bothering me is: the whole project is built over Sharepoint. I have never developed for this platform, but I'm afraid that building experience with Sharepoint will somehow restrict my available career paths.

For instance, I'm afraid that the time I will spend developing using Sharepoint will not be as valuable (in learning and CV) as the time I spend in my current job of managing deployment, proposing new architectures, and so on with the .Net Framework.

What kind of questions can I ask myself when trying to decide between building experience with a specific software platform, or a generic framework that is widely accepted in the industry? What factors should I consider that may affect my decision?

Answer 1

Learning new platforms, tools and techniques is inevitable in most careers; in my experience, the first couple of changes are the hardest, and after that it gets easier as you start to link and translate concepts. For some perspective, look at the tools and concepts that existed 20 years ago.

It's better to do it early on (0-10 years), than later in your career (10+ years), when your ideas are more fixed.

To me, the key issue here is the career path you have indicated that you want to follow. There are essentially three choices that most people face along a technical career path: The specialist, the generalist, and leadership.

[I] would like to aim to grow in my career and reach a leadership position. I currently am not the lead developer, however I am his "right hand", and get given some of the more important tasks.

Not all people in a highly technical role aspire to leadership positions, and leadership as a skill is quite distinct from any technical skill base. Growing this skill can require as much investment as any technical skill, and in many ways it can be a lot more challenging.

Mobility is important in a leadership role, as most positions have a "life-span" of maybe 2-3 years (initially) and perhaps 3-5 years before you need to move on. The next opportunity may not be within your organisation, and may use different tool sets.

Team leadership is also about putting the overall team productivity ahead of your own; a significant proportion of you time will need to be spent leading, not doing.

I'd actually suggest that going into a team in a leadership role with little knowledge of the platform is a huge advantage.

I found that the two hardest things to learn as a leader were the ability to delegate effectively, and the ability to listen to your team.

Delegation.

If you are an expert in a system, then delegating a task to junior staff is hard. They will do it slowly, and do it wrong. It's frustrating to watch. You want to dive in and do it for them so you can move on.

This is not leadership.

You are not coaching and supporting your staff to improve, you're demotivating them (by making the task look easy) and teaching them that if they give up quickly, you will do their work.

Listening.

Conversely, one of Covey's "seven habits" is to "seek first to understand, then be understood." If you are going to have to learn from your team about the platform, and how they use it, you will be forced, at first, to listen to them. In doing so, you are more likely to build a rapport with you team, get a measure of their skills, communication styles and productivity.

Understanding your team strengths and weaknesses is important in terms of ensuring they are happy and productive - and of course you are included in that, because as leader, you are still part of the team. Listening and learning from your team is one of the keys to this.

To sum up - if you are interested in a 10+ year leadership career in a technical field, changing platforms as part of a leadership role, in my opinion, offers some significant long term advantages for both development of leadership skills and long term career options.

This was (essentially) my career path over the last 20 or so years.

Answer 2

Sharepoint programming is .NET programming. You will be developing many skills (both technical and soft) you will be able to use even if you never do another Sharepoint project again:

• Designing a product
• Hiring and managing developers
• Specifics of building reports with SSRS, building ASP.NET controls, learning APIs like authorization or encryption
• Working with third-party libraries to make PDFs or whatnot
• C# language features like LINQ, await/async, etc
• Graphics/css/layout design skills to make something beautiful and usable

Your boss is offering you something very cool. Think twice before turning it down just because Sharepoint is awful (which it certainly is, I've done it too.)

If you come out of the project never wanting to do Sharepoint again (I know EXACTLY how that feels) you can list it as "web development" and emphasize the parts of it that are transferrable.

It is a very important skill for everyone to be able to see commonality in seemingly disparate kinds of work.

Answer 3

It's bit me in the ass multiple times now, but I've finally learned this:

Don't take jobs you don't actually want.

As for the career value of the technology, it doesn't really matter that much what you're doing if it's roughly-related to the broader category.

If you just want to fast-track it to management and don't find the coding aspects that interesting anyway, being able to not care and plug through and eventually lead a team through some tedious crap is what you have the opportunity to demonstrate here and yes that would be valuable.

But if one technology over another actually has a significant impact on your personal interest, hold out for a leadership position dealing with something that's not going to make you miserable and depressed.