Writings on various topics (mostly technical) from Oliver Hookins and Angela Collins. We have lived in Berlin since 2009, have two kids, and have far too little time to really justify having a blog.
I had a meeting this week where among other things we talked about our teams and team members and how things were doing, generally, in the sense of team health. Oh yeah, since I haven't explicitly called it out on this blog, for the last 9 months I've been an engineering manager and since the beginning of the year took on a second team. So I've got two teams of developers to manage currently.
Within the discussion we touched on personalities of team members and how some people are more likely to engage in pair programming, but others generally not. This reminded me of my own habits. I aspire to pair program, but when the opportunity is there I usually avoid it. This isn't setting a great example to my teams so I feel guilty about this, but in the moment we were discussing the topic I started to reflect on this tendency a little.
Part of the new management training programmes that are being explored at SoundCloud involves a reasonable amount (ok, a LOT) of self-discovery and self-awareness. One form this takes is in doing an MBTI test and getting familiar with your tendencies, preferences and communication styles. I've done this test at least twice in the past and nothing had changed this time around, but I'm more familiar now with the implications. I tend to live the factual, data-based world, and without delving too much into my own personal MBTI type, prefer to plan things out and think them through in advance rather than acting spontaneously in the moment, talking out problems and making on the spot decisions.
This really reflects on my hesitation when it comes to pair programming. Innate in the process is talking out problems when the situation is not understood, making on the spot decisions without having much time to reflect internally and rely on internal thought processes (since there's another person there waiting for you). This directly conflicts with my personal pre-dispositions. No wonder I am not a willing pair programmer! It's quite likely members of my teams may be the same, and hence taking a universal approach of everyone pair programs may at best lead to poor results and at worst lead to a dysfunctional team full of unhappy members.
I'm sure this is not an original thought (in general) but it was a useful realisation for me. I think that taking into account different personality types and different personal motivators for your team member, and using this when it comes to planning how to work and what to work on, can be one potentially powerful tool in building a strong and happy team.