At the beginning of the year Teams set goals. Sport analogies make the most sense so I will use them again. In hockey, it is to win the Stanley Cup and in American Football it is to win the Lombardi Trophy. For some teams who the previous year the goal may not be as high, it could be simply to make the playoffs. Working in Technology it is often to do ‘project x’ or complete ‘project y,’ in sales (which I did as part of Tech consulting) it was sell X amount or bring in Y number of clients.  

The above fit ‘SMART’ (as we spoke about in Part 3) and I should just stop here, and presto we have magically created goals for the new year, and our team will successfully get them done. Well not so fast. Digging deeper and understanding a lofty goal like winning a championship has massive downside. In sports, only one team brings home the trophy each year, and thus the other 30 or so teams ‘failed.’ So, if your team does not reach goals, complete projects on time, bring in revenue etc., is it a failure? 

The first thing companies do wrong is do reviews only with individuals. In many cases the ‘manager’ or a team gets the team goal, and on his review when they do not get there, he is asked the reason etc. Now I have been on the ‘why didn’t you reach your goal’ (or the why I did,) I will use analogy not from sports, but for people who invest, when they have good year and their portfolio rises, it’s always ‘I am a great stock picker’ and when their portfolio crashes, it was ‘There are some outside forces’ like the SP500 is down, we are in a recessions. To me, when reviews are done like this, we put our managers in that same situation. Let him gloat how great he is when he succeeds and find all the outside issues when they do not. 

Team goals are just that, we should savor victory as a team, and share the disappointment in the loss. No company I have worked for, not any other I have read about has this notion of end of year team reviews. Companies do reward teams with lucites, cash etc. when hitting some ‘completion’ mark, or hit sales goals etc. But the review is missing, and more important digging into the why is lost. 

The second thing is that reviews are done and really managed ‘Annually.’ As bonus cycles, raises, promotions etc. Management needs some way to judge and compare so the process is set up this way. And as stated the process is done mostly one on one with people, not teams. Can you really review once a year and summarize twelve months of work for anyone or any team? And does not this scale well, how many individuals can you review, understand their impact for their year and give honest assessments.  

Software development teams who follow agile practices often do retrospectives. These are regularly scheduled (every two weeks or so) meetings to chat not about status, but about the process of development. Many create lists of what we should be doing more of what to stop doing, and other ideas to improve how the project is built. These even fall short, as they are momentary, and trying to look at a brief period, and once a quarter a 10,000-foot view should be done. A review on the retrospectives, looking at things like ‘why doesn’t anyone address the big issues.’ or is the retrospective helping us hit the goal. This goes back to the fact, it is hard to admit that there is something wrong, it is outside our control. 

And lastly, we look at failure completely wrong. Failure is not something we know how to deal with. I have told the story about the difference between college and the real world, using the example that if you made a three-legged table in college, the professor what give you an ‘A’ for proving you cannot build a three-legged table. In the real world you would get fired for not producing a product that could sell. But failures have some root cause behind it, and for teams to get better they need not look at a failure as a problem, but one of an experience.  

Failures should be something we look at as we understand what we did does not work, and have built the necessary tools, training, reminders to improve the team. Everyone talks about ‘getting’ better, and no great person made zero mistakes. Why are we not celebrating the failures, and using them to make the team better? Why in management meetings do we demo/talk only about projects that succeeded, the successful architecture etc. Each of those projects had mini-failures, things they did wrong and corrected. And instead of teaching the rest of the organization and other teams how to get past those failures, we show the ‘success’ and the chance to repeat those failures persists. We need to present failures, and the lessons learned, and reinforcement so they are not made again.  

Though I make this sound easy, at the start of 2023 I am planning to redo how I run my team and try to fix some of the above. Funny, I knew these problems existed and I complained about them in the 90s. But writing this blog has made me rethink how to address them. I will let you know how they work out.  So on my to do list is to create a structure where I have recurring team meetings where we address goal changes (to be pushed down to individual goals) and create a culture where failures are brought forward as a learning experience.

This opinion is mine, and mine only, my current or former employers have nothing to do with it. I do not write for any financial gain, I do not take advertising and any product company listed was not done for payment. But if you do like what I write you can donate to the charity I support (with my wife who passed away in 2017) Morgan Stanley’s Children’s Hospital or donate to your favorite charity. I pay to host my site out of my own pocket, my intention is to keep it free.  I do read all feedback, I mostly wont post any of them

This Blog is a labor of love, and was originally going to be a book.  With the advent of being able to publish yourself on the web I chose this path.  I will write many of these and not worry too much about grammar or spelling (I will try to come back later and fix it) but focus on content.  I apologize in advance for my ADD as often topics may flip.  I hope one day to turn this into a book and or a podcast, but for now it will remain a blog.