I've been thinking about my career over the coming years. A fork is starting to appear as it does for many others. Stay focused on the code? Or look to team lead and other management type roles? As part of that, I wanted to start exploring some open questions I have, with you dear reader. I’ve been thinking a lot lately about process and team efficiency. I’ve been on a few teams now in companies large and small. I've been on teams with a range of programming abilities - from expert to tester to non-programmer. So let me think out loud a bit here and share these thoughts – and I’d love for you to add any you have in the comments below.
Convention
Often when I’m on an underperforming team I think about jazz musicians jamming. There might be a person on the keys, a guitar, a brass instrument and the whole time they’re just jamming out. They know their chords, scales, keys, tempos, rhythms. They watch, listen and create magic together. They don’t stop and say ‘hey everyone we’re now changing to an A chord for four bars and then we’ll go to a fifth above that”. But, I see this a lot in software teams…
Conversation
A lot of talking what’s going on whereas this stuff should be automatic. These are conventions not being followed (or not existing), and conversation is taking place when it doesn’t necessarily have to. For example, think about tasks moving down a scrum/kanban board. We know tasks generally move left to right. Sometimes some columns form a todo list for different team members. Should you tell a team member the task is moving column, or do you just move it and let automated systems notify them? Should people be expected to also monitor their own column?
Another example - what if you assign someone to code review - should you tell them or let the Github/Bitbucket notification tell them? A developer knows what is expected when they receive a pull request. They know the expectation for turnaround time. They know the expectation of what is fair and what is not.
I once tried to introduce a notion of board to a team. The manager said that they didn’t want to be told to look at a board to know where things are at. But, this the very point of the board. They preferred conversation over convention.
Their preference, and a benefit to this flexible process, is that it more easily allows exceptions to come out and be handled. Agile likes to pretend all issues are equal but the reality is that most are different, so is trying to wrap a convention or process around them even feasible?
Finding Middle Ground
To me, this is a spectrum. Too much process, and you have a team that has problems. You have a team that doesn’t innovate on process. A team that is hard to join (because there is a lot of process to learn). A team that doesn’t do the best they can with tasks because they can’t fit that into the process (Been there…). On the other end, you have a team that has pointless conversations about stuff we just should know. Tasks take longer than they should because of all the talking about doing rather than doing. The challenge is finding the middle ground. And I think it’s different for every team. I believe its a function of the team’s makeup: in terms of tenure, seniority, technical ability and size. Briefly, I’d say that smaller teams gel better with longer tenure and similar seniority/technical ability make music the best, whereas larger, more diverse teams need more work to get their rhythm. Jeff Bezos is somewhat well known for his "two pizza" team rule, and I generally agree with that.
The question for that is still outstanding is what do you do when the team doesn’t agree on that middle ground, or leaders don’t agree with the team members? What happens when factors like the above are changing, and it’s time to change that balance of convention and conversation?
You hear the term “growth pains” a lot, and I think “balance struggles” is what is happening. A team didn’t take into account their conventions and adopting them more as the team grew or creating new ones that scaled. Should you preempt growth and work on a scalable process or solve it when the time comes? Once again, a balancing act is at play here, and once again, differences of opinions arise when trying to find that balance. At this point, I have more questions than answers, both for myself and for you, the reader. But what do I know would help? I think good or aspiring leaders should be aware of these challenges. This would allow for civil and productive discussions around finding the balances. Balances of convention and conversation and the free movement of that balance.
Being Explicit
Another question that comes is should the team be aware of this whole process? I used to argue that leaders should treat process as an open-source project internally. Open to hearing issues and accepting pull requests. Labouring the metaphor, process can have bugs that can be fixed, and can be rolled back after a new buggy version goes live. But in reality, the team never sees the whole picture. Taking the time to explain it would break any productive leadership abstraction. There's plenty of actions a leader can take for the better that their team may never understand. There should be some collaboration, because a good leader appreciates the insight into where the team sees issues. They should accept that insight and hear out ideas for changes.
Don’t Overthink It
I asked a mentor of mine to weigh in, and he said: "I have very rarely seen a team that actually understands what matters: Customers. You can easily get software folks spending forever focused on improving their own little world, and never actually improve things for customers (oh, they'll tell you it will help deliver faster, they'll tell you that the changes will help them long term help customers - never mind that, help them now and figure out how to make improvements at the same time)."
So yes, whilst it's fun to reason about these things and I've enjoyed talking about this with you, we mustn't forget the customer is central. Any process should aim to make their lives better, it is after all what we're there to do.
Hopefully with a bit more conversation upfront about all these concerns, your team can be making some sweet tunes sometime soon.