As a leader, coach, mentor, and manager I have been through many goal and objective meetings. Through the conversations of helping determine goals for my team there are a few principles that I diligently adhere to:
These are not my goals but yours:
I have yet to complete goals that have been set by others with little or no input from myself. It is a sad state of affairs when a manager has “determined what is best for the employee”. When I first started leading a team, I was this manager. To the detriment of the company I worked for, I alienated my team and made the goal process a wasteful paper drill that eventually ended up in the circular file. To be fair though, the company instituted a very stringent goal setting process that lacked input from the employee.
Each individual now is responsible for going and providing the first cut of the goals. I usually ask them to think about them in a S.M.A.R.T. goal format when presenting to me. I have found that this is very hard at the start for my team. However, we are getting better after a couple of iterations. Below is an example of one of my employees (notice that it is not quite in SMART goal format):
- Tech skills:
- jQuery
- WPF/Silverlight
- Functional Programming / F#
- Entity Framework
- ASP.NET MVC
- Project-related:
- Remove a now-redundant middle-tier layer from our application
- Business/Process:
- Learn how to develop leadership skills among those with more technical experience
- Develop an internal tool using new technology
- Team goal:
- Revisit and take ownership of the Definition of Done
Develop Goals for the Short Term
I typically ask that goals and objectives last no more than 1 quarter. I have found this to be a very good time box. This keeps the goals somewhat fresh in the employees mind. It also helps to focus on some very specific goal setting. Within the time period, I ask the individuals to “check-in”. This allows me to help guide them to with resources and ideas to achieve their goal.
The most successful individual use this “check-in” process.
Defining The End Result
One of the most challenge areas that I face when determining goals for my team, is what the end result looks like. Ideally it is some physical artifact that can be presented or disseminated. I work to ensure that the knowledge that my employees have gained can be shared. A lot of times the end result is usually a process improvement within the team (which is usually the best from a business perspective).
This is the refined list from above. Since the timeline is known (1 quarter), it is not shown as part of the goal.
- Pick 5 areas in our application where performance can benefit from doing things client-side using jQuery.
- Document the improvements and present them.
- Pair with each member of the team once per week.
- Observe how the process changes coding styles during this period (3 months).
- Record the “a-ha” moments.
- Present your findings.
- Research and develop one area of the build process.
- Develop a custom MS Build script instead of using the Visual Studio Solution Build.
- Discover online what others are doing but don’t just use their tools.
- Team Project: Develop a Virtual Scrum Board using WPF & ClickOnce.
This process gets better each time I sit down with my team. What process do you use to define goals and objectives for your team?