Doing Fieldwork in TIM Group


How do you get a sense of the culture of a place? This is the question that Joe Schmetzer and I were contemplating at our fortnightly morning ‘get together’ where we mentor and coach each other. We’d been discussing the idea for several meetings by this point, but this time I’d been looking at the blog of Fieldwork (thanks to Douglas Squirrel for pointing me at it!). Fieldwork has been publishing a series that they call Everyday Fieldwork and provided some instructions on how to observe the unseen elements around you and see your work differently.

Armed with the discussions I had with Joe and the instructions from Fieldwork, I’ve been taking pictures of what I see around me at TIM Group. Along with each picture, I’ve been keeping a description of what is happening in the picture and some of my own thoughts about the scene. Going forward, I am planning on posting a number of these pictures and their descriptions. I hope that they’ll help me and others understand what the culture inside TIM Group actually is.

And so, in keeping with one of the phrases I hear around here pretty often, I won’t delay in posting the first one of these.

Home Office

There is a messy desk with a laptop plugged into a large monitor. A separate keyboard and mouse are in a prominent position. A cup of tea is on the left hand side. The chair has a blanket over the back, which is used to cover the seat to keep cat hair off. On the monitor is a browser window with email in it. Behind the browser is OmniFocus and Slack. I took this on a day that I decided to work from home. A number of developers at TIM Group work from their homes either most of the time or regularly. Working from home isn’t something I normally do, however, so this was a somewhat special day. Even though I don’t do it often, I was still able to be connected to everything and everyone I needed.

What I learned about self-organisation

I learned a number of things at Olaf Lewitz and Adam Pearson’s course ‘Enabling Self-Organisation: Getting Macro Results without Micromanaging‘. I think my biggest a-ha moment was that self-organisation is not something that you do to others, it is something that you do to yourself.

The course focussed on a few simple techniques to help each of us be better able to self-organise. The first is a simple system to train into yourself for evaluating the situation you are in (feel, think, act). The second is a structure to use for actively listening where you fit what you want to reflect back to someone in a conversation structured as “you feel X because Y”.

My experiences with self-organisation at TIM Group has taught me that it starts with myself. From there it expands into how I interact with others. These two systems that I got from the course will make it more likely that I’ll have effective interactions and expand self-organisation in the group.

Gaining Feedback, Building Trust


A powerful means of building trust and collaboration within a team is to gather around a table and tell each other face to face ‘this is how your actions made me feel’, both the good and the bad.

The importance of feedback

Effective software development requires a robust feedback loop.  Test-driven development gives immediate feedback on ‘does this code do what I expect?’ Continuous Integration gives early feedback on ‘does this code work with the rest of the system?’  And early incremental delivery gives quick feedback on ‘is this code useful to the customer?’

All this feedback is about our code, but as Gerald Weinburg famously said, No matter how it looks at first, it’s always a people problem” – so it seems wise to put at least as much effort into getting feedback about how well we are collaborating with our team-mates.  Compared to the immediate and precise feedback of a good test,  the standard annual performance review is too far distant from the behaviour in question to be much use in guiding iteration and continuous improvement.  We need something better.

How it works

We decided to adopt a variation on Jurgen Appelo’s 360 degree meetings.  The key point is to bring the whole team together, face to face around a table, to give direct feedback.  First, each person writes down items of feedback.  Each item:

  • should be addressed to one team-mate,
  • can be ‘went well’, ‘puzzle’, or ‘could improve’,
  • should refer to a specific incident, meeting or piece of work, and
  • ideally should be framed in terms of how that behaviour made you feel at the time.

We then go around the group, and each person in turn delivers one item of feedback, until they have all been covered.  After each item, the feedback recipient may respond briefly to ask for clarification; however the focus should be on asking ‘what can I improve?’ from the feedback, not on ‘defending myself’ from criticism.

As an example, recently a team-mate raised a ‘puzzle’ that I often seem to make arbitrary business decisions while coding, rather than raising the question with our business representatives.  Talking things through, we surfaced many underlying reasons why I tend to do this, including a degree of intellectual arrogance and a lack of trust.  We agreed that in future, we will at least share our decisions on slack, where business owners can see them.

How it helped us

