Thursday, May 5, 2011

My professional goals

Once again, I've been asked to write up my goals for my job. While I agree this is important, corporate guidelines around how I set my goals, the structure, and / or templates I don't agree with. I think it helps getting started, keeping an eye out on what you want to be, and setting a path to getting there. I have yet to actually execute on any goals professionally as my project work simply gets in the way of doing what I think is interesting. Makes it hard to be measured against something a company ask's you to set out prior to knowing your project work.

I also feel my goals are mine, verses the company's. I hear they are suppose to align, sure, but I can't align with all parts of a company's direction, if I did, it would be my company. Nor can I execute on a company's entire direction. I also don't care if they are SMART (Specific, Measurable, Attainable, Realistic, Timely).

That said, corporate goal setting should be simple and aligned on the individual to allow them to grow how they want to grow while helping their employer's bottom line, verses making the individual set goals based on what the employeer wants of them. If there is complete misalignment, either the employer or the employee made a wrong decision by partnering with the other.

Regardless, the following are my professional goals simplified beyond a company's structure and/or template.
  1. Read a lot of technical news articles, blogs, and generic content I find interesting and share it. Yes, I want to be measured and rewarded for this professionally. This will allow me to share items with those I work with that are interesting, and keep conversation of technical things beyond what I am actually doing. And if you are an employeer and you think your technical folks don't spend about 2 hours a day reading internet crap, you are wrong. 
  2. Contribute as much as I can internally and externally what I've learned based on my work done while an employee. This involves write ups and in-person presentations, doing demos and proof of concept type work (see #5), code reviews, approach discussions, etc. I want to talk and be known by my peer group. 
  3. Always be building and never just conceptually designing and/or architecting. I feel people who do just design and architect lose their edge. There is something about people who can build better than design that I respect so much more. How can I respect myself, or others respect me if I am not hands on making it happen.  
  4. Always be building in different ways and changing as I go. I never want to be the same person I was last year, solving the same problems and using the same stack. I want to move around and solve problems in different ways on different teams. Sometimes I think I know what I want, other times I am surprised by what I don't know. If there is a job, but nobody is a good fit, try me even if I have no background in the area. 
  5. Participate in in concept projects, research, idea generation efforts for no good reason except that technical people feel its important. Along with this, being involved in open source projects, or openly developing for the community on these projects or efforts. I never like hearing about "special" projects, it just means I wasn't the guy telling someone else about it. Always gave me the sense I was missing out on something special. 
  6. Specialized in performance and / or data aspects of a solution. These go hand in hand mostly, its more and more important to act on data in a timely fashion. If something is taking to long, and it needs to be shortened, I want in. If it involves a lot of data, I want in. I am just interested, I am not sure why. 
  7. To work on teams with members smarter than me. I never want to be the smartest guy in the room, I'd rather be learning than teaching. I'll do both, but if I were to pick one, it would be learning. 
  8. Be sent to conferences. 
I'll leave it at that. 

No comments:

Share on Twitter