June 15, 2018

Weeknote 3

I missed a weeknote. Interesting things happened but I went through a period of being down and having crippling hayfever.

I learned lots about leading in an agile environment

A difficulty with working at GDS is how exposing collaborative ways of working can be. There are lots of potential triggers, like teams expecting pair programming and not building in ay recharge time. There are lots of things one has to work with, such as being overwhelmed by bright office lights.

I’ve learned to work around these things. Finding recharge time can be a question of seeing yourself as being in the team rather than of it. Bright office lights can be mitigated by polarising sunglasses, and hopefully by something more stylish in time. And I’ve learned a lot along the way.

We seem to learn more from unpleasant experiences than from enjoyable ones. It’s hard to know why something successful works without asking a lot of questions, and some questions risk surfacing lingering issues and creating drama. I suppose that the people we storm with can become deeply respected and appreciated friends as things normalise.

I’ve been talking to quite a few Delivery Managers and Product Managers, and I shadowed one of my favouritest Delivery Managers. I’m fascinating by the agile team structures that we use, and their deliberate structures. I had always felt that stereotyping people into roles was oppressive, and would be suffocating to roleplay. But these structures work because people divide responsibilities—not because people are necessarily lacking in relevant abilities. With divided responsibilities comes more focus, clearer lines to collaborate along, and thus more effective teams. When you understand your role you can subvert it in ways that work for you (for instance, some Delivery Managers take a keener interest on the Product side of things.)

I’ve been talking to quite a few Delivery Managers and Product Managers, and I shadowed one of my favouritest Delivery Managers. I’m fascinating by the deliberate structures in our agile teams. These structures seem to work because people divide responsibilities, even though people might not be lacking in skills.

A good example is that Product Managers sometimes need to be “a product arse”—very outspoken in advocating for the product. This could ruin morale or burn the team out, except that other roles are there to speak out for what’s humanly and technically possible. When you can count on the other roles in a team to complement your role, you achieve more together.

I had always felt that stereotyping people into roles was oppressive, and would be suffocating to roleplay. But these structures work because people divide responsibilities—not because people are necessarily lacking in relevant abilities. When you understand your role you can subvert it in ways that work for you (for instance, some Delivery Managers take a keener interest on the Product side of things.)

GDS ask interviewing Developers about experience of leadership. I kept quiet because it isn’t necessary for mid-level, and I doubted my experiences in smaller orgs with informal leadership was relevant. At this stage: a lot of that was the stereotyped self-doubt that marginalised people get when applying for roles. The missing ingredient in applying my leadership experience to GDS wasn’t “how does one lead?” but “why do we have roles?”

This is all opinion. Much of it is influenced by others; the exact understanding is mine. I think it’s a way forward. As I learn more of my triggers, and keep finding new opportunities to exercise myself in different team situations, I’ll get closer and closer to being a credible tech lead. This might take a long time, but that’s particular to this way of working, and if I wanted I could find a different organisation that I could lead in right now. But GDS’s ways of working care about people, deliver great products, and are worth my effort to learn.

The other things I’ve been doing

I’ve said all that without mentioning what I’ve actually being doing most of the time! I think I’ll talk about that next time. I’ve done: