Goal-driven Development
Years ago (well not that many years)…when I was working for a large company, I was asked during my midyear review to identify my goals.
I remember that my immediate reply was to ask for the group’s goals, because with that information I could figure out my own goals, as
a member of the team. Looking back, I wonder how they could have asked me for a goal without telling me the larger goals first. The process was with no doubt broken. I remember promising myself that when I become a manager, I will always tell my team the company goals so they can best help achieve them.
But, as time passed by, when I founded Typemock and became the CEO, I must admit that I haven’t always lived up to my word.
My wakeup call was when we had a very large financial project to produce and submit. After we sent the report to our CPA, I received a hysterical phone call from my accountant that my numbers don’t fit. I checked and realized that the reason the numbers were wrong was because the goal was not communicated properly to the people in the company. My team did everything right. They did whatever they could to meet the deadline. They didn’t wait for me. They worked as a team. But I didn’t explain the goals properly.
"Ahhh, so that’s what you meant." A few hours later the numbers were sorted out.
Once I explained the goals and they understood them, they helped fixed the report. If they knew what the goals were from the beginning, the drama would have been avoided.
One of my trusted marketing advisors has a unique and successful tool: the project brief. For every task, he first writes the goals and the sub goals and then the course of action to get there. By sharing the brief, the team has the information they need.
For example, with Test Lint, we want to have web pages for each of our golden rule. Saying that we need a page will probably get us nice pages but the goal is missing. Writing down that the goal of the page will lead to different results. So if our goal is to teach the developer to create great tests, we can explain the reason why the rule exists and how to create tests that follow the rule. Communicating the goal directs the task, and keeps the team focused on the same end result.
As Covey says Start with the End in mind.
Recent Posts
- Top 5 questions to ask when checking references
- Unacceptable: Unit testing will take 20 years to catch on
- The 4 reasons why we DIDN’T choose Oslo
- Typemock Academy Launch
- The First Rule to Software Craftsmanship
Categories
- .NET Tests
- Agile
- Code Integrity
- Community
- Debugging
- Fun
- Management for Geeks
- Marketing
- Product
- Release
- Reviews
- SharePoint
- TDD
- Time Management
- Uncategorized
- Unit Tests
Archives
- August 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