The team agreed to experiment with holding this feedback meeting weekly for a month, after which we asked ourselves ‘should we continue?’. There was unanimous consent that we wanted to; what was interesting was that each person spotted different benefits from the process:

  • Lots of ‘went well’ feedback reinforced positive behaviours, which people might otherwise stop doing as they might not know they were valued
  • Positive feedback also builds confidence and satisfaction working on the team
  • ‘Could Improve’ feedback relating to a specific incident feels easier to accept, as it is about behaviour on a single occasion, rather than a general criticism of you as a person.
  • Rapid, small pieces of feedback lead to iterative improvements
  • When one person gives me feedback privately, then I’m inclined to think ‘that person has a problem’, and not look to change my own behaviour.  By giving it in front of the whole team, then unless anyone disagrees with the feedback as given, I’m more likely to accept that I should try and change myself.
  • Subsequent performance reviews are fairer, easier to write, and less surprising
  • By being prepared to accept critical feedback in front of the team, each of us makes ourselves vulnerable to our team-mates.  Doing this builds up a powerful sense of trust and interdependence between team-mates, which helps the team gel and thus collaborate effectively.

As team members switched onto other teams, they spread the practice of weekly feedback sessions across the TIM Group development organisation.  Having seen the benefits, I highly recommend this practice to any team working together closely.

Doing this yourself

Just as with retros, it can be helpful first to jog memories about what the team has worked on over the last week or fortnight.  Gathering in front of a task board, or collectively making a list of what has just been done, often helps people remember events they have feedback to give on.

We discovered that the vast majority of feedback (90%), was positive, and quite often a meeting concluded with no negative feedback given.  I think this is helpful too, and helps build up the trust and confidence which makes it possible for constructive criticisms to be made.  

We started out with all team members physically present in the room, however as our teams become more and more distributed, we soon adapted to use a hangout for some or all participants, which works fine.

We were lucky to start from a position where the team members knew one another, and had a reasonable level of trust and a fairly flat hierarchy.  It worked for us even though I was officially line manager of two of the others in the team; the reciprocal nature of this tended to reduce the effect of hierarchy, since my reports could equally raise feedback for me, which would go to my own line manager afterwards for my performance review.  

Everyone in the meeting should be ‘part of the team’ and committed to common goals, and everyone present should be open to receiving feedback – it’s fine to have a team lead or manager in the meeting, as long as they are also receiving feedback.

So if your team works closely together, I really recommend trying weekly feedback meetings.  They are very simple to run, and need only take as long as necessary based on the amount of feedback people have; the benefits in increased trust and collaboration are noticeable.

Choosing what work to do at TIM Group

TL;DR: Working at TIM Group means having the responsibility to decide what work to do. The most obvious criteria is business value but I don’t think that is enough.

At TIM Group we have been experimenting with self-organisation for a while. It’s been a gradual process that started with the adoption of the Eight Behaviours for Smarter Teams and whose last steps were the removal of the line management structure in the technology department and a reiterated message from the CEO on employees insisting on being responsible.

My personal experience has been of changing team and/or project every six months or so which I find refreshing. Most of the time my moves were motivated by changing conditions and suggested by people higher in the hierarchy. A few times, very notably the last change of both team and project at the same time was decided and executed without indication from the management. I saw this happen multiple times since, to multiple people across multiple departments.

My colleagues and I have the responsibility of deciding what work to do. The executive team still has the authority to give orders and to fire people but that does not happen often. For all intents and purposes proposing projects, staffing those projects and delivering are now shared responsibilities.

Continue reading

Kik, left-pad… Should I stop using npm?

TL;DR: No, unless you make npm packages. If you do publish npm packages think about how the disputes are resolved and decide if you are OK with it.

I started using npm a few years ago in our build system. My CTO and his deputy today told me that means it is in production. I thought it was not, but on second thought I think they are right since it decides what code is in the production artefacts.

A few days ago, while I was on holiday, two of my colleagues investigated a problem with npm regarding some dependencies that may contain malicious code. I’m the one who used it first. I felt responsible.

I read about the issue on GitHub and I was more worried: npm allowing reuse of names meant that it was unsafe to use it. Due to my decision to adopt npm more and more projects in the company depend on that, was I responsible for us disseminating malware?

How did you feel at that time? Had you done your due diligence on npm? I felt I had not.

Or did I? After all, what is the difference between npm, Maven and GitHub? Don’t they all allow you to download some code identified by a name and a version number?

Continue reading

Using your values to choose

