Tag Archives: enterirpse-it

Leaders Should Make Their Teams Teach

Teaching something will make you a better practitioner of that thing.  It is an adjunct to the old adage that true mastery of a subject is the ability to teach it to someone else.  The act of educating someone on something forces you to organize your thoughts on that subject.  This, in turn, gives you new insights on the subject and/or makes you more efficient at processing the subject.  Therefore, there is a lot of value to the teacher in the act of educating.

There is a business value as well.   But a lot of managers, however are not comfortable pushing their team members to do so – particularly if they have team members who resist doing it.  I have spoken to a number of managers who really have no idea how to break down that resistance.  There is obviously the ‘stick’ side of it where it should be a part of a senior person’s job description and if  they don’t do it, their review will not be as good as it could be.  But the stick side is a pretty weak instrument and it just breeds problems over the long haul.  The more important aspect is the carrot side of the discussion.

Look at it this way:   no matter how good a coder someone is, their value is intrinsically limited by the amount of code they can physically produce in a certain amount of time.  That means that once they reach their personal peak productivity, they are basically plateaued in terms of their career opportunity due to laws of physics and biology (i.e. only so many hours in a day and humans need to sleep).  Contrast that with someone who has reached their productivity peak and uses their skills to help make others better.  That person is now leveraging their skills through a larger group and enhancing the produtivity of that overall group by passing on lessons and learnings.  They are multiplying themselves through that group.  That person’s value has not plateaued.  This does not mean they are on a ‘management’ track, either – though it can lead there.  I have found that engineering organizations that have been successful over time all have a non-management ‘technical leader’ career path for folks who are both strong technically and effective leader/teacher/mentors.  Does your organization think like that?  It should.

Even if it doesn’t, it is irresponsible of the manager to not at least have a frank conversation about this to their team members.  That a team lead does a massive disservice to a team member’s career if they just encourage them to be ‘super techie’.  It will fundamentally limit their team members’ value and the value of the team in general.

Advertisement

Agility Comes from Knowledge

One of the members at Agile Austin is fond of saying that ‘the only true source of Agility is knowledge’.  I think that is very true in a lot of situations.  The more you know and understand, the more adaptable you can be.  It might be  a geek-spun buzzword version of the old aphorism that “knowledge is power”, but that doesn’t mean that it is in any way bad.  Indeed, old aphorisms, rephrased or not, stand the test of time because they speak to human nature.  For all of our technology, we’re still pretty much the same.

So, where does this cultural comment hit DevOps?  Many places, really, but today I am going to pick on the fact that Agile and DevOps require participants to know and understand more than what would have been present in their traditional job role.  It is no longer OK to just be the best coder or sysadmin or architect.  You have to maintain a much higher level of generalization to be effective in your specialized job role.

This can hurt people’s heads a bit.  Particularly in larger organizations where the message has been to specialize and be the best [technical role] that you can be.  The irony is that larger organizations tend to have large and complex application systems.  So, they have traditionally compensated by having teams of people who specialize in fitting things together across the specialties.  While this certainly works, there is often a lot of time spent on rework and polish to get the pieces to all fit together.  That also implies time, which directly impacts the responsiveness (agility) of the development organization to the business.

Now those organizations are faced with needing to retool their very culture (and the management structures entwined within it) to place some amount of value on generalization for their people.  That means deliberately encouraging staff to learn more and more about the “big picture” from all aspects – not just technical.  That means deliberately DIS-couraging isolationism in specific disciplines.  It also means deliberately blowing up organizational fiefdoms before they take hold.  And it means rewarding behaviors that focus on achieving the larger goals of the organization while rooting out incentives on very parochial behaviors

The funny thing is that this is not new.  When I was first a manager, I worked for a company obsessed with this sort of thing.  We were very high on the notion of ‘lifetime learning’ and organizational development in general.  It was a way that the company encouraged/taught/focused people to aggressively adapt to the changes that came with fast growth.  That company returned more to its investors than any other tech startup I have seen in a long time.  We never worried about solving problems -we all understood a lot about the business and had a common understanding of how it worked.  It was easy and fast to get people working on a problem because we did not have to waste time bringing people ‘up to speed’.  We knew how it fit together and understood the value of proactively pushing it into newbies’ heads.  They wouldn’t be newbies for long, after all.

This month’s book club selection  at Agile Austin is focusing on Peter Senge’s keystone work in this area – “The Fifth Discipline”.  I have not read it in a while, but it is damn good to hear people focusing on this stuff again.  I really liked a lot of the concepts in that book; probably because they are relatively timeless as it relates to human nature / behavior.