Building Bridges as a Technical Leader

Part of a series about how to build strategy and technical leadership skills with the goal of deliberately cultivating a long-term career as an engineer. Earlier posts: Thriving on the Technical Leadership Path, Where to Start, and Technical Research and Preparation.

In a talk a few years ago Michael Bernstein asserted that “Marketing is more important than code in the adoption of software”. He’s talking primarily about adoption of software once it’s released to users. I’ve also found this to be true much earlier in the process in the companies that I have worked for. For most of us producing software inside a company, the success of our work is dependent on our collaboration with other people. Particularly with complex or long-running projects, you need to garner support and input from across your company. If your project gets cancelled due to that lack of support, it doesn’t matter how great the code was.

In this post, I’m going to look at how to build relationships and embrace cross-functional communication in order to do great work as a technical leader. Aside from common practices like presenting at an internal group talk, I’d like to share my experiences with fellow engineers of other perhaps lesser-discussed practices that I’ve found helpful. I find large group meetings challenging, for a number of reasons, and as a remote employee building support via serendipitous interactions is limited. So I’ve focused my energy on other practices. Here I’ll share from my experience of finding the people you might need on your side, the benefits of going high and broad with your outreach, and how to embrace understanding and participating in the politics of your company. Finally, how and why to build trust in you and your work.

Find your people

Depending on the nature of the project and organization, you might need a sponsor. What I mean by ‘sponsor’ is someone highly placed who will actively, visibly and vocally support you and your work inside the company. While it’s possible to do discovery or R&D work as your own initiative, in relatively small chunks of time, it is a lot easier to succeed if your work has a sponsor. When your decisions have consequences across the company or work needs financial investment you need someone in your corner who has access, scope and power. Someone to speak on your behalf behind closed doors.

In my current role, I was fortunate to be given an explicit sponsor from the outset - someone who had advocated for my role to exist, and shared accountability for the initiative I was hired to work on. Importantly, your sponsor does not need to be the person your report to.

Previously, when I haven’t had an explicit sponsor, I have asked someone senior on the management side to advocate for me on occasion. A few years ago I was tasked with being the technical representative for my department, acting as a consultant for other internal teams and high-profile external partnerships. Sometimes, in meetings and written discussions, other very senior engineers would dismiss my input, or even presence. I explicitly asked my advocate not to answer for me, but to validate my role and expertise. From his privileged position he could lend me credibility by saying out loud, “Keavy is representing [the department] on this. She is the technical advisor.”. This helped others treat me with respect and quite simply made it easier for me to do my actual job.

I subscribe to the idea that success at work is built on three things: results, process and relationships. The relationships, like the rest, need deliberate care and effort.

As well as an explicit sponsor, for the sake of the work’s success, and your personal sanity, it’s incredibly important to find ‘your people’: anyone and everyone that can help and support you and your work. So the deliberate work here might include finding out who can help practically, logistically, or emotionally. Then making time to connect with those people.

Bringing about change, especially cultural or systemic change, in an organization is challenging. Even with a change that people say they want, resistance is pretty much guaranteed. At various times you might need: some muscle to back you up, voices that get heard to advocate on your behalf, or a shoulder to cry on when things go awry.

Go wide

I’ve learned to reach out to other discipline teams early: support, docs, legal, security. Let people know about what you’re planning, ask what they will need, seek their input. Especially in the lead up to a big release, you want to minimize surprises all around. Having explicit conversations about needs and expectations, leading to written plans of who needs what, by when, and who is responsible for each part, makes the process and relationships have a much better chance of success.

To flourish at this you need to see cross-functional communication as truly collaborative and multi-directional - you want the experiences and needs of others to inform your work, rather than seeking just to inform others about your work. If your preparation is mainly with engineers, especially if the team isn’t diverse, you may well share similar blind spots.

On a personal level, as a woman engineer, having worked in groups of predominantly white men, it’s been a bonus to do more cross-functional work just to interact with a more diverse range of people. I partly want those interactions for my own enjoyment and fulfillment. But mostly I want those interactions for the rich and nuanced understanding they bring to the product.

Forming and staying aware of the bigger picture of the organization is critical to doing more strategic work, taking on more responsibility, working on the company, not just in it.