At the London Action Science Meetup in January we discussed the article Emotional Agility (HBR, Nov 2013), and in particular how to apply the four steps described in the article:

  1. recognize your patterns;
  2. label your thoughts and emotions;
  3. accept them; and
  4. act on your values

The importance of using your values they provide a stable point of reference, not subject to day-to-day fluctuations: “The mind’s thought stream flows endlessly, and emotions change like the weather, but values can be called on at any time, in any situation.”

For me personally, one consequence is choosing between alternatives for positive reasons, not negative ones. This was useful for a recent decision at TIM Group and I used the occasion of our weekly Lightning Talks to share the experience more widely.

Rollbackability in upgrading a MySQL cluster

Here I give a lightning talk on how we mitigated the risk of upgrading the version of MySQL used in one of TIM Group’s most important databases.

Our approach to risk mitigation was Rollbackability. Rather than spend all our time ensuring that nothing would go wrong, we decided to plan the upgrade such that if anything did go wrong, we could rollback safely. One complicated replication topology,  double the use of computing resource and a sprinkling of unsupported MySQL behaviour later, we safely upgraded versions with minimal impact to the business, knowing that we had “Undo” at every step of the way.


The diagrams used in the talk, showing each step in the process, are available here.

Human Error and Just Culture

Sidney Dekker’s Just Culture made me thankful I don’t work in an occupation with a high risk of impacting public safety (those described in the book include aviation, health-care, and policing). In our society we believe that practitioners should be accountable for their actions, that without legal consequences after a tragedy there would be no justice. The dilemma is that tragic outcomes are more likely to be the result of systemic issues rather than bad actors, and the legal system is fundamentally unsuitable for dealing with issues of systematic safety. Worse, the risk of legal consequences stifles learning, and so our search for justice makes tragic outcomes more likely, rather than less.

Reading Just Culture after Charles Perrow’s Normal Accidents was a serendipitous pairing. Normal Accidents illustrates very convincingly that safety is an issue that largely transcends our traditional idea of human error. It makes the case that some accidents are normal and expected because of the properties of the system, and that the easy finger pointing at the practitioners misses the real story. As we should already know from Deming and manufacturing, quality is a property of the system, not the people in the system.

Picking up from there, Just Culture shows how the concept of accident doesn’t exist in law. There is always someone who was negligent, either willfully or not, and that someone shall be held responsible. The law isn’t interested in the learning of the system. It isn’t really interested in the truth as most of us would understand it. It is really about blame and about punishment.

How does your organization respond to a system outage? Are blame and finger-pointing the order of the day? We may not be subject to the criminalization of error described in Just Culture, but the organizational reflex can all too easily be to blame the developers, the testers, the system administrators, or others, when the focus should be on organizational learning, on fixing the system.

The idea of Blameless PostMortems is not new to TIM Group. We’ve done our best to use our RCAs as a tool for improving the system for several years now. Just Culture served as a reminder that we are fighting a cultural bias, and we need vigilance to avoid outdated ideas of human error creeping back into our organization. The pressure to do so is both pervasive and subtle. It would be easy to detect and fight if it were a case of managers asking “who screwed up?” It is harder when it seems like a virtue, when it is an engineer who is quick to assume responsibility for a mistake. It is a valuable trait when each individual is willing to be self-critical. The challenge is being able to look beyond the individual to the contribution of the larger system.

This is the balance we are trying to strike, between individuals who feel enough safety that they are willing to acknowledge their own contribution to the problem, and a system that doesn’t accept “human error” as a reason to avoid learning. We believe this is the path to a high-performing, and just, culture.

SoCraTes Germany

SoCraTes Germany 2015 has again been a conference full of superlatives — or should I say “unconference”, given that it consists mainly of a two-day Open Space? Whatever you call it, we had more participants (over 180), more proposed sessions (90 – 100 sessions per day), and more sponsors than ever.

Speaking of sponsors: Of course TIM Group was among them, and all contributions were spent on reducing hotel bills for participants. Not that it was an expensive event anyway: the participants cover their hotel room, breakfast and dinner, and that’s it. But let me start at the beginning…

Six or maybe even seven years ago, my boyfriend Andreas Leidig decided to create a conference for developers — after all, developers deliver the software. If you remove all managers from a software project, chances are you might get something usable out of it, but if you remove all developers, well, I’d say your chances are zero. There were lots of agile events for managers, coaches and other “tree-huggers”, but no general-purpose developer conferences along the lines of software craftsmanship and improvement.

