Translating Tech Tactics to Leadership

Introduction: The Hawthorne Effect and the Importance of Attention
Rick Giner starts with the Hawthorne effect, illustrating how paying attention to employees significantly impacts their productivity. He emphasizes the importance of asking for feedback, celebrating successes, and providing constructive criticism to make employees feel valued.
Transferable Techniques: From Engineering to Leadership
Rick highlights the need for leadership shortcuts, drawing parallels to using crib sheets and copilot in engineering. He introduces the concept of transferable techniques, using the example of a BA transitioning to a program manager and leveraging existing skills like backlog creation and prioritization.
Defining "Technique" and Its Power
Andrew Murphy defines "technique" as a way to apply expert skills to opportunities, emphasizing the generic nature of techniques as their strength. He lists examples of technology techniques like Agile, Continuous Integration, and Version Control, proposing their application in leadership.
Pair Programming and TDD in Leadership
Andrew introduces pair programming and TDD as the focus techniques, explaining how their core concepts can be applied to leadership scenarios. He encourages thinking about applying other known techniques in different areas.
Pair Programming in Leadership: A Case Study
Rick shares his experience as a young leader, recounting a project where he tried to solve everything with coding, neglecting other leadership responsibilities. He then introduces the concept of pairing in leadership, detailing his partnership with Rav and the benefits of their diverse backgrounds and perspectives.
A Day in the Life of a Leadership Pair
Rick describes a typical day in his pairing with Rav, including stand-ups, planning, attending meetings together, debriefing, co-creating communication, and socializing. He emphasizes the importance of shared knowledge, playing to strengths, and cultural sensitivity.
Findings and Benefits of Leadership Pairing
Rick discusses the positive outcomes of their leadership pairing experiment, including increased capacity, built-in contingency, robust output, positive impact on clients and employees, and increased support for leaders.
Pairing Beyond Senior Leadership
Rick explains how pairing has been successfully implemented in product teams and as a support system for returning employees, highlighting its effectiveness in diverse geographical teams and for gradual returns from parental leave.
Test-Driven Strategy: An Alternative to Waterfall
Andrew discusses the challenges of traditional waterfall strategy planning and introduces the concept of test-driven strategy. He explains the TDD cycle (red, green, refactor) and its applicability to leadership and strategy.
Benefits of TDD in Strategy
Andrew outlines the benefits of TDD in strategy, including small batch impact, enhanced dialogue, risk mitigation, and the importance of emotional intelligence. He emphasizes the need for communication and collaboration in a TDD-driven strategy.
Applying TDD to a Mobile Strategy
Andrew shares his experience applying TDD to a mobile strategy at a scale-up company. He describes defining a North Star (multi-platform approach) and experimenting with different solutions in the first quarter. He emphasizes the iterative nature of the approach and the ability to adapt based on the results of experiments.
Conclusion: Leveraging Existing Techniques for Leadership Challenges
Andrew concludes by encouraging the audience to leverage their existing "bag of tricks" and apply known techniques to new leadership challenges. He emphasizes the complexity of leadership problems and the value of experimentation and iteration in finding solutions.
Okay, I'm gonna start my story back in 1924 at the factory of the Western Electric Hawthorne Works in Illinois.
There was a guy called Elton Mayo that was there playing with a light switch.
In fact, he was doing a little bit more than playing with a light switch.
He was doing a series of experiments to find out if the physical space that people worked in affected their performance.
So he turned the brightness of the lights up by 10 percent and the performance of the workforce went up by 10%.
Or maybe not 10%.
It went up.
It went up.
So he turned the brightness up a bit more.
And the performance went up.
He turned the brightness down.
And the performance went up.
Something a bit funny here.
I feel maybe it's not to do with the light switch.
So he did a few other things.
He increased the number of breaks that the people had.
And performance was up.
He decreased the breaks.
Performance was up.
What's going on?
So he packed his bags, put his lightbulbs away and left, and performance went down.
And what he had discovered, known as the Hawthorne effect, is that when people feel like they're listened to, when people are paying attention to them, then their productivity goes up.
And when you don't pay attention to your co workers They don't feel as valued and their productivity goes down.
Now this is really interesting to learn as a leader because it means that all the things that we implicitly know about paying attention to our workforce actually make a really big difference.
When we ask someone how they're doing, when we're asking for their feedback, when we're celebrating their successes, or when we're giving them constructive feedback, we know that this is actually helping our co workers feel seen and therefore be more productive.
But how, as a new leader, are you going to learn a fact like that?
Well, as some of the previous people that have spoken today, Ben and Andrew, you both talked about frameworks, about mentors, about learning stuff.
And, you know what?
We are all going to have to learn a bunch of new skills as we become leaders.
But I'm an engineer, really.
And I like a shortcut, right?
I do want to do all the learning, but I want to do something quick now.
What are the shortcuts that I can find now?
When I was learning Java, I had a book on my desk full of dog eared little corners so I could quickly find what I need.
When I was learning regular expressions, I had a crib sheet stuck to my cubicle.
Now when I write code, I have a copilot.
What are the techniques that we can use as shortcuts for leadership?
Well, Andrew and I think that there's quite a lot.
There are things that we already know as engineers, which are transferable techniques to leadership.
Let me explain what I mean.
A few years ago, one of, our program managers came to me.
She was relatively new into the program management space.
In fact, it was her first program management role.
She'd been a BA for many years, and she'd learned a bunch of techniques around her BA practice, but program management was very different.
She was no longer looking after a single product working on a single team.
She now had many teams, multiple stakeholders, all kinds of different responsibilities.
But she had realized that the skills she learned as a BA were suddenly really useful to her as a program manager as well.
She knew about creating a backlog of work.
She knew about slicing those items in the backlog small, about prioritizing them, about maintaining a WIP limit.
And very quickly, when she realized this, she went from being overwhelmed by the enormity of this new role to comfortably knowing how she can start to make an impact effectively.
And so we're gonna talk about some techniques which we think everyone in this room can do the same as they move into their leadership roles.
So Rick's said the word technique, we've had Andrew and Ben use phrases like framework.
What do we mean when we talk about these things?
What does the word technique mean?
Because if we're going to go through this, we're going to analyze this and spend some time on it.
I'm a fan of reductionism.
I really like to go, let's look at the core of the thing we're talking about, drill into it, so we can then go out and look at other ways it can be applied.
So with the technique, really what I'm saying is we've got a, an opportunity.
That opportunity could be a new feature we want to build, it could be a new strategy to implement, it could be a new business line we might be investigating.
But it's an opportunity, somewhere where we can add value potentially.
And then we've got a bunch of experts that can help us with these opportunities.
These could be people who are program managers, it could be software engineers, it could be tech leaders.
It's people who have particular skills.
So a technique, all we're meaning is a way to take these opportunities and apply those experts to that opportunity to give us this particular outcome.
Pretty generic way of explaining technique.
But that generic ness is the power in what we're talking about.
So a lot of these techniques you probably Heard of some of these or most of these.
These are things we do in our lives, in our professional lives to build software, to work with technology.
I'm not going to go through them all, things you've heard of before, Agile, Continuous Integration, things like Version Control.
These are technology techniques that we use for building software.
But our hypothesis is if we can take some of these techniques and apply them in other areas, such as leadership, we can give you that shortcut Rick was talking about.
Rather than learning an entirely brand new framework, an entirely brand new model, how can we take something you already know and apply it in a situation that you're not sure how to solve.
What of these techniques can we take and apply to leadership?
The two we're going to go through today are pair programming and TDD.
And we're going to show you how the core concepts of both of these can be applied in a leadership scenario.
Rick's going to go through pair programming, I'm going to go through TDD, but I do want you to start your brains thinking about these other techniques and maybe where you could apply them in other areas, like Rick mentioned with the BA moving into program management, those techniques of backlog and slicing.
How can you apply those techniques in other areas?
So we'll go through these and then hopefully in the Q& A at the end, the panel question, we can go through some more if you've got any questions.
Okay, so my first job as a leader, I was relatively young, certainly quite inexperienced in leadership, and I found the role quite isolating because I wasn't surrounded by very many great leaders.
I was given the job not because I was great at leadership, but because I was good at coding, and that was part of my journey.
So when it came to being a leader, I was out of my depth.
There was one particular project that I remember.
At the time I was looking after four, maybe five different teams in a company and one project had, an immovable deadline and it was not going to hit that deadline.
And it was building a micro site for a product demo and it was going to be important.
This guy called Shane Warne was going to be there.
I don't know who that is, but he's apparently a big deal.
And the company really wanted to make sure this thing went out on time.
And the thing that the team was struggling with was the UI of this site.
Now, back in the day, I used to be quite good at front end engineering, and I saw how they were struggling, and I thought, you know what I can do?
I can go in there and help them with the code.
So I spent two weeks picking up stories, smashing it out, and the team got all of their work done.
And I thought success!
I've helped the team.
I'm a great leader, but just like AJ was saying before, this is the sort of thing that a leader needs to delegate.
I was not a multiplier like Ben was suggesting we need to be.
I was an adder.
I was doing stuff.
So whilst I was helping this one team get their stories across the line, there was another team that was waiting for me to unblock some important stuff that now meant that they couldn't do their work and they were stalled.
I had executives waiting for me to sign off on budgets for training, and I had people waiting for that training, and they were both pissed off at me as well.
There was some dysfunction happening on a team that I hadn't even noticed, let alone gone in to try and help do, because My tunnel vision, I was working in a siloed way with one team.
This was not the way that I needed to work.
I shouldn't have tried to solve everything with JavaScript.
But looking back, what techniques could I have used, which I already knew?
Well, pairing is one that came to mind.
Most people here know what pairing is.
It's where two, usually two, engineers come together, work on something together.
And they bring different perspectives, different viewpoints, and they enrich the quality of the work, by working together.
Well, Everest Engineering, the company I work for, is a consultancy.
We typically have about 60 different clients and projects on the go.
And that's spread across three different business units.
And we have set out to have, leading each of these business units a pair of leaders.
So I'm going to tell you a little bit about that.
This is me and Rav.
I love Rav.
He's my pair.
He, we do everything together.
He's there when I make mistakes to catch me.
And I'm there for him.
We have a lot of fun together.
We also compliment each other really well.
We come to the role with different perspectives and experience.
I come from an engineering background and Rav comes from a product background.
We're both now leaders.
But our diverse backgrounds mean that we can actually help look at problems in different ways and support our teams in different ways.
I'm based here, RAV is in India and we have a mixture of clients all around the world as well as team members all around the world.
So we bring a diversity of geography and culture.
We're also of different ages.
Rav is about 10 or 12 years my junior.
So again, it's another diverse way of thinking, that we can bring into the leadership role.
And of course, being in India, there's a time zone difference as well.
So, this brings a lot of different advantages.
Let me just talk you through a typical day, so maybe this can clarify what we mean by the pairing.
So we start each day with a stand up.
Well, I don't start my day with a stand up because it's about two o'clock in the afternoon for me, but when we first get together, we have a stand up.
And that's to talk about all the things that have happened whilst we've been offline is to talk about what's coming up in the day.
So we do our planning throughout the day.
Now, if one of us really needs to dive deep on a thing, then that needs to be taken into consideration.
I don't have the capacity to go to all of these meetings with you today.
I've got a thing going on, but the other person can then step in and help adjust and free up the time, make sure the things that need to get done still get done.
Then we try and attend all the important meetings together.
So we know what's going on across our portfolio of clients and projects.
And we debrief often, whether we've been in that meeting or not, we get back together and we talk about what did we think about that, what new information has come out of that, what new jobs are we going to do?
And of course.
A lot of problem solving that comes out of the days works.
When we do then need to communicate.
We co create that communication because it's very important for leadership to be of one voice on one tone as well.
And of course, we want to be sensitive to different cultures and on diversity as well.
But it's important that we co create the communication that we put out to the business.
And finally, we socialize.
Every day, we make sure there is time to just hang out, to laugh, to spend time together, dare I say it, to play sometimes.
It's very important, I think, when you're in leadership positions to make sure that you do have time to enjoy things too.
So we've been doing this experiment well, I guess it's always an experiment, but it's, we've reached some conclusions.
We've been doing this for, over a year now.
And there's a bunch of findings.
By playing to our strengths, we've improved our management of risks and increased our capacity.
So, because if there's an engineering problem, I can lead on it.
I could spot that quickly and I know how we might be able to solve it.
If it's product, Rav can lead.
If it's to do with, a local thing happening here, I can take the lead.
We bring all this different diversity so we can play to our strengths, which we do easier.
Leadership is a diverse role, and quite often when you're always doing new things, it's slow and it's hard and you miss risks.
So what we found is when we were individually managing projects, we could each manage around four or five projects.
Now between us, we manage 20.
So we've doubled our capacity by playing to our strengths and getting ahead of those risks.
We've got built in contingency by always sharing our knowledge as well.
So when Rav decided he wanted to go and get dengue fever for three weeks, It sucked for him, but not so much for our clients.
And when I wanted to take a couple of weeks off to spend with my daughter over the school holiday, Rev was there to keep everything ticking over.
It's not often that as leaders, we can actually step away and completely switch off, but if you do everything with a pair, it's not such a big deal.
Our output is more robust because we've got that diversity in the role.
I think that speaks for itself.
We also noticed good impact, effective measurable impact on the people that we work with.
So our clients now have more expertise and more availability from us.
And by that I mean if the client has a product question, the leader that's looking after their account.
Well, that's Rav that can lean into that.
Of course, I'll be there to support him, but there's like this different expertise that really helps us get to the nut of a problem quickly.
And because of the time zone, we are much more available than either one of us would be on our own.
Our employees are now getting more appropriate leadership because we are more culturally sensitive, and also because of that diversity of experience.
So, of course, there are still some regional line management situations in play, but by and large, our employees are better supported by a diverse leadership team.
And as leaders, we feel more supported as we contribute to the work that we're doing and as we learn together.
Just because there is an expert that is leaning in doesn't mean the other person isn't still learning by being there, and doesn't mean that they can't still try some things out as well.
So, as a leadership group, I think we're much better off.
It's a commonly repeated idea that leadership is quite a lonely position.
You know that phrase, it's lonely at the top.
It doesn't have to be if you're always working with a pair.
But this hasn't just been with senior leaders.
We've also done this on our product teams.
So where we've had a team of seven or eight people, we've had two leaders that pair in that leadership role.
And again, this has worked well when you've got a diverse geographical team.
Of course, there is still individual responsibility and authority that might be delegated, but a lot of that leadership activity can be done as a pair.
We've also seen this work well when we've had someone return from parental leave, and wanted to return gradually, one day a week, then two days a week.
In leadership, it's really hard to do that part time, but if you're going into a pair, you're actually much more supported.
So we've been able to take someone back into our leadership team on a time frame that works with them and the way that works with them.
And we haven't lost the benefit of all of their experience that otherwise we might not be able to have come back gradually.
Back to you.
I'm going to talk about strategy and how strategy is one of these really hard things to do in organizations, and we tend to do it in a way which is basically the waterfall approach.
I've had a lot of CTO type roles where I've been the most senior technologist in a company, being part of the senior leadership team, reporting into the CEO or the MD, and so technology strategy often fell to me.
And what would happen is the CEO would say something like, what's your three year strategy?
Tell me what we're going to do every quarter for the next three years to radically shift this organization.
How are we going to go from where we are now to a digital first organization or a product led company?
What's your three year quarter by quarter strategy?
This is taking a waterfall approach where basically what you're doing is you're planning everything out.
We know this doesn't work and yet this is the forcing function that happens often in companies.
And the reason why it doesn't work is because you focus on, quote, getting it right, which actually means fixing your idea of where you want to be by defining that exact outcome in every step along the way.
We used to do this in software development.
We used to say, okay, we're going to spend three months defining exactly what we're going to build, exactly how we're going to build it, exactly the classes and the database structure of every part of this.
And we get a month down the project and realize we got it wrong.
This same thing happens with strategy.
Because you spend all of this time planning, but stuff changes along the way.
You're not, you're not flexible to what's happening.
You're building a very brittle strategy.
And I've built a number of these over the years because this is what I was asked to do.
I was asked by my CEO to build these strategies.
I'll be honest with you, nobody ever even reads these.
A thumbs up in Slack when you post a document doesn't mean that person's read the document you posted.
So we're doing all of this work.
It doesn't work and nobody reads it.
So I joined, I joined a scale up company a couple of years ago that was going through a big transition that was scaling from about 20 engineers to 200 engineers.
And, I owned the, the mobile strategy.
So I owned the mobile application.
That was one of the things that I owned.
And, Like AJ alluded to in the beginning, I've never written a line of Swift, Objective C, or Kotlin in my life.
And yet, I was owning the mobile strategy.
But I thought to myself, there is no way I can plan this out by going through this whole process, taking months to plan out this mobile strategy, and then executing on it.
There has to be a better way.
There must be a better way for how I can build out this mobile strategy.
And so I did this thing that I often do, and what the whole point of this talk is, which is to go, okay, well, if I don't know the solution.
What's the shape of this problem and how can I find a solution in my bag of solutions that seems to fit this?
And I thought, okay, well I'm gonna, if, I'm gonna try this idea of test driven leadership, test driven strategy.
Rather than just trying to jump to the end, I'm gonna, I'm gonna start with a better approach.
Now, this is, leaders, Web Directions leaders.
I'm not gonna go through ten minutes on what TDD is.
But the basic concept, if you've never heard the term, is instead of writing your code first, you write tests first.
So you write a failing test.
That's what the red block represents.
You write a test that fails before you write any functionality.
Then you write the functionality that makes the code pass.
That's the green block.
Then you ask yourself the question should I refactor this, should I make it better?
And you go through this in a loop.
You write a failing test that, that, you don't have the functionality for, you write the functionality, and you refactor.
And you just go around in a loop.
If I break this down, you can start straight away seeing how this can be applicable to leadership.
Really what we're doing is we're going in that red bit, what's the smallest slice of what you want to do next?
And how do you know if you've done that well?
That's what the red bit is.
Define what you want to do and how you know if you've done it.
Then the green bit, which is do it and check you've done it well.
That's what green is.
And then the last bit, refactor, can you improve anything?
Does rework exist?
Is there somewhere where you've copied and pasted your code?
Is a good example of that.
So you can start seeing how when we take the core concepts of TDD and break them into something that isn't necessarily talking about code, but is talking about problems and solutions, we can start applying these concepts into strategy and into areas, elsewhere.
So why do we do TDD and how are those benefits applicable to strategy?
Well, it's all about small batch impact rather than going, let's define everything up front and then work through it all and hope we're building the right thing.
We bite off small manageable chunks that we know have impact.
And what that allows us to do is to effectively change direction if we realize we're going awry or if things change around us, if the market changes The other thing TDD does is it enhances dialogue between people.
Because you've got to talk to each other all the time.
You've got to define what these small bits are.
You've got to define how you know if you've done them well.
You've got to ask these questions about refactoring.
So by doing TDD, you're getting people to talk to each other a lot more.
You're getting them to communicate.
And the same can be true for a TDD driven strategy.
If you're doing these small blocks of work that you're constantly going through, you've got to talk to each other all the time.
You've got to communicate, you've got to ask questions and you've got to come to consensus or collaboration.
The other thing it does is mitigates risk.
If we're planning everything up front, then there's a whole heap of stuff that could go wrong.
If we're doing small Changes, small iterative changes, you're mitigating that risk because you're only doing a small change that only that small change can go wrong.
And if you realize you shouldn't have done that, you can just go back previously and head off in another direction.
And the other thing it does, we've had a few mentions of this, but really, emotional intelligence is a core part of TDD.
Especially if you combine it with pairing.
TDD and pairing are often put together in a technical concept.
The same can be true when you're building a strategy with these techniques.
If you're pairing on a strategy and taking a TDD approach, you've gotta be able to communicate and have high emotional intelligence between.
The people that are working on it.
So I took this approach when I was working at that scale up.
I said, okay, I don't know about mobile technology, from a technology point of view, but I know about strategy, I know about product, I know about all of these things.
So I paired with the people that knew what they were talking about from a technology point of view, I paired with the people that were, knew what they were talking about from a product to marketing point of view.
And instead of coming up with this three year, quarter by quarter strategy.
I defined two things.
I defined a North Star, and I defined the first quarter.
So the North Star was, we, basically this company, they, there was 200 engineers.
Do you know how big the mobile squad was when I joined?
Five.
This mobile application was meant to replicate the functionality of the entire web application.
So you had five engineers chasing the functionality that 195 engineers were building.
There's just no way that was ever gonna work.
And so that was the solution that I needed to come up with.
And I said, okay, well, the best way to solve this is that if we take a multi platform approach where mobile is just another, another platform we're building and every team owns their journey on both web and mobile.
That was the North Star.
Every team owns their journey.
On web and mobile.
Doesn't mean they have to do all the coding, but they own that journey.
They're accountable for ensuring that journey works well on web and mobile.
So that was the North Star.
Then the first quarter was, okay, well let's do an experiment.
Let's see how this could work.
Let's try embedding a mobile dev in another squad.
We tried that experiment.
Didn't work.
Didn't work because basically what ended up happening is that mobile dev just ended up doing all the mobile work.
If I'd have come up with that idea in a waterfall type strategy and gone that's the solution.
We're going to put that mobile dev We're going to have a mobile dev in every single squad and they're going to spread the knowledge out My fundamental first idea would have failed and the whole strategy would have failed But because I was taking this iterative approach and I try this experiment first my test failed And I knew I needed to come up with a different solution.
So I came up with a solution of, okay, well, the mobile, engineer doesn't sit in the squad, but they consult into the squad, did an experiment on that and that worked.
And so that was the strategy we kept going forward with.
So the exact details of that is not really the message.
Like you might be in a company where the first strategy worked, but the second one didn't.
So I don't want you to fixate on the details here, but this idea and this technique of.
In both Rick and I's story and his, BA to PM example in the beginning we were taking these techniques we already knew and applying them into scenarios we didn't have solutions for.
This is really what we're trying to encourage you to do is when you come up against one of these problems, which you've never seen before, which you will do as a leader.
A lot of leadership is coming up with solutions that are tricky.
The problems are complicated.
The problems are complex and convoluted.
Because if it was simple, chances are somebody would have solved it already.
So if it gets to you, it's because it's a complex problem.
And if you don't know the solution to that problem, look in your existing bag of tricks.
Try and find the shape of this problem.
Think about what that shape is similar to in your existing bag of tricks.
And just try that tool.
Try that technique.
It might work.
And it might save you a lot of time and effort rather than trying to come up with something yourself from scratch.
Thank you.