Know your audience and prepare in advance how you’ll best communicate with them. For example, do they like visuals, stories, data?! Different organizations have different cultures around this - at GitHub the culture was orientated around the written word. At Fastly, I learned the culture had a preference for slide presentations. I still write detailed proposals and documentation around a project, because I believe the benefits of that go far beyond any other medium. But I have learned to also prepare for presentations.

Go high

To get the buy-in that can make or break a project, you also need to talk to people in positions of power. I seek to find out what exactly I should talk to those people about. I learnt a tip from a talk by Julia Grace about how to find out what execs really need or care about. That tip was: “ask them”. Quite simply, explicitly ask people what they care most about, what’s top of mind for them. You might think you know what the legal or marketing or product team cares about, but you might be surprised. Our assumptions about other people or groups’ work is based on our own experiences and bias, so asking questions is the only way to get beyond that.

I’ve learned to adapt the detail or granularity of a proposal to suit the audience. With their tight schedules and higher level of operating, execs need to hear a different, certainly shorter and punchier version of any pitch. Depending on their area, and what you already found out they care about, you might need to talk about the potential business impact, any hiring implications, or why this and not some other technical approach. Writing down how you’ll pitch a project, for a particularly important person, and practicing out loud is good preparation.

A manager recently told me a good tip about “pre-meeting” work, which was to only go into an important meeting knowing that the most important person is already onboard. I’ve rescheduled meetings until I could achieve this and it has been incredibly helpful in moving things forward.

Politics

If this all sounds like “politics”, ewww, I’d recommend listening to Nicholas Means talk on the Eiffel Tower. He talks about how building anything successfully requires you to “understand and participate in the politics of your company”. He assures us this doesn’t have to be unpleasant, but that it’s really about “making friends and telling stories”. I find this description really helpful. I can absolutely explain what I’m going to do and why. I can tell stories about what I did and why. I can listen and think through all the information I glean across the org. I can find a path.

I’ve seen some people have success predominantly through making friends and telling stories but without any substance to back it up, just schmoozing with their buddies. These tactics can be particularly detrimental to the culture when that team doesn’t need to do the broader work in explaining and documenting the whys and hows. It’s hard to scale and replicate that approach and can leave those mid or senior level engineers without privilege confused as to how they might progress to carry out big projects successfully.

Building Trust.

I’ve been fortunate in my recent roles, having built up enough track record, that the organization leadership has trusted me, allowed me the time and space to do this type of work. With that trust comes a high expectation and responsibility to deliver, so to sustain it you need to do what you say you will and do it well.

One thing I’ve learned that helps nurture that trust is being transparent about your work. I talk and write about what I’m working on, what challenges or threats there are, what my next steps are. I like this work to be discoverable, as well as just accessible, and my preferred medium for this is markdown files in a company repository. I want important discussions around tradeoffs and direction, and certainly decisions, to have a URL.

At GitHub, I enjoyed a culture of writing proposals down and having that work be discoverable by anyone in the company. Because my team and I valued our autonomy to build so much, but had an awareness of our vulnerability, we often went above and beyond with this. We would share written proposals, design documents, learnings from spikes, records of decisions, roadmaps, estimates, how we arrived at those estimates, everything. The downsides included sometimes getting unsolicited ‘drive-by’ criticism, which can be unpleasant. The upsides included strengthening our own approach through having to articulate it and often adapt it.

Building that trust enabled me and my teammates to do even more: to have more autonomy, to take on more responsibility and to build more challenging work. People had seen our process work. When we said we’d do a thing, they knew not just that we would deliver but that others could see it happen and learn along with us. This is how we can have nice things.

Showing a path to follow

By sharing your work you want to keep stakeholders involved and updated, of course. But another valuable aspect is in promoting the very senior engineer path to any interested mid or senior level engineers following along, both now or in the future. I like the fact that there’s often nothing magical to see, but rather ‘just’ a careful, thoughtful process delivered through consistent hard work.

Conclusion

Finding a sponsor, seeking to hear and understand the needs of people high and wide across your organization, finding your people to support your journey, nurturing all these relationships… it’s a constant learning curve, but these are some of the practices that I’ve found helpful in communicating effectively across the company. Even as an introverted, 5’ 2” tall, Irish woman who works remotely.

The most impactful experience I’ve had with you is the way you treated me, taking the time to listen and collaborating on our work together here.

A former colleague who worked in Customer Support.

Thanks to Andy, Joanna, Michael and Sheri for reviewing a draft of this.