With 2018 on the horizon, I’ve started thinking about plans for the new year. That means changes that I’m making to my site, updates and rethinking my personal brand. It’s been around 8 months now since I started writing. I started off wanting my writing to be relaxed and then I’d see where it went. But now, I’m starting to think more about where I want to take it as the new year approaches.
My bio seemed like a good place to start. After all it is my mini-pitch of my unique take on the world. I never liked my bio because I didn’t have a good grasp of what my target topic (and reader) was. I knew I wasn’t interested in talking on this site about technical topics. Many people are already creating amazing tutorials, videos and blogs on programming and software. But, I’ve always known that the key to good software teams was not more technical skill anyway. I’ve been more obsessed with things like effectiveness. And are we doing the right thing, not only are we doing the thing right.
One of my favourite quotes from Drucker is:
“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.”
This is the type of thing that keeps me up at night. I’m not pondering whether migrating our product to Typescript might be a good idea. Because, those types of changes bring micro-benefits, not macro. They’re important, but they’re not going to, as Peter Theil would say: take us from Zero to One.
Our tools are always improving. But are we – software practitioners – improving as fast as the tech ecosystem that surrounds us?
With this in mind, I rewrote my bio as follows:
Amongst other things, I take inspiration from Peter Senge, and his magnum opus book: The Fifth Discipline. This might not be immediately obvious, for those that have read it, and definitely not for those who have not. Senge is a systems thinker. He’s an advocate for thinking about things as a whole. Senge, as I am, is interested in how we can setup the right ecosystem for problem solving. Senge’s book is about creating a “Learning Organisation”. This notion ties in nicely with what I’m interested in uncovering:
How we build high functioning, adaptive teams.
To do this we have to go deeper than most tech teams do. We have to do more than put in place a lightweight agile model. And resist the temptation to walk away, dusting our hands off, feeling like we’ve done all that we need, to create a great team.
Peter Senge’s 5 disciplines
Senge gives us some other dimensions that we can look at our work. Beyond the typical agile framework. The best way to look at these is by breaking down what Senge calls the Five Disciplines required to create a “learning organisation”.
Discipline 1: Systems Thinking
Thinking about things as a whole. Trying to avoid thinking such as: “I am my role” type thinking. You know, when you hear “that’s not my responsibility, that’s X’s responsibility”. It’s this type of thinking that hinders us from thinking about the broader environment in which we work. Which might be responsible for more of our outcome than we realise.
Discipline 2: Personal Mastery
The extent to which individuals are pursuing learning towards their personal Mastery. In order to be truly adaptive, our teams need to be pursuing what’s important to them. Their day job should help them towards their higher sense of purpose in some way, or they won’t be fulfilled. We also want high performers, experts in their field in order to be proficient.
Discipline 3: Mental Models
Mental models are our own ways of thinking. It’s what we think of our team, and of ourselves. Senge highlights the need to repeatedly challenge our thoughts and biases to grow.
Discipline 4: Team Learning
Learning, must be critical to a “learning organisation”. But Senge emphasises the purpose of team learning. Learning together. This could look like pair programming sessions, running frequent lunch & learn sessions. Anything that encourages curiosity and group learning.
Discipline 5: Shared Vision
This is more a question of alignment. In order to be a high functioning unit we must be aligned to the same goal. Aiming at the same target. But this means true buy-in, not artificial harmony.
Agile models and the 5 disciplines
After writing my Bio inspired by Senge I started recognising a pattern. That a lot of teams in the industry focus on implementing an agile framework only and little more. Most teams don’t venture into deep areas, like: motivations, desires or communication patterns.
I’m a big advocate for Scrum. But I’ve also written (and written some more) about the fact that when we focus too much on “following the rules” we risk losing the point. But, this is not the only problem. And that’s when you follow such a model, it seems to be harder to put in place other methods of thinking, too. Implementing other complimentary frameworks such as Senge’s five disciplines would often face resistance. With responses such as:
“That’s not a scrum ceremony”.
“That doesn’t align with the agile manifesto”.
“We’re already following a framework, why do we need another?”
Agile models address our process very well. But they leave bare other important aspects of building strong teams:
Are we listening to the emotional desires of our team? Are they fulfilling their personal mastery’s and getting satisfaction out of their work?
As a team do we have personality clashes between individuals? Are these causing communication breakdowns?
These types of issues will not resolve only within the ceremonies of an agile framework. Because agile tackles process, not humans and their behaviours and interactions. These issues are too complex to rely on only a retrospective and few post-it’s to address.
So, we need to ask ourselves, if we’ve got a good delivery process how can we take it up a notch? How can we start performing beyond our basic ceremonies? How do we dig into our deeper dysfunctions? And resolve our more pervasive, systemic problems. I think the five disciplines give us a great starting point. We can write those up on a board and begin to discuss them as a team. And figure out how we can challenge our own thinking beyond our basic agile framework.
So that we actually can go from Zero to One.
Latest posts by Lou Bichard (see all)
- Cloud Software Engineering Newsletter #22 (March Recap 2021) - April 7, 2021
- Is An AWS Certification Enough To Get You A Job? (Spoiler Alert: No) - March 30, 2021
- Which AWS Certification Should You Take First? The Definitive Answer. - March 15, 2021