In Conversation: Rick Giner & Andrew Murphy, and Inga Pflaumer with Chris Lienert

Opening Remarks and Pair Programming
Chris thanks the speakers and asks what they didn't get to say. Rick discusses his chickens and emphasizes using known techniques when facing new problems. He shares an anecdote about resistance to pair leadership and how it ultimately improved productivity and culture.
Leadership and Strategy
Andrew discusses the dual roles of a leader: within their team and within the leadership team. He emphasizes building trust with senior leadership to enable experimentation and strategic flexibility. He also highlights the importance of aligning the team's goals with the company's overall objectives.
Pivots and Awareness
Inga expands on the concept of pivots, noting they can be any change in direction. She emphasizes the importance of being aware of pivots, as unintentional or unrecognized pivots can be detrimental.
Audience Q&A: Pair Leadership
An audience member asks about the logistics of pair leadership, including reporting structure and conflict resolution. Rick explains that line management was geographically determined for clarity and cultural sensitivity. Pairing focused on functional management and professional development.
Audience Q&A: Balancing Change and Stability
Another audience member asks about balancing frequent changes with the need for stability. Andrew suggests establishing a clear North Star goal to provide consistency while allowing flexibility in the methods used to achieve it. Inga emphasizes empowering teams to initiate changes, creating a two-way street for change management.
Andrew's Coding History
Chris asks Andrew about his coding history, prompted by Andrew's use of "goto" in an example. Andrew recounts his early experiences coding on a ZX Spectrum, including transmitting programs over radio and storing them on audio tapes.
Lessons from Pairing
Chris asks the panel what they learned from pairing that they apply to individual work. Rick discusses gaining empathy and diverse perspectives from working with colleagues in different regions. Inga highlights the importance of pairing for PR approvals and bus factor safety. Chris shares his experience with pairing culture improving team productivity.
Benefits of Pairing
The panel further discusses the benefits of pairing, including context sharing, time efficiency, and even making tedious tasks more bearable.
Loneliness at the Top and Support Networks
Chris asks Andrew about the loneliness of leadership. Andrew emphasizes the importance of seeking support from peers outside one's immediate discipline, both within and outside the organization. Rick agrees and highlights the value of mentors and communities.
Communication and Pairing
Chris shares an anecdote about communication challenges and how pairing could improve team cohesion. He then asks the panel about methods for giving people agency.
Giving People Agency
Inga discusses linking agency with performance management, advocating for a "volunteer or be voluntold" culture where individuals take ownership of tasks and are measured on their delivery. She emphasizes the importance of clear metrics and balancing agency with the need for results.
Closing Remarks
Chris thanks the panel and concludes the session.
Thank you very much, all three of you, for inspiring talks.
Before I throw to the audience, first question is, what did you not get a chance to say that you would like to have?
Rick, I'll start on the end.
Firstly, as a rule, I'm really good at looking after chickens.
I just had a rough year and lost seven or eight that year.
Half of them happened to be Andrews.
I think the takeaway from our talk really is when you're faced with a problem, that you're not sure how to solve, look back at what techniques that you, can perhaps employ.
Think patterns and frameworks that you do know.
But specific to pairing, I just want to share an anecdote.
A lot of the time when we talk about pair programming, there's sometimes resistance to this.
Why would I put two people on the same problem?
And those people that I think have done effective pairing know that actually having two people pair together, it doesn't decrease productivity.
It can really help with productivity.
It certainly, in the long run, helps with a better product and a better outcome, which means a lower cost.
But even knowing this we had resistance when we wanted to put two people into a leadership role.
There was, from senior engineers, from the CTOs saying, can we really afford to have two leaders?
But we were very quick to show, that not only did the productivity go up but it, we also created this really nice safe space where we didn't all need to be leaders with 15 years experience to do something.
So it paid off in a better culture as well as overall performance.
Using maybe that, that TDD mindset if you ever wanted to do something like this.
Try with a small experiment and, define what, a pass or a fail might look like and give it a go because you're likely to meet resistance when applying new, and, novel, patterns to stuff.
Sure, following on from what Rick said, and Inge, you touched it, and a couple of the people this morning touched it, there's this idea that you're, as a leader, you're sitting in two teams.
You're sitting in the team that reports into you, the people that report into you, but you're also sitting in this team of leaders.
And that's relevant to the strategy situation, because a question that often gets asked when I talk about this kind of stuff is, how did you get your boss to agree to not come up with a three year strategy?
And part of that is the, trust that you built with the people that are also in the senior leadership team.
So this especially applies if you are the most senior technologist, but it it, also applies if you are not.
Seeing yourself as part of the team of leaders, seeing yourself as driving the outcomes that are the best for the business through technology is the way that you build trust with those people that allow you to do these experiments and take these approaches that maybe they're not 100 percent on board with.
If you're taking this approach that it's my team and I'm going to protect them from the rest of the organization, you're not leading yourself into that mindset of how can I help my team help the rest of the company reach their goals in a way that suits both the team and the company.
Like that, way of thinking and having this idea that I'm a leader first, that's my first team, I think is really what you need to build the trust so you can do the stuff that we talked about.
For me, I think, my, my talk was heavily focused on technological pivots, but you can have all sorts of pivots.
Splitting the team into two different teams is a pivot.
As long as you had a direction and now you're changing the direction, it is a pivot.
And you need to be aware of this because, of all the pivots that I mentioned, I didn't mention a pivot when you pivoted and you didn't know about it.
That's the really bad one.
Right, thank you.
Any audience questions at this stage?
I just got a question about, the pair leadership.
Because I'm not sure, can you give example about how you get the reporting flow, the daily, if, say for example, you have conflicts with each other, how you resolve that, and how the reporting line, up and down, how that works.
Just give brief example.
Yeah, absolutely.
It is really important for the clarity of employees that they know who their line managers are, and I think that line management, was, very clear and the way that we do that is, geographically.
So line management is done by the leader that is looking after your region, and that's, for a number of reasons, but, culturally I think there's a lot of sensitivity, at different, expectations, culturally and geographically around, around things like, leave and entitlements and, so on.
But also there's that availability and that cultural sensitivity when there are conflicts, perhaps, on the team.
Sometimes there's conflict between people from different regions.
And again, that's where coming together as a pair, maybe not initially, speaking to people individually, and then bringing people together, is, important.
So really the pairing was much more about the, the management of the function, I think.
And perhaps for professional development, but when it came to sensitive line management issues, it was very clear that it's handled by someone local.
I think there was, there another one down the front?
Kevin?
Yeah, Diana, you can get there.
Other side.
My question's about the intersection between the test driven leadership and the pivot theory that we heard about in these two talks.
As a leader myself and having observed other leaders face these kinds of dilemmas, feedback that leaders often get is, stop making so many changes so quickly, we need stability in order to do our jobs and to build psychological safety.
And this can prompt leaders to avoid making changes until they are impossible to ignore or inevitable, and then they become forced pivots with, with no freedom about the direction.
So I was wondering, do you have any thoughts or advice on how to keep these changes small, and to maybe foster a culture of tolerating small leadership experiments, frequently?
Yeah, I think a really important aspect of that is, is that North Star that I talked about and, the communication around what that means.
The, this idea of this is, the goal we think we want to get to now, this is the direction we're heading in.
This is, the outcome we want to achieve.
The way we get there might change.
The tools we use to get there might change.
The direction we head in.
If the wind changes direction we're going to, go with the wind for a bit, but then it changes direction again, and we've got to tack against it.
The way we approach the North Star might change, but that's still the direction we're heading in.
That allows you to, talk less about what we want to get change, and more how we get there.
That reduces change fatigue.
Because change fatigue is a real thing.
And managing people's emotions around that, and decision fatigue, and everything that comes along with it, is part of the job of being an effective leader.
So I think that would be my number one suggestion, is by separating it into the North Star, and the set of steps, you can still have this consistent narrative around where you're heading, it's just how you get there, changes.
I think my suggestion might sound a bit childish, but there needs to be a balance.
Because pivots should not always come top down.
As long as your team knows that, yes, the business may pivot and the road may change, but they also know that if we have a need to change, if we have a need to change our processes, if we have a need to change our ways of working, if we have a need to change our technological stack, we're empowered to do this.
Because it's a road that travels in both ways.
If it's always leadership making decisions and engineering just following the direction, you will have change fatigue.
But if you are empowered to also make changes that you feel are needed to achieve this North Star, this is very important and this is empowering.
All right, any further questions at the moment?
I have a brief interlude question for Andrew.
How long have you been coding that you used a goto in an example?
So I, learned to code at eight years old, on a ZX Spectrum.
I don't know if they ever made their way over to Australia.
Yeah, this, was a computer which, no, no joke, the computer plugged into your television through an aerial cable.
And the way you stored your programs on it was on tape.
Yeah.
Not digital tape, audio tape.
I had this very strong memory of taking one of my mum's ABBA tapes, putting a little bit of sticky tape over the write protection bit, and then using that to store my video games.
And you used to be able to transmit programs over radio, store them on an audio tape, and then load them into your computer.
Yeah, I, my first programming languages had goto as a core part of it.
Don't do it nowadays.
There's much better ways to do things.
Radio transmitted programming sounds a bit safe.
Was it back in the days of pirate radio, That was in the name, wasn't it?
What have you learned from pairing that you take back to working as an individual?
I'll start with Rick.
What have I learned about pairing?
As you've learned, things you've learned as you've learned how to pair that you take back to when you're doing something on your own.
I think one of the, so, much stuff to be honest because everything that we do is with someone else and I think every opportunity to work with someone else is an opportunity to learn.
So I've half of our business is based out of India.
I spend a bit of time there myself.
But by, by working, with, my colleague in India day in and day out, I've got a real appreciation for all of the different challenges that are there, both culturally, from the technology and the infrastructure.
And so there's, a deeper level of empathy, not just for, my peers, but my colleagues, that comes from having that diverse perspective really injected into everything that we do every day.
You got any thoughts on the same?
Any thoughts on pairing?
Something that occurred to me while you were speaking about how leadership is sometimes intolerant of pairing because it's a waste of time.
I have a solution for this.
Just require two approvals on every PR.
That's it.
Everyone will pair and leadership will immediately appreciate the importance of this.
Because unless someone pairs with you on a PR, there is no way they can easily approve it.
Sorry, I was just thinking about this all the time.
Because my engineers pair a lot, and I did not make them to do this.
It's an organizational rule around, to approvals for any PR.
It was like, oh, people don't pair in other companies, how do they do PR reviews then?
Yeah, I ended up leading a team where there was some strong pairing culture among some people in that team.
And it became our way of doing everything.
To the point that in a stand up, if someone at any point said, oh, I'm the only one that knows how to do this, it's alright, pairing opportunity.
Everyone else's safety was there enough that they could stand up and say, hey, I'd like to learn how to do that.
And it made an enormous difference for the productivity of the team.
But it is, from the management perspective, it is about safety, and not psychological safety, it's about bus factor.
If someone gets hit by a bus, someone else needs to be able to continue this work, so it is more secure from this perspective.
But it is also, I think, again, depends on the culture, but in my teams, as general rule, people at the stand up say, I'm going to work on this, and someone else can always say, oh, that's super cool, can I join you and work with you?
So I think, I'm not sure if it's a play.
But I'm going to think it's a play from now on.
And yeah, I actually think that pairing is an amazing tool that every business should encourage as much as possible because it is beneficial for the leadership, it is beneficial for context sharing, and it's beneficial for time.
And it doesn't, just have to be the challenging things that you need a really robust solution for either.
I was surprised, a few years ago when I found a team that had some really tedious, mind numbing work to do.
They were pairing on it.
It didn't occur to me at the time pairing was optional and most people would pair on challenging things, interesting things.
But it was so mind numbing that they didn't want to do it on their own.
And it was just a way of getting through the day.
Because you've got someone actually suffering alongside you and, they're turning it into actually a pleasant experience because you're, bonding over the frustrations that you're feeling.
And it didn't slow down the team at all because, if you're doing something really tedious, you actually slow down yourself anyway.
But you're doing it with someone, you're buoying each other up.
It's, so useful in, in many scenarios.
Andrew, it's lonely at the top.
What's that, sorry?
It's lonely at the top.
It's lonely at the top, yeah.
How does that, how does pairing help you?
Yeah, this is the thing, and this, is the nature of, hierarchies is that there are fewer people the further up the hierarchy that do the same job as you.
Like it's, just the nature of how those things work.
And it's really important to remember that, a lot of being a leader and being a very senior leader is finding support outside of your immediate discipline peers within your organization.
'cause there just, they're just are not that many.
And my last few jobs, I've, either been reporting into the CEO or, into the CTO.
So I've had either, no, no discipline peers or very few.
And finding ways and supports both within the organisation of people who are not your discipline peers but are your peers, and getting support from them has been hugely valuable for me.
There's a lot you can learn from people who are not technologists.
We're not special, we're just a discipline like any other and there's a lot of tools, techniques and support you can get from your product management peers and your design peers.
Even finance, marketing, sales, there's always something you can learn.
Like I've learned a lot from sales people about how to communicate well.
Because at the end of the day, sales is just communication and influence.
And so learning those tools and techniques and using them for good rather than evil has been really valuable for me.
So I think, it is lonely at the top, but broadening that sphere of who you think of as your peers, both within your organization and without, is a way to mitigate that.
Yeah, I think it's really interesting, because many of us will have, great bosses and leaders, around, and, that's, super valuable, but of course they're going to be very busy as well, so it's important to have this, a broader network, whether that's mentors outside of the organization, or whether it's communities, like Web Directions, there's, lots of different ways of getting some input and some support.
The difference that I find between, my mentors and communities and YouTube videos and books is that if you've got a pair, they are very close to everything that goes on.
They have the context and they have the availability.
That's not to disparage any of the other support networks that you absolutely should be going and looking for and need.
But they're never going to be as close as if you are actually pairing with someone and living day in, day out everything that you're doing.
And sometimes things go wrong, I can think at maybe around 4pm yesterday afternoon when something went terribly wrong in my work and I had to ping three different people to tell them that things had gone wrong.
If they paired more, if they actually were better gelled then I wouldn't have had to have the same conversation three times as I've had.
Are there any more questions on the floor at this stage?
I can't see very well over that way.
You'll need a really long hand.
If not one more from me then.
What methods do you use to give people agency?
Because the key to everything that we've talked about is that agency.
And Inga, if you could start.
I think, the amount of agency is bear with me for a second, part of performance management.
Because you should have as much agency as you want, as long as you can deliver on this agency.
Because in my teams I have this, that's a bit embarrassing, a culture of volunteer or be voluntold.
And it helps a lot because people know that if something comes up that they want to do, they will volunteer for this.
And they will get agency to deliver, but it will be a performance metric.
I don't support the culture of everyone just run away and do whatever you want, and if you don't deliver that's fine, you'll try next time.
I, I have to, as a manager, as a leader, I have to deliver, I have to make sure that the product gets built.
As a result agency, anyone can have agency, as long as this agency is then transformed in the actual delivery.
So it is a part of a metric that you apply to your team.
You volunteered to do this.
Amazing.
How did you go with this?
How, obviously you need to know beforehand how you're going to be measured.
That's a part of a culture again.
But people tend to pick up agency, at least in software engineering, I haven't met that many people who would be like, oh, no, I will just sit in my corner and do nothing.
People generally want to explore, people want to, join the community, people want to participate in solutions, they want to have agency.
The question is always how much agency you can actually manage.
And that's where the interesting things start to happen.
All right, I think we'll wrap it there.
Thank you very much Inge, Andrew and Rick.