Change is hard (for me)
This is my first blog post in 6 years, so I expect I’ll be a bit rusty. Hopefully I’ll get more chances to write and the rust will brush off. Unfortunately, I’m going to start with a post about my limitations — a less than auspicious start.
I like to think of myself as a software development coach. The last six years have showed me just how true that is — I’ve come to realise that what really excites me in software development is delivering better teams and better individuals, and that to a large extent the project we’re involved with is a vehicle providing learning opportunities. While there was a time when I revelled in the delivery itself software development has changed and so have I (there are multiple opportunities for blog posts in those statements, but not today). Ironically, it’s taken me quite an extended period of discontent and outright unhappiness to reach be able to make a clear statement of what I really enjoy, and I’ve still not reconciled that with what I actually get paid for.
I work in a bank. For sundry reasons, including my own lack of clarity, I’m not in an explicit coaching role. My time’s split between (85%) coordinating cross-business unit architecture for a large program of work, that I’ll program A (think business analysis, chairing architectural committees, raising and tracking issues) and (15%) being a peer on a team of experienced developers and data modellers, that I’ll call project B.
On the surface that project B role looks ripe with coaching opportunities, but it hasn’t turned out that way, and I’ve been wondering why. First, I’ve discovered that I’m reluctant to “coach” without specific permission, which I don’t have. Although there are things that I’d do differently I’m a relativist rather than an absolutist — I’m sure there are many ways of doing things that will lead to a satisfactory outcome (and of course many that won’t) and I don’t have the position or the desire to try to impose “my” way on a team of peers.
Permission could arise in a couple of different ways. In the past I’ve been specifically engaged to help solve a particular problem or guide a particular change — a typical GROW model, with a goal, a current reality, and obstacles (some obvious, some yet to be discovered). In this context permission, at some level, is explicit in the engagement, though you might have to work on getting permission on other levels. I’ve also been a career coach for individuals — the goal and the current reality are less well-defined to begin with, but again the permission is explicit. In a team of peers my impulse is that I need to wait until the team identifies some obstacle (hopefully one I have some experience with) and then I can ask for permission to coach past that obstacle.
The interesting part (and sorry for taking so long to get here) is that the first obstacle is how to identify obstacles. Not for me as an individual — I’ve already mentioned that there are things I’d do differently — but the things multiple people on the team have identified as obstacles. This requires some level of transparency — I need other people to be willing to share their view of the obstacles, but I suspect they’re in the same situation I’m in — they’ve identified things that they’d do differently but they’ve not raised them because it’s only a single person’s perception.
Writing this post makes the first step self-evident — put a stake in the ground as a personal impression of our obstacles, so that I’m at least being personally transparent. Then talk to people about how they feel about that perspective — maybe they confirm my impressions, maybe I learn new perspectives on the project. Not a bad outcome in either case, but it triggers my natural insecurities (although all this makes sense in principle, I don’t like stating opinions that turn out to be unfounded). So, aside from insecurity, why haven’t I already done that?
It turns out that, at least for me, assigning “responsibilities” is a powerful constraint, intended or otherwise. I know I’m responsible for the architectural outcomes on program A, I’m fairly sure I’d be held responsible for technical choices on project B, and I don’t feel responsible for the structure or organisation on project B (at least no more than anyone else). Sharing my impressions in a constructive way, and then talking to other people about them, feels time consuming and not aligned with my “responsibilities”, and I think that’s one reason I’ve shied away from it.
Why bother writing any of this? On the surface it’s just a laundry list of some of my shortcomings. I’m writing to help me clarify my own thoughts, and to share, because I doubt I’m the only person with feelings like this. After years of having explicit permission to guide change I’m back as an average team member, and all of a sudden I see how hard it must be for teams to “self organise”, and for individuals who want to champion change without a mandate. If you recognise some of the feelings or situations I described then now you know you’re not alone (and I do too). I hope this makes me a better coach in future.