Monday, 15 October 2012

Perception and Fact - There is a Difference.

So here I go, the first of many posts (hopefully).


There are many ways that people progress through their careers, be it progression through a single business, or jumping from role to role in order to get to where you want to be. My experience is pretty much the progression through a single business, so this post is going to highlight the challenges that this has posed me, and how I have gone about tackling them. Hopefully this will help someone out there who finds themselves in a similar situation.

Now, I joined my current company as a junior. This meant I was still learning my trade, learning what was good and what wasn't. Learning what was acceptable, what would get me attention - be it the right or wrong type of attention. Through all of this learning, people gain a perception of you. This is especially true for the people in other departments who only get snap shots of you at work. I have found that this perception is especially difficult baggage to get rid of, but have been trying to do so for a while now. Whilst the people who work with you on a daily basis can see all the great things that you do, the customers just see snap shots of a young, loud, enthusiastic and sometimes brash young man telling it how it is. They see a young man having a laugh, keeping his team engaged and motivated and don't link it to the work delivered by the team he is in. They see someone not sat at their desk writing code. Whilst this may seem a little cynical, it is also devastatingly true.

In my role as a software development manager, I have a much closer working relationship with the people who take this exact view. Even more frustrating than trying to change these individuals perception of myself, is the fact that they have the same view of the staff in my development teams. Having suffered from this myself during my short career, it is something that I am quite passionate about working on and ensuring does not cloud the view of how my teams are performing.

The problem with all of the above is that it is simply based on the perception of individuals by individuals. A company with a culture that allows individuals to make decisions and changes based purely upon perception needs to stop and take a look at itself. They allow the company to be run purely with their emotion and little to no statistical data. Whilst it is invaluable to have the passion, desire, and drive to have a successful company, it needs the stats to go with it in order to truly delivery value. Without stats they will say that a team is not delivering enough and the team will be called upon to explain why. This is ultimately demoralising and not conducive to a highly performing development team.

Despite the views of people within businesses that I.T. 'aren't delivering' or 'could do more', the simple fact of the matter that all of this is based upon someones feeling, and can very rarely, if ever, be backed up with data. This is a very scary thought. Even scarier is fact that this isn't something that just happens in one place, but happens out there in a lot of companies. 

The move to driving changes and improvements out through the aid of actual statistics and figures can be a challenging one but, without them, how can you ever prove that what you do at work had a benefit.

The moral of this story, boys and girls, is that if you want to change something, you are going to need some way of seeing if its had a positive or negative effect. The only real way that you can do this is through the aid of stats and figures. This is the only true way you can have continuous improvements within the development teams, it is the same for the rest of the business. You have been warned.

4 comments:

  1. It happens everywhere Lee, I've experienced it at every single place I've worked.

    Righting that perception is probably the most difficult job a SDM has. The team will be delivering, but the customer (in your case, your colleagues in other departments, in mine, external clients) will always want more so will always believe that you're not doing enough.

    ReplyDelete
  2. Great post Lee. Can definitely relate. We all know the power of the metrics. Keep the posts coming. Damian

    ReplyDelete
  3. Is there a solution that involves capturing capacity, utilisation, productivity and business value of the developers and their team? If such a solution exists, how is this linked with the outcomes in the business... and bottom-line?

    What constitutes success; one developer writing 100 lines of code and generating £1m revenue, or ten developers writing 10,000 lines of code and generating £1.2m?

    How do modern development teams conduct qualitative self-assessments?

    ReplyDelete
  4. Plan-do-check-act. Build-measure-learn it's that simple. Lee you may like this little book: http://www.lulu.com/gb/en/shop/jurgen-appelo/how-to-change-the-world-a4-pdf/ebook/product-20105695.html

    It's true though most people don't rule by merit/results and this is where politics come in to the equation. But if you can defeat politics with cold hard facts then you're winning.

    ReplyDelete