Fostering a culture of team learning

 

 

Recently, we were sharing our experiences with my friend. He mentioned a statement his boss used to tell him when he worked at craft silicon.

I would rather hire three average developers than one rockstar developer. Within six months they will have delivered more.

Obviously, this rings true to my team orientated mind.

Yet such delivery does not just happen automatically. In the same way, individuals need to learn, so do teams.

Anita et al describe why some teams are smarter than others

In this entry, I will be looking at what you can do to stimulate learning in your own developer teams.

Break down communication barriers

As companies grow, the amount of paper work grows as well. This is not necessarily a bad thing, it implies the organization is codifying its knowledge thereby reducing rework.

For example, if you are hiring 8 – 10 developers every month it probably makes a lot of sense to have the on boarding process in a document.

The problem comes when communication happens primarily via documents.

The key here is to challenge yourself not to create a policy every time something goes wrong. Policies are only useful when the situation reoccurs many times within the course of your business.

You maybe intimately aware of agile’s face to face communication principle, yet the allure of beautifully detailed dashboard is guaranteed to get to any manager.

Don’t get carried away, there is such a thing as, over collaboration, constant communication also disrupts creative work.

If you do manage to hit the balance between process and communication the next biggest challenge is to ensure the team is kept intact and members are learning each other’s vocabulary

Build whole team responsibility

I find it surprising some people deliberately pigeonhole themselves with meaningless titles; “PHP developer”, “Python developer” etc. Of what use is your language to the business?

Clients care about having their problems solved. This means everyone in the team is a problem solver first then whatever other titles they chose.

In this mindset, everyone owns the outcome, not just the tasks they are working on. This means if as an individual you do everything right but the project still failed, then you also failed!

The more everyone has been involved in everything the more responsibility they will feel towards its success.

Lynda Gratton puts it as:

    working with other people was never more exciting and exhilarating and when you knew deep in your heart that what you were jointly achieving was important and purposeful

Capture useful knowledge

Let’s start with some timeless advice from Seneca

It is the mind which is tranquil and free from care which can roam through all the stages of its life: the minds of the preoccupied, as if harnessed in a yoke, cannot turn round and look behind them. So their lives vanish into an abyss; and just as it is no use pouring any amount of liquid into a container without a bottom to catch and hold it, so it does not matter how much time we are given if there is nowhere for it to settle; it escapes through the cracks and holes of the mind.

Here he was referring to the people who waste their time. But I feel it equally applies to those who waste their experience.

Whenever you work on a project, there is always something new to learn. Maybe you just figured out the lighting in meeting room A does not allow for easy projection. How do you capture this knowledge? How do you ensure no one else does a client demo in that room? If you encounter a rare bug in one of your core libraries, what do you do about it?

Reconciliation is a useful concept in this regard. Whenever you are done with a sprint, a project or even a day. Consider what did you expect to happen vs what actually happened.

How do you foster team learning in your own organization?  Talk to me in the comment section below or on my twitter @jchex

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer