Transcript
Henry Wilson: I want to start today with a thought exercise. I want you to think about what single skill makes you excel in your current job. I'm sure some of you are thinking about your technical skills, your ability to design architectures, to write code or to solve problems. Maybe some of you are thinking about your research skills, your ability to draw together information from different sources and synthesize it into a plan of action. I'm sure there are many other possible answers that you could have thought of. My view is that if, like me, you're a senior individual contributor at a large organization, the single skill which contributes most to your effectiveness in your role is influence. I would wager that's also true for any of you that hold senior engineering management roles. Let's talk about influence.
I'm a senior architect responsible for the teams in the BBC's audio backend. Just to give a flavor of what those teams do, they deliver the backend functionality for the BBC's audio offering. On BBC Sounds, the BBC's flagship audio experience where they serve an audience of 4.8 million weekly active users. On third party platforms like Apple and Spotify, where the BBC's RSS platform is responsible for 85 million content downloads a month.
Why Influence?
I'm sure some of you are thinking, why influence? There are many facets to a senior individual contributor role. Why do I want to talk to you about this one? I want to talk to you today about influence, because I've spent a lot of time in the last few years thinking about it. My career at the BBC has seen me move between different roles and different teams, from engineer to senior engineer, then principal engineer, and now architect. In those different roles, I've seen firsthand the power that good influence can have, and what can happen when influence is used in the wrong way. I've also found myself frustrated when I haven't been able to influence a decision in the way that I want to. Why couldn't I persuade that individual or group to adopt the approach I'm suggesting? What could I have done differently that might have led to a different outcome?
Another reason that I want to talk about influence is that it's about communication. Communication really fascinates me. Language is so powerful, so versatile, but also so full of nuance. I love exploring it and understanding how I can make better use of the potential power of my words. The English language leaves an awful lot of room for ambiguity, for accidental implication or for misunderstanding. Ultimately, while senior IC roles are very technical, they're also all about communication. The phrase individual contributor might imply that you sit in a corner on your own being awesome and smashing out contributions, but the reality in large organizations is that you spend far more of your time communicating than you do writing code or creating designs. Even the code that we do write and the designs and documents we create are forms of communication. Ultimately, we're all expressing and communicating ideas all the time in different ways.
Finally, I want to talk about influence because it feels particularly significant for architects. Now, not all organizations have architecture as a separate role from engineering. Some will use senior principal or other staff-plus roles to fulfill a lot of the same duties around technical strategy and technical leadership. At the BBC, architecture sits as a distinct discipline from engineering, which can lead to teams lacking understanding of what architecture's role is and being unsure as to how they should respond if their architect is telling them something they don't understand or is giving them direction that might not match the direction that their colleagues in engineering are giving them. The man in the picture here is the man none of us want to be and none of us want to work with. The architect in the ivory tower handing down their perfect designs, but devoid of context about how those designs will be implemented and become a practical reality.
They might have influence, but if they do, they're using it in the wrong way. The difference between the ivory tower architect, someone who is likely to be isolated, might be disliked and definitely won't be effective, and the friendly neighborhood architect who the team want to work with and who helps them solve problems is all about communication and all about influence.
What Do We Mean by Influence?
What do we really mean when we talk about influence in the context of senior IC roles? Let's start with this dictionary definition. There are some useful aspects to this, in particular around our ability to have an effect on someone or something, and focusing on the character, development, or behavior of that personal thing. As senior individual contributors, we're often trying to influence behaviors of people or teams, when we want to influence process or ways of working, or we're trying to influence the character and development of the software being built by leading teams to make good technical decisions. Influence is so key to these roles. Without it, it's really hard to be effective in the space. There are likely to be many different targets that you might be trying to influence in different situations. The teams that you have technical responsibility for, the senior leadership in your area, and other disciplines you work with, like product, UX, and architecture or engineering.
Influence for these roles is not the same as managerial authority. Managers still need the ability to influence their staff beyond just saying, I'm your boss, please do as I ask. Nonetheless, there is a reasonable expectation that if your boss asks you to do something, you'll probably do it. Senior IC roles can't rely on that. They need to build reputation with the individuals and teams they're trying to influence. That generally revolves around building relationships. One analogy which I sometimes find useful to consider when we talk about influence is to think of it as a catalyst. We can build our influence by nurturing our relationships, proving ourselves useful to the teams and individuals we work with, being measured in our steer and our interventions. This influence gives us power when significant decisions need to be made and can be used to push technical decision-making forward at key inflection points.
Takeaways
I hope if you give me the benefit of your time today, you'll be able to take a few things away from this talk. Specifically, I intend to give you some tools or techniques you can use to influence the teams and stakeholders you interact with. I'm going to cover my experiences using these tools in different situations. I hope you'll see some parallels with your own teams and projects. You'll ultimately be able to leverage something from this talk to be more effective in your own role.
BBC Sounds Re-Architecture
The project I'm going to focus on for this talk is a large-scale re-architecture within BBC Sounds, which was started around a year ago. This is part of wider org changes to move to the product operating model and start to embrace platform engineering. Why is this project important? Because the BBC needs to evolve its digital offering to stay relevant. The BBC's audio offering is a key part of the digital estate and we need to ensure that it's in a fit state to serve the audience. First, I want to cover the project context and the organizational changes at the heart of it. The previous team structure was organized around a product vertical for BBC Sounds. Within that vertical, a catalog team provided core metadata for available audio content. A business-led team consumed that metadata and defined the business logic which powers the BBC Sounds experience. That business logic was used to serve the audience-facing experience across clients on web, mobile, TV devices, and smart speakers.
With the move to platform engineering, this structure needed to change. Under the new structure, the catalog team would sit in platform and the previous business-led team would be split into two halves, one half providing platform APIs. The remaining part of that team would sit within the experiences area of the org, and the audience-facing client teams would also sit within experiences. What would that mean for the split of responsibilities for those new teams? The platform team would own core and personalized metadata with responsibility for creating APIs that describe the catalog of on-demand content, including podcasts, previously aired radio programs, and audiobooks, and live content, the BBC's stable of local and national radio stations. The experience team would own personalization and user experience concerns, building personalized responses based on user context, and owning the logic around experience-specific concerns, such as what content rails are presented in clients, and experience variants, such as the international mode which users are presented with when using the app on holiday.
Project Complexities
Given that high-level context, I'm now going to drill into some of the complexities around this project and the challenges and opportunities they present when looking at them through the lens of influence. On the technical front, there were various complexities in the BBC Sounds backend landscape to contend with. The technical estate was complex, consisting of over 40 separate microservices with varying degrees of team knowledge and documentation. This is a very zoomed-out view of the estate, just to give you a little flavor of the number of connections and the number of dependencies between different microservices. Some of these key services lacked separation of concerns, mixing personalization, in particular details of user activity, with core API responses. This included the program metadata service, which I'll come back to a little bit more later on. Let's think about those system characteristics, complexity and choices about separation of concerns. We saw in the dictionary definition earlier that influence is about our ability to have an effect on the character of people or things.
Persuading teams to revisit design decisions requires influence. The original estate design prioritized performant responses rather than service decoupling. Additionally, inter-service communication was handled via an RPC implementation using Thrift, built using Finatra and Finagle, which are no longer actively maintained. There was also a desire among platform engineering leadership to move away from the tech stack currently used in the estate. Existing services were built using Scala and there was a strong desire to move towards this tech stack that was more commonly used at the BBC due to issues with recruitment, retention, and knowledge sharing. Through our influence lens, this second complexity is about behavior. If we're seeking to change the day-to-day behaviors of a team who are used to using a given set of tools and ask them to learn and use something different, understandably there could be some reluctance to make that change, and this is where our ability to influence becomes key.
The project also had social complexities. The team had previously operated using a monolithic team structure. There were three engineering teams consisting of 20-plus engineers across dev and test but they'd operated as one large team for over 5 years. There was also an inconsistency around buy-in levels within the team. Attempts to split the team had been attempted before and resisted, and not all members of the existing team were in favor of a split either from a technical point of view or an organizational point of view. Both factors ultimately pointed to a need to try and increase buy-in in order to help with morale and ensure progress on the project. Most social complexities are ultimately about our ability to influence behaviors, and from experience these situations can be really tricky. People problems are almost always harder than technical problems. Finally, there were complexities on the operational front that we needed to consider.
Most significantly this is a high traffic system powering a key audience-facing experience, so there was a need to ensure that the audience experience was not adversely impacted by any of the re-architecture work. On the out-of-hours support front, previously all services had been managed using a single on-call rota leaving a need to consider how to move to clear our ownership boundaries and separate on-call responsibilities across the platform and experience divide but without impacting our operational response. Looked at through our influence lens, again there's a desire to have an effect on system characteristics. We want the system to change but we don't want that to impact the audience, and there is a desire to have an effect on the team's behavior without degrading the operational outcomes.
First Steps
Given that context, what was my approach? The first steps involved selling the vision to the team. The initial work was to sell the benefits of the change to the team and help them understand why we were doing this. The first key benefit was around increasing the speed of delivery. I'm firmly of the belief that smaller teams with more manageable technical estates can more easily reason about those technical estates and feel confident that they understand everything they're responsible for. This leads to engineers having less fear and greater confidence to evolve the software that they own. Additionally, this change will begin to unlock cross-functional audience experiences which weren't previously possible within the BBC digital estate, such as cross-experience recommendations. Many of you may be fans of "The Traitors," and may also be aware of the companion podcast, "The Traitors: Uncloaked." At present it's not possible to recommend the companion podcast to viewers of the show on iPlayer, and the move towards a platform engineering stance where generic capabilities are exposed to a variety of teams is a key part of breaking down those silos and enabling these richer audience experiences.
I also needed to set expectation with the teams that this change wasn't optional. There was a clear strategy being set by senior leadership and a need to align around that strategy. This kind of project presents key tensions for anyone in an IC role, and that's because those roles rely on building and maintaining strong positive relationships with the teams and individuals you interact with. Operational strategy can't be ignored but the way that you implement that strategy can have a huge impact on your relationships within an organization. This is where we come to the first couple of tools in the influence toolkit. In order to sell the vision, I land on two things. Spoken communication either in person or via video calls is a huge part of the way that we influence people. That spoken communication can be one-to-one or in groups sometimes aided by presenting from slides or talking about documents.
It's absolutely essential to communicate the vision and build rapport across all levels and disciplines, whether that's engineering, delivery, product, architecture, UX, whatever disciplines you might happen to have in your organization. When I'm speaking to people and trying to sell a vision, I try and make space to allow time for questions and challenges, and to engage honestly with the doubts and fears that individuals might have about what's being proposed. Spoken communication is valuable but it doesn't always scale. If you're trying to influence a group of 30 or even 100, that's an awful lot of one-to-one interactions. This is where context documentation comes in. I led on the creation of context documentation that could be used to disseminate the vision to the wider team, and I collaborated closely with key engineers to outline the problem, the challenges, the rationale, and the planned next steps.
Inevitably, during this vision setting period, there were some areas of pushback from some members of the team and I had to address those. One of the most significant areas of pushback was the view that we didn't have enough idea of future vision or future requirements to inform our approach for changing the technical estate. To address this, I liaised closely with colleagues in product and established that there were no concrete or hypothetical requirements that would be impeded by the proposed approach. Another really significant area of pushback was the view that doing this properly would take three years and anything else would be a bodge. Ultimately, my response to that was quite simple. We don't have the luxury of indulging in 3-year re-architecture projects which don't deliver audience-facing value. Tradeoffs would be required but this change represents an acceptable first step in the evolution of the estate.
When we're thinking about pushback, it can be useful to think about individuals and teams in the matrix of support and resistance. In the top right you've got active supporters. These people are thoroughly bought into whatever you're proposing and whatever you're trying to achieve. They're already cheerleading what you're doing so you shouldn't need to spend any time influencing them, and they should help in your ability to influence others because they're actively supporting your efforts. In the top left you've got passive supporters. They're not so vocal in their support either because they don't care enough or because they're not comfortable evangelizing to a wider team. You shouldn't need to spend that much time influencing here either but you're unlikely to get active help. In the bottom left you'll find passive resistors. They're opposed to your idea or your plan, but they're not doing anything to really try and prevent things from happening.
Passive resistance can have an impact on morale because it can lead to grumbling. It's worth identifying anyone in this camp and spending some time trying to influence them, but they're definitely not the key group. Down in the bottom right you've got the active resistors. They're opposed to the idea or the plan and they're trying to head in another direction. This can manifest in a few different ways. Active resistance can involve arguing or dissenting in group discussions or in discussions one-to-one, but it can also present in a less obvious way where people say nothing but quietly keep on doing something that doesn't align with the strategy. The active resistors are the group that you should spend most of your time trying to influence, and they will often represent a disproportionately small number of people or teams within your overall sphere of responsibility. If you can influence these individuals to move to passive support or even active support, your ability to drive change will be hugely improved.
Breaking Down the Problem
Back to the re-architecture. With the team aligned around the vision, the next step was to break down the problem into manageable chunks and identify the key areas that the teams would need to agree approaches for. I collaborated with stakeholders and discipline leads to identify the areas where significant changes would be required and where agreement would need to be reached. That included ways of working, how the teams would interact as they split apart, and how we would approach the work for the re-architecture. How the teams would approach AWS account management given that up until that point all infrastructure resources had been deployed to a single set of accounts. Agreeing ownership of the services in the existing estate between the new teams. Agreeing an approach to common libraries and whether there would be a need to adopt an InnerSource model. Looking at a strategy for contract testing to validate the new boundary between platform and experience teams.
Lastly, thinking about how to split functionality in the services at the heart of the estate which needed to change to support the re-architecture. When it comes to achieving consensus, I'm a huge fan of the combined process of RFCs and ADRs, which the teams I was working with in this instance were already familiar with. RFCs, that's request for comment documents, are a powerful starting point for decision-making. I led the creation of an RFC for each significant problem area. The process around RFCs allows for collaboration with key players, and then once you have consensus in a tight group you can widen the group you're seeking input from. This process really empowers good analysis, letting you tease out ideas, gain input, come to consensus, and push decision-making forward. Once each of these RFCs had come to a conclusion, decisions were documented using ADRs. That stands for architecture decision record.
If anybody isn't familiar with the idea of ADRs I really encourage you to look up this blog post by Michael Nygard. It's an excellent rundown of the concept behind that particular kind of documentation. ADRs provide a perfect format to ensure that key decisions are documented tersely for future reference. Documentation is really powerful but it's not enough on its own. It's also necessary to have regular check-ins with your stakeholders. These can be used to identify any remaining points of contention, have any debates that are still necessary. They provide an opportunity to really push for progress, to ask the group to find the compromise, ask if things are really a problem, and agree an approach so that you can move forward and not get bogged down.
A big part of selling this vision was in helping the teams to understand the long-term strategy but also sending the message that this wasn't the end state, rather a useful stepping stone to allow further evolution of the estate as we evolve the audio offering in line with wider BBC digital plans. Viewing things through that lens, a number of tradeoffs and compromises were accepted. Initially, work on the platform side would create an API on a parity basis, so a newly owned API which provides the same functionality and a very similar API surface to the existing core service. This is probably not the API shape that we would choose if we were designing the API from scratch, and it will undoubtedly require further evolution. Attempting to redesign the API while also splitting the technical estate would have been too complicated and would have introduced unacceptable delays. A greater degree of coupling between platform and experience services than is ultimately desirable will persist for some time after the initial re-architecture work is complete.
I consider this an acceptable tradeoff to reach a point of separate autonomous teams that are then empowered to further change their technical estates and continue to evolve the system's architecture towards new goals and requirements. A transitionary approach would be required around operational support. Out-of-hours rotas and the handling of business-as-usual maintenance tasks would not be able to immediately match the desired team structures, and this would be necessary to ensure that operational stability wasn't impacted by the re-architecture work.
Zooming In: Platform Tech Stack
I can't cover every facet of a project this large, so I'm going to zoom in on some areas where I feel my influence was particularly useful, starting with some decisions around the tech stack used by the platform API team. The team had taken a decision to use Node.js, moving away from Scala. I identified this as an opportunity to leverage the existing approach used in sister teams, such as the catalog team, and I leaned on my experience in those teams where I'd previously laid the foundations of a monorepo approach using CDK for infrastructure and CI/CD. I shared lots of prior art with the new platform team, including code samples and documentation. I conducted targeted knowledge sharing sessions with the team lead and the principal engineer in that space to ensure that they understood the rationale and advantages inherent in the approaches that I was sharing with them.
I was also influential in guiding the team towards a managed service approach, an opportunity to move away from the maintenance burden associated with running services on EC2, which was heavily used in the previous estate. I suggested that the team should make more use of managed services, such as Lambda and ECS Fargate, and pushed the team to consider the tradeoffs and use the most managed solution wherever possible to keep overheads low, taking a serverless-first approach and only falling back to serverful options where compelling reasons existed. Back to the influence toolkit, these are the techniques that I lean on when I'm working on the ground with teams. Slack is such a valuable tool for collaboration, and it offers really unique opportunities to influence behavior and decision-making. Being present in team channels and observing day-to-day discussions provides valuable opportunities and allows you to spot technical problems or decision points where there might be an opportunity to share prior approaches or leverage existing organizational knowledge.
Slack is so rich. You can link to other Slack conversations, GitHub examples, documentation, blog posts, anything you like. While Slack is a powerful tool, it's really important that you follow up on those discussions. Speak to the key players and make yourself available to answer questions and dig into the detail. Ultimately, the aim here is to empower the team to use tried and tested patterns as a springboard to deliver faster, but also to upgrade or evolve those approaches where newer libraries or tools might be more powerful.
Zooming In: Core Metadata Service
The second area I'd like to zoom in on is work around the core program metadata service, which I mentioned earlier on. Before the org change had been announced, work had been planned to remove Thrift from the BBC Sounds estate in order to address security vulnerabilities in the underlying Finatra and Finagle libraries used in the implementation. Due to the complexity of the service implementation, this was many sprints of work for a large number of engineers. That work would ultimately be thrown away in less than a year due to replacement functionality being created in the platform space. Once I'd identified this risk, I raised the issue with senior leadership. There was pushback from the team around the security considerations and the difficulties associated with changing the team's roadmap at short notice. Ultimately, I secured agreement for a change of approach. Once we were further into the re-architecture project, discussions around how to split the core program metadata service began, and the engineers began to think about how far to go with the re-architecture work.
Some of the engineers were keen to look at a larger reimagination of how personalization might work across the estate. I identified this as a source of risk in terms of project timelines. A more complex reimagination could quickly grow arms and legs, leading to elongated project timelines and blocking any work which could deliver audience value. I pushed strongly for the team to distill options with a focus on simplicity and speed of delivery rather than notions of elegance or wider scope. Not a hack, but a pragmatic path forward.
Some of the discussions around the core program metadata service were difficult, with significant differences of opinion among stakeholders. Perhaps the most important part of the influence toolkit is how we use our influence to have those difficult discussions. Having allies is absolutely essential, whether that's your boss, your peers, or other key stakeholders on the projects that you're working on. That's because the best ideas and the strongest visions will still fail to gain traction if you don't have support, because change is hard. Finally, when approaching tricky discussions, radical candor can be hugely powerful. We need to be willing to have difficult conversations, approach them head-on, and be frank in the way that we address problems. It's important to ensure that we do the right thing, not the easy thing. I'm lifting a quote here from Kim Scott's book entitled, "Radical Candor," caring personally while challenging directly. Scott was talking about management, but I think the same principle applies to influence. If we build a reputation as a caring and empathetic co-worker, we build our influence. When we have good relationships with the people we're trying to influence, then we gain the ability to challenge directly and move discussions forward.
Measuring Success
I want to touch on how to measure success. I want to bookend the re-architecture story by covering our progress so far. We're not finished, but we're on track. Agreement has been reached on all the major decision points, and those decisions have all been documented in ADRs for future reference. The platform team have already made a lot of great progress towards creating a new API surface, and the building experiences to integrate with those new APIs is also underway. Now comes the trickier part, what could have gone better? At times, morale in the team has not felt as high as I might have liked. Change is hard, and there are many factors that affect how people feel, but ultimately this points to an area that I could have had more success. I'm not sure there's any such thing as perfect morale, but that doesn't mean we should ever stop trying to find it.
Some of my personal approaches weren't as successful as I'd hoped. Every individual is different, and it often takes time to establish the best way to interact with them. It can be hard to affect positive change when you don't have prior relationships to lean on, or if you're geographically at a distance from the person or team that you're trying to interact with. Sometimes my approach was wide of the mark, and I've tried to learn from those experiences. In terms of buy-in, I think my attempts at vision selling fell short with some members of the team. Now, 100% buy-in is probably unrealistic for a change of any significance, and I remain a big believer in the concept of disagree and commit. Nonetheless, there may have been ways that my vision selling could have been improved.
How do you measure success? How do you tell whether you're any good at influencing the individuals and teams around you? When you're looking to measure your influence around areas of technical complexity, you can track your success by the technical decisions the teams are making. What proportion of those decisions are roughly in line with your desired outcome? How much are those decisions deviating from what you might consider perfect? Reviewing these technical milestones frequently can help you get a feel for the success of your influence. Measuring influence on areas of social and operational complexity is potentially more difficult. You're looking to influence people's behaviors, but behavior can be hard to observe, and individuals won't always be honest about how they truly feel. Outcomes may be harder to track, but you can look for clues. Does morale feel higher? Are you having less difficult conversations? Are you able to classify any of the active resistors you've encountered as passive resistors or as supporters?
The best thing you can do is ask for feedback. Check in with your stakeholders and your teams. Ask them to give an honest assessment of how you're doing. If you feel brave, you can ask someone you often seem to disagree with to give you feedback. You might find something you can learn from and be able to incorporate into your practice, whether that's positive or negative.
The nature of feedback and the different ways we can receive it is something I want to touch on, because feedback comes in different forms, and these different signals can help us understand whether our influence is working in the way we want it to. When people think about feedback, they often mean direct feedback. Either you're actively asking someone to tell you how you're doing or to reflect on their interactions with you over the past six months, perhaps. Or someone has something they wish to address with you, and they provide direct feedback without request. Now, that kind of feedback is really useful, especially if you haven't had to ask for it. That means the person you're interacting with really wanted to tell you something, and that's something that you can always learn from, whether it's positive or negative. You can also get some really valuable insights from indirect feedback, and this is where relationships come in.
If you have friendly, positive relationships with the people around you, then the conversations you have can give you valuable indications of the success of your influence. To give an example, I bumped into one of the engineers in the platform API team a few months ago in the office, and I had a short conversation where I asked them how everything was going. They mentioned how positive they'd found the experience of moving into the new team structure and using the new tech stack, and how much more quickly the team were able to build things in this new world compared to their previous experience. These kinds of conversations could easily be dismissed as small talk, where nothing of value is likely to be learned, but in this case, I received an anecdotal indicator. The approach I'd proposed was working for the team. This kind of positive feedback loop, where we make helpful suggestions to teams, is how we build trust and ultimately grow our influence.
Recap
Let's recap the tools I've talked about in the influence toolkit. Spoken communication is so powerful. Find opportunities to talk to people, whether that's one-to-one, in groups, over a coffee, in workshops, whatever settings present themselves to you and feel right. Consider context documentation when you're trying to sell a vision to a big team, and use it to scale your influence beyond what can be achieved in one-to-one conversations. Leverage the power of the RFC and ADR process to build consensus and really drive decision-making. Make sure you review regularly with stakeholders around those decisions and keep key players in the loop. Spend time on the ground with your teams. Try and understand the challenges they face, and use tools like Slack to find opportunities to help and guide them. When you share thoughts with your teams in this way, make sure that you follow up. Make time to continue the discussions in the most appropriate way and drill into the detail. Build a network of allies so that your vision is nurtured and you have support when you need it for difficult conversations. Practice radical candor. Build your relationships and be prepared to challenge directly so that you can help your teams to make the right decisions.
Questions and Answers
Martell: You talked some about how we need to work to get our teams to buy into our vision. Sometimes you're in a place where the vision maybe isn't yours, and you need to get the team to buy into it. Maybe you're not 1,000% aligned. What does that look like? Other than disagree and commit, how do we do that?
Henry Wilson: That's really hard. Sometimes in senior leadership positions, we do get put in a position where the organizational strategy is moving in a certain direction, and it's not necessarily a direction we would have chosen. Ideally you would get some opportunity to feed into that technical direction. You would have the opportunity to talk to senior leadership and challenge, try and influence the direction that's moving in. I think if you aren't successful in that, if the organization is moving in a direction that you disagree with, you do have to disagree and commit. Either that or you have to find another job. That's a really hard position to be in. I think it asks a lot of people to positively sell a vision they don't truly believe in. I suppose you have to ask yourself how much you disagree with this. I think if you disagree with it too much, then maybe you do need to find another job.
Participant 1: What were the biggest challenges from the active resistors and how you tackled those?
Henry Wilson: I think the challenges in this case were, yes, I think there was a lot of pushback about whether this was something that we really wanted to do and whether it was being pursued for the right reasons. When you're dealing with technical teams that have been in place for a long time, regardless of what job title somebody might have or what seniority they technically hold, people who are long established in teams can have a lot of influence. I think that, yes, that presents challenges if key players are grumbling, and espousing a view that we shouldn't be doing this or that this is a waste of time or that it's doomed to failure in some way. There are no easy answers to those kinds of problems, unfortunately. You have to try and get people on side, try and explain the rationale for changes, explain why as an organization you're pursuing a given strategy, but yes, it can be difficult. Some people have very strong opinions and are very stuck in their ways.
Participant 2: How can you choose what hills to die on, if you know what I mean, and just like when you're butting heads with someone and you're like, do I let this go, do I drop it, or you're like, actually no, I really want to pursue this.
Henry Wilson: That's a really tricky judgment call. I think some of it has to be about how significant the change really is. I think you definitely have to try and identify as objectively as you can which areas are really significant, where there's some significant risk. Whether that's to do with timelines or to do with like ongoing maintenance, and you should try harder to persuade people, and where actually the direction they're heading in might not be the one that you would choose. It's more of a toss-up decision, at which point if you argue the toss over every one of those, then you're probably going to make yourself quite unpopular. I think the other thing to bear in mind is where there's an opportunity for learning. I think there's an element with these kind of IC roles where you can get into, trust me I'm a doctor mode.
Often, people will learn more from their own tried and tested experience of having gone down the wrong path and found out for themselves why it was the wrong path. I think there's a really interesting judgment call. Sometimes you can see that an approach is wrong, but it's still better to let the team learn that firsthand than to prescribe it or try and prohibit them from pursuing it. There's a really difficult judgment call there around, I suppose, effectively how much time is consumed in allowing an individual or a team to go down that path, and if it feels like a reasonable tradeoff of, ok, we'll lose a couple of weeks, but they'll learn something really valuable, then maybe you let them do it. If it feels like they're going to lose six months, then maybe you shouldn't.
Participant 3: I was just wondering if you've ever been in a situation where engaging somebody who you initially view as like an active resistor has led you to, I suppose, switch to their side or change your initial direction that you wanted to influence them in.
Henry Wilson: That isn't so relevant when you're talking about organizational strategy because you're not going to be terribly popular if you start off trying to sell a vision of organizational strategy and then start trying to undermine it. I think when it comes to slightly less totemic technical decisions, it's really important to try and approach those discussions with an open mind. Inevitably, I think all of us when we go into technical discussions, we're going to have some idea of what we think the best outcome to that discussion is, but we're not doing a great job if we're set in that view to the point where nothing that can happen in the discussion is going to influence it otherwise. I think we have to be open to the possibility that somebody could persuade us of a different point of view. Personally, I find that quite refreshing. If I've come in with an idea and then somebody succeeds in persuading me that a different approach would be better, then I've learned something that day and that's really valuable.
Yes, I think it's about trying to be as objective as possible when we consider these things, and trying to make sure that we're doing things on the merit of the technical approach, the actual objective reality as much as we can assess it of what the outcomes are going to be like, rather than notions of pet ideas or personal opinions about who might be voicing the idea. That makes it sound really easy. It's not. Like you walk into a discussion with some preconceived ideas and some biases, it's difficult sometimes to challenge your own assumptions, but yes, it's worth doing.
See more presentations with transcripts