So Andreas created a developer conference, and named it SoCraTes: Software Craftsmanship and Testing Conference. It was designed as a two-day event falling on a Friday and Saturday so that both the developer and the developer’s employer would contribute time to the event. Arrival on the previous evening was mandatory in order to start the first day early and in a relaxed fashion. Another important factor was that it was held off-site — everybody stayed in the conference hotel, which we had to ourselves, allowing us to be together from the first yoga and jogging workout before breakfast to the last beer, song, or boardgame long after midnight.

We started our first SoCraTes in 2011, with the help of a small handful of friends. The first year we had one day of talks and one day of Open Space, because we were afraid companies would not let their employees attend a conference without a programme. The feedback of the 50+ participants reassured us we didn’t need the programmed talks, and from the second year we ran SoCraTes as a two-day Open Space. We sold out in the second year with about 75 participants, confirming our decision. On Saturday evening of the second year, a group of participants decided that they had not yet had enough, so they extended their stay and spontaneously ran a Coderetreat on Sunday. This Coderetreat is now an integral (though optional) part of SoCraTes, accompanied by workshops and other half- or full-day sessions.

In the third year, we sold out so quickly (literally within a minute) that we felt the need to do something. Of course it was nice for everybody who could register, but thinking of those who could not get a spot diminished the joy quite a bit. Also, the SoCraTes “brand” had expanded to the UK, where a sibling event was being run by the London Software Craftsmanship Community. Meeting friends from abroad was an important part of attending SoCraTes; how could this reliably happen with such high demand and such a small number of participant slots?

After some discussion among the organizers, we decided to experiment with increasing the size of the event. We were curious — and also a bit tense — because we wondered whether it would still be the same event, with the same familiar feel we had come to love so much.

The fourth SoCraTes took place last year with twice as many participants, approximately 150. And it was amazing! Of course the event felt different. I was not able to speak to everybody any more. Everything took longer, from the signup to the marketplace to walking around the new hotel, which was of course a bit bigger than the previous one. But at the same time, the SoCraTes spirit was there just like the years before, as the seasoned participants carried it over while the newbies blended in naturally. We heard many positive voices and read enthusiastic blog posts. Our experiment had been a success, and so we did not think twice about continuing in this direction. In 2015, we increased the number of participants to 180, and next year we will try to cross the 200 mark. Although I will slowly pass the management of SoCraTes on to the next “generation” of organizers, I’m looking forward to seeing SoCraTes thrive together with its sibling conferences that sprout all over Europe.

Again, my thanks go to TIM Group and all our other sponsors for supporting SoCraTes and encouraging their employees to participate!

Oh, by the way, are you curious now? Please feel free to have a look at

Joda Time? You might be overusing DateTime

We generally prefer to use Joda-Time for our date and time representation. Its immutable objects fit our house style, and the plusHours, plusDays etc methods usually produce much more readable and maintainable code than the giant bag of static methods based on Date and Calendar that we had before. Throw in easy construction from components, thread-safe parsers and formatters, a richer type catalogue for representing date-only, time-only, timezone-less values and integrated conversion to/from ISO-style strings, and working with date and time values becomes more comfortable and less fragile.

This snippet is fairly typical:

DateTime now = new DateTime(2015, 4, 13, 9, 15 /*default timezone*/);
DateTime laterToday = now.withTime(17, 30, 0, 0);
DateTime tomorrow = now.plusDays(1);
DateTime muchLater = now.plusMonths(6);

In principle, a DateTime contains a date, a time and a timezone. These three correspond to an instant- a number of milliseconds since the epoch, 1st Jan 1970 00:00 UTC.

Actually, that’s not quite correct- there are some date/time/timezone combinations that don’t correspond to an instant, and some that ambiguously reference multiple instants. This occurs when the timezone includes rules for daylight savings time, producing gaps where the clocks go forward and overlaps when the clocks go back. (Consider how you would interpret “2015-03-29T01:30:00” as London time, or “2015-10-25T01:30:00”).

Here’s a nasty thing that can occur when you use DateTime, though. If you wrote this:

assertThat(new DateTime(2008, 6, 1, 14, 0, 0) /* Europe/London */,

Then (if your system timezone is “Europe/London”, or you explicitly passed it in as the parameter) you would get this highly unhelpful failure:

Expected: <2008-06-01T14:00:00.000+01:00>
     but: was <2008-06-01T14:00:00.000+01:00>

Continue reading