How to Grow Beyond Blame and Justification
In the last couple of years a lot of people started to ask me how to get others to change and take responsibility. Most of the time these questions come from people wanting others to do things for them. Sounds familiar?
Well that is exactly how it should not be done! As a member of the Leadership Gift program, and long time follower of Christopher Avery's responsibility process, I found it was time to spread the message of doing things righter. As such, I have "Co" designed and facilitated an interactive conference session with Sergey Dmitriev at ALE2012 and with Erik Talboom at Open Agile Cluj. In the conference session we explore a couple of the key factors behind responsible behavior in such a way that attendees get a real understanding of applying responsible behavior. Both sessions were very well received and had an immediate impact on the rest of the conference!
Attendees were taking responsibility in changing the conference facilities setup, in a way that it suited them and the other attendees more appropriately. I still get messages from attendees of both sessions that it really helped them and their organizations to grow beyond blame and justifications. In that sense I consider it my responsibility to not only inform the conference attendees about the true power of applying responsible behavior. I like to invite everybody, including you, to enrich their personal lives, and by extension the organization they live in! How? I have the luck that the last conference session was fully recorded so I don't need to write a small book about the subject but just a small introduction in the "problem" scenario we used throughout the session. The rest is for you to watch, sit back, and enjoy...
The Perfect Problem Breakthrough
We are dealing with a senior software engineer/architect who has been in the company for about 16 years and is totally not a team player. In the past this was not a problem since everybody was pretty much doing what they needed to do within their own piece of the product and no collaboration needed at all. Since 2001 the company started to grow. Due to the success of their software, the customer count grew exponential. Just as the number of customers, the structure of the organization also exploded to an unmanageable size. Management and tasks were delegated more and more, and business focus got fuzzy. Since end of 2011 the company shifted gears and started using an Agile approach to build their products including a restructuring of their organization into small collaborative teams and this is working very well for the organization and its related income and customer satisfaction.
There is still one problem for the manager of the organization and that is that one person in one of the teams who is really blocking others out of “his” piece of the product. He does not allow anybody from the team to touch his code (collective code ownership) and does not help his fellow workers in achieving their iteration goals/commitments and sticks to doing his thing only up to the point where he is blaming others for not meeting commitments! This manifests itself within the team in lower motivation, frustrations from all directions and lower overall performance, which becomes an urgency for the manager to tackle.
To make things even worse, this senior engineer is very well connected to the business and end customers and in general they like him, because he’s always helping them on the spot. This is causing impact to other ongoing projects and commitments but that is of no concern to the business/customers asking the support at that moment, but to others not included in that conversation. So the manager goes to the employee to get him on board... (watch the video to find out how it turns out)
If you want to discover more about the subject and how you and your organization can benefit from it, do not hesitate to contact us!