Supporting Each Others Development
Context
We had a team day recently where four from our team met up with another developer from one of the other teams within our organisation to have some discussions on various topics face to face. One of the topics which was excellently led by one of my teammates was on psychological safety which I found very useful. My talk / discussion was on career and personal development. Most of the discussions went as I expected but one section we spent the longest on was on how to support each other through both personal and professional development. This post is to go through some of the responses and expand on them and ruminate on possible ideas to take them further. I shall be grouping them according to my personal take with no weight or priority in order of discussion, in the talk they came out in a much different order.
Feedback
Feedback is something that the team has discussed on a couple of occasions and while we are better than we were it is not an easy thing to do both for personal and professional development. Some people find it hard to give feedback whether it’s good, bad, or both, others may find it easy to give feedback but struggle to receive it. Personally I stand there awkwardly hoping the attention will go away but that’s just me 😺.
Quantity of feedback
We do not give feedback in the team that often, other than a generic “nice one” or “good job”. This is something we have noted before that we should do more often and there are many ways we can do this, some of which have already been discussed. Giving regular feedback can be very beneficial as it provides a positive affirmation that you are on the right track and doing well, or can correct a minor issue before it becomes a bad habit (like not writing tests, fortunately not a problem with my team).
One of the ways I was thinking would be good to fix this is to have more regular one-to-one conversations in the team, not just with our line manager but with each other. A no judgement place to be able to say, your work is great in x but in y you might want to try doing z to make it better, more stable, more maintainable, etc…. The only problem with this is some people might not feel too comfortable giving that kind of feedback in a one-to-one environment but it is an experiment that I believe we should carry out nonetheless. Another solution I was debating with myself about would be some form of anonymous feedback system, maybe a google form that we fill out semi regularly. While this would be easier to give feedback it would make receiving it harder not being able to face someone telling you how you can improve (to get clarity, ideas, or even to disagree).
Quality of feedback
Good feedback, referring to the quality, should ideally be constructive. whether it is good or bad I always take on feedback better if I can take it and run with it to learn something new or improve a way I do something.
Feedback should also not be too negative. Constantly getting negative feedback can be very mentally draining and cause you to doubt yourself which can lead to struggling to motivate yourself or feelings of isolation within the team. In my archery coaching we learned to give negative feedback using a technique called the complement sandwich: say something that is going well, comment on areas that can be improved and end on something positive. This leaves people in a more positive frame of mind as they think I need to improve Y but I’m doing great in X and Z.
Feedback should also ideally be a conversation and not a dictation, if you do not agree with the feedback then it should be discussed as it may be two people disagreeing on something that is a preference issue. It can also help to have a third party present to act as a moderator if you are worried that the person giving or receiving feedback may take it personally.
Introspection
Good feedback should be useful to both parties. For the person receiving feedback whether it is praising or constructive (or both) it shows them something they can work on, offers validation on a skill that they can take pride in, etc…. For the person giving feedback they can use this opportunity to gain empathy for the person they are providing feedback for. This empathy is very good for team cohesion and it allows each individual to have some idea of what the other team members struggle with or are good at. It shows where someone might need a bit more motivation and support and areas where if you struggle you know who to speak to.
Sharing
Course History
In our team we have a lot of collective knowledge but this is not solely limited to our technical skills. Between us we have participated in a lot of training courses / programs and therefore have many we can recommend to take or to avoid. We have already had a minor discussion in this topic and a repository of information on the courses we have taken and how we rate them was proposed. This will allow anyone on the team, current or future, to look at the list and if the skill they wish to learn is there they can use that information to make a better decision on which training course to do. We have also decided to, at the completion of a course give a short talk to the team, this could be a synopsis of the course or just 5 minutes on its good and bad points.
Side Projects
As developers we often take on side projects, I myself have started dozens over the years (not finished any of them but that’s besides the point…). Many of these could be of interest to others in the team so we have discussed sharing these projects as most of them are open source on github so pull requests could be made. I like this idea, it is a shared out of work experience with the team where everyone can practice skills that are not often used day to day and have fun doing so.
Shared Courses
While not everyone has the same interests on the team there are many areas where they overlap. We have decided as a team that where this is the case we want to try doing courses as a group, this could be as a pair or even the whole team. Some of these benefits of this are that we can support each other in areas where we get stuck, we can bounce ideas off each other for tasks, we can decide on a shared goal for future development after the course, etc…. This is largely dependent on finding and agreeing on a course that we all want to participate in and finding a time where we can justify having a large portion of the team doing it.
Lightning Talks
We have a monthly meeting where people can give short 10 minute talks on a subject that they are particularly knowledgable about or interested in. As a team we want to do more talks here to share our knowledge with the rest of the organisation.
Goals
Goals are a really important part of the process of self improvement, whether it is personal development or professional.
Discussing Goals
Sharing and discussing goals with the team shows us where our goals overlap, where we can offer help, what courses we can recommend to our colleagues, etc…. Some goals, particularly personal ones people may not be able to share and that is fine, even a general idea of areas people want to improve will allow us to generate some shared goals, provide ideas for joint training, offer support where we can, help motivate and support people, etc….
Repository of Goals and Interests
Taking the results of the above discussion and storing it in a repository somewhere will allow us to keep a living document that shows all of the benefits of the above in a persistent manner. It can be a first step in deciding on training by looking up to see if anyone else is interested in the same or has skills in that area or to see if there is a way to help a colleague. For example if I went on and saw that someone had posted a goal of improving their testing skills then I would be able to arrange a time to talk with them and either provide some recommendations for courses or even just help answer questions they may have.
Future
I am planning to update this post as we discuss this more as a team. If there are any major developments or changes then this may get their own post and will be linked here. This is part of my teamwork series of posts which I want to keep updated and relevant, my next one will likely be a recap of my colleague’s talk on psychological safety.