This conversation is transcribed from our podcast Between Product and Partnerships, a podcast brought to you by our group the SaaS Ecosystem Alliance. It’s focused on bringing together product, partnerships, partner marketing and engineering leaders to discuss how to build support and scale SaaS ecosystems.
In this episode, we spoke with Katherine Tooley, a Technology Partnerships Manager at LogicGate, a modern risk management platform.
An an engineer turned technology partner manager, she now serves as a liaison between sales, CX, and product teams to collaboratively identify integration solutions that provide value to their market base.
In his interview Katherine shares:
If you're interested in watching or listening in on this conversation, you can access the video here and a link to listen on podcast platforms here.
Katherine: Liz, thank you so much for having me. My name is Katherine, and I'm currently a Technology Partnerships Manager with LogicGate. I've had a bit of a journey to get here.
I studied engineering and physics in undergrad, and also got my masters in engineering management. Then, I started my career as an engineer. I worked in the biomedical space, as well as the maritime shipping space.
And then, in my previous role, I did a rotational engineering program, and then moved into their software team at the same company, which is where I got my start in partnerships.
I started managing their partner portfolio and their program, and I found software incredibly interesting, and I really enjoyed the social aspect of my job working with partners. And so, I started to look for another job that was based primarily in the SaaS space, doing the same thing.
That's really where I came across LogicGate. Having been in the compliance and risk background before, the transition to a GRC tool was pretty simple. And, now I manage our technology partners, as well as work with our product and sales teams.
Liz: Nice, really interesting background here.
Katherine: As an engineer, I really enjoyed the analytical piece of my education and of my previous roles, but I found that I worked very well in a collaborative space and more of a customer facing space.
So it was a really big transition to move from really numerical engineering, very lab based work, to customer focused, client focused, work, and having that level of professionalism change in my day to day environment.
So, as I started to work with clients at my previous role, I found that I really gained energy through working with other people, and was able to translate a lot of our engineering into a conversational or ingestible way that people could understand.
And so, I found that as a really big strength and decided to capitalize on that moving forward in my career. So, I moved over to partnerships, completely.
Liz: Yeah, I definitely see how that would be a great strength to have in the partnership space, just because I feel like not too many partnerships professionals come in initially with that really strong technical background.
But to dig a little bit into your day to day work, I know in our previous conversation, something interesting that came up was the reporting structure of Technology Partnerships at your organization, and also at your previous organizations that you've been with.
I know, you mentioned that at LogicGate your role as a tech partner manager sits under sales.
Related Content: Justifications for Investing in Tech Partnerships - From Product Leaders
In many of the interviews that I've done, this role usually sits under product, but it does shift and change.
Katherine: Absolutely. So that was a change for me as well, having come from a previous alliances organization that sat under Product.
Moving to sales really connected me better with the business. I've seen a lot of value, in my opinion, in sitting underneath sales as I spend a lot of my day on demonstrations and client calls, which allows me to see firsthand what types of solutions, products and features are being asked for by our customer base and by our market.
This then allows me to take that data back to our product teams, and to our integrations, and really focus on gaining technology partners who can create a stickier solution that provides value to what our market base is really looking for.
That's something that I had trouble with when reporting under product. As an engineer I love to have different cool software school products that I could partner with, but I was a little out of touch with what was necessary and required in order to propel our business forward.
Sitting under sales with LogicGate really allows me to keep adapting our technology profile with the changing market better than it did as someone sitting under product looking solely at product features.
LIz: Yeah, one challenge that has come up a lot in conversations that I've had with other tech partner managers is how do you actually track the success of the technology partner program, especially when it comes to business outcomes, not just product outcomes.
I'm guessing they're more revenue/sales focused rather than product focused?
Katherine: Yeah, absolutely. So while we do have KPI metrics that I reach towards, our organization is really supportive of the fact that technology partner revenue is not very cut and dry, not very black and white.
There's times when we are looking for solutions that will make our products stickier, or will support our current customer base that may not be the largest revenue generating, but really provide a feature in a space we don't want to be in or build ourselves.
So, we really attempt to diversify our ecosystem. Part of my metrics is really making sure we have a hand in everything that's being asked for. That’s almost more important to us than really major revenue drivers, since we want that diverse ecosystem that will support our product, and our customer base.
And then the goal, obviously, is to drive more lead generation. But, that really comes from selecting the right partners. So it's not as much of a black and white number as it is more of a structured ecosystem that supports long term growth for the company in the product.
Liz: Got it. So, your KPIs or what you work towards isn't necessarily directly tied to revenue. You're, you're more focused on the enablement of the product and the customer success and sales teams to drive those numbers.
Katherine: Right. And while I do have revenue goals, they're not as strong of benchmarks that other departments may have to hit, because there is a lot of gray area with why people are selected to be partners of ours and why we are focusing on the long-term strategy as well.
Related Content: Lessons Learned from Top Technology Partnership Leaders
Are there any processes or tools that you feel you've implemented that have really helped with that alignment?
Katherine: As someone who sits under sales in this role, it required a lot of a direct effort from myself as I onboarded about nine months ago. I really made an effort to focus on setting up repeated interactions with our technology and product teams, in order to best understand the pain points that were existing in integration.
As an engineer, it is best for me to sit in on technology calls and hear the hesitations with certain API integrations, as well as red flags and green flags with the documentation from partner companies.
This allows me to better vet technology partners and be the first line of defense for our product team. By communicating with sales about resource allocation and interests from the product lens, I am able to bridge the gap between the two departments.
At my startup, everyone works closely together, so there isn't as much division between product and sales. One common struggle for technology partner managers is getting buy-in from product for integrations, especially when resources are tight.
My background as an engineer and software engineer gives me credibility and understanding when I talk to product and integration teams, allowing for an open dialogue and the ability to validate requests from a sales perspective. This creates a good roadmap for integrations.
Liz: That's a great quote right there. I'm curious, you mentioned some things like knowing about what resources would be necessary, how long things would take.
It can sometimes be intimidating for tech partner managers in terms of how much technical understanding they should have.
Katherine: Absolutely, I come from the opposite side. I was a little worried about the lack of sales knowledge and experience I had, but it's been a really good experience learning about how a sales organization operates.
As a lifelong learner, I love school and changing jobs to learn new industries. But, I was really grateful to have had that technical expertise prior to coming in.
If I were to give advice to technology partnership managers, I would say it's not as necessary to understand the technology and what goes into building an integration as it is to understand the labor time and expense of what you're asking for.
This way, you aren't burning out your teams or over allocating your resources. You don't necessarily need to understand how the API connects, but understand that it takes a certain amount of time and resources. Understand how much you're actually asking for from your product teams. Knowing enough to support that team is the most essential part of being a technology partner manager.
In terms of gaining knowledge, I would recommend taking a professional certificate or an entry-level course. I did a lot of LinkedIn learning when I started this role. I also took a course on sales through Northwestern.
I also recommend seeking out free resources or resources through your company that will help you understand the vocabulary associated with software, which is the first step in understanding what you're looking at.
Regarding identifying red flags and green flags in partner API documentation, when I talk to a potential inbound partner I like to review their API, see how organized their API documentation is, look at the maturity of API's, see how many partners they have in their ecosystem.
Do they have web hooks versus an API integration? Is it a bi-directional integration? These are things that really help us understand the maturity of that organization when it comes to partnering, because that will be a large determining factor in the success of the integration, as well as the technical support that we'll receive from the other organization.
Red flags would be disorganized APIs and partner managers that are unsure of answers to basic questions around how the integrations work for them and how their partner integrations work.
That might be a question for a product team at times more than the partner manager, it doesn't necessarily have to be my role. But those are things that have helped me pick strong partners, by vetting those pieces prior to trying to build an integration.
Related Content: Mastering API Documentation: 3 Proven Best Practices for Success
Definitely, from the lens of my career, when I previously worked in a role where I reported to product, as an engineer, I enjoyed it. But, I didn't have a strong understanding of how our sales were doing or how our partners were being received by clients.
And, to be honest, I didn't really want one. I was an engineer and I liked being an engineer.
But when I moved to LogicGate, and moved under sales, it propelled my ability to understand how to select partners and also gave me more of a leadership perspective in my career.
Being involved in sales really showed me how to best support the business as a whole, and not just as an individual contributor.
I had buy-in and visibility into how my role impacted the overall business and the success of the business. And that, I think, was a really strong positioning for a technology partner manager.
Because then, I could go back to the product and say, 'I've seen this capability asked for 10 times, let's set out a partner for it. Let's see what we can do. I think this would support our solution.'
Whereas if I was in product, I was very detached from the overall business success and was very focused on the success of my specific partners.
Liz: So, I know that you mentioned that your role doesn't necessarily focus on direct revenue goals, but rather on enabling sales and product.
So, I am working towards creating an ecosystem within our specific application structure. I aim to have about two to three partners in each area of our technology roadmap that we're focusing on.
Additionally, I am pushing for standardized integrations and repeatability in order to scale. I also focus a lot on supporting our sales team by being versatile and knowledgeable about our integrations, and by having appropriate collateral to support conversations with our partners.
Katherine: Yeah, absolutely. I found that creating a fast one-page cut sheet on how the two products work together has been really beneficial for calls and follow-ups.
While you may be on a call talking about our product, you may not be talking to the decision-maker there. So having the ability to follow up with documentation on how the program works, that's branded and clean, and shows a real alignment between your company and your partner company.
In terms of enablement internally, things that I found to be more successful is working with specific role groups, as opposed to doing large calls for the entire sales organization. I try to break up my enablement sessions based on role so that I can tailor what I'm teaching and how I'm positioning it to be intentional for their role, rather than a broad sales organization.
In those smaller set calls, that are maybe 15 to 20 people, or even less, it allows for a lot more personal interaction, more questions, and more engagement across the board. So that's been a big learning for me, is how to best get the engagement of our sales teams in order to retain the information.
Katherine: So I sit on almost every partner call, so I do have a really clear lens into every single opportunity that's involving my partners, and every call that’s involving my partners.
That allows me to do a lot of internal tracking on how best partners are succeeding and influencing our opportunities.
Liz: I'm also curious to hear about the enablement meetings. I know you talked about the one sheets and the information that you would involve in there.
Katherine: Yeah, absolutely. I really think it's essential to bring in the partners as the first step. Bring in the partner, let them demo their product, let them explain their tech and their value as if they were selling to us.
This really gets buy-in from our teams and starts a conversation about how the partner's product can support ours. It generates questions from our teams that will then help them position the product better when they're on a call with a client.
I usually sit in on most client calls as a subject matter expert for partner-related questions that come through. This helps our team see the questions that they would ask and sparks their interest in the partners.
We like to support the independence of our sales team to reach out to our partners.
It also helps bond the relationship between them and their contact at the partner company. We like to support the independence of our sales team to reach out to our partners and be part of our company as well, so they can reach out, ask questions, and I'll join the call if needed.
But it's nice to have that connection made between the teams on both the partner and our side.
Liz: That idea of a partner roadshows is a good one, and I appreciate the open line of communication between partners and internal sales teams.
Moving on from sales enablement, I know you also work cross-functionally with the product team. You mentioned some of the ways you enable the product team, such as by providing them with integration requests.
Yeah, one thing I've found particularly interesting to do with the product team is something that was done for me in my previous role.
As someone who hadn't previously been involved in sales, I found it valuable to have transparency on how our partners were performing. Many of our product teams don't have that lens into sales, and I struggled with this in my previous role.
So, I brought this into my new job by showing transparency on how many people are interested in a particular product, how it's doing on the sales side of the organization, and what common struggles we're seeing with clients. This allows for pivoting and resource allocation, as well as a better understanding of the impact we're having on the business.
Additionally, it allows for a sense of accomplishment when a product is well-received. I've found that this kind of information doesn't always reach our product teams, and I hope to bring this into my current role as well. In our leadership integration calls, I'm able to give the product teams a lens into how their hard work on integrations is impacting the business, and I find that valuable as an engineer to see how I'm propelling the business forward.
Liz: Yeah, you can't underestimate the power of joint success, right? I’d like to talk more about prioritizing integrations.
Katherine: Oh, and that's so tough. As an engineer, it can be tough to balance my personal interests in cool technology with the needs of our clients and market base. For example, there will be a big push into ESG (environmental, social, governance) in the next few years, but the regulations and drivers for purchasing ESG tools are not in place yet.
So, while I am excited about the concept, it may not be the highest priority on our roadmap. It's important for me to shift my focus from what is the most exciting new tool to what will be most useful and helpful for our clients.
This means taking into account requests from sales, research and data from our marketing team, and allocating resources to the products and partners that will best support our customer base. It's a challenging position, but ultimately it's about making the best use of our resources to support our clients.
Liz: So, it's mostly based on customer requests, and also market research from the marketing team of what would propel your solution?
Katherine: Yeah, and if I come across a tool that I really like, or I think would add value, I will start a conversation and build a relationship with the vendor and put it on hold until we start getting requests for it. That way, when the opportunity arises, we are ready to go and have already scoped out what we need.
One pitfall to avoid is approaching sales as if it were simple.
When it comes to enabling sales or developing partnerships as a technology partner manager, one pitfall to avoid is approaching sales as if it were simple. I have learned that sales is a dynamic and complex field that requires a high level of intellect. I would advise people to be transparent about their struggles and to lean on their strengths.
For example, I may be a technical expert, but I may not understand deal cycles yet. So I enrolled myself in a course and worked with a mentor to learn more about sales.
Another pitfall to avoid is not taking the time to understand the product as a sales professional. It is important to play around with the software, ask questions, and read the documentation so that you have a good understanding of how the product works and how it can be used to best serve the client.
This will help you understand how different types of software will complement yours and how to best support the client experience.
In summary, be transparent about your strengths and weaknesses, be open to learning, and be hungry for new information when you come into new roles.
Liz: That's great general advice. Hearing you talk about that brought another question to mind, how did you come into your role? Did you feel like you needed to work on getting buy-in from sales to work with partners, or was that just a part of the organization's culture or something that you felt you had to help cultivate?
Katherine: At LogicGate, the leadership has strongly bought into our partner program. They are very supportive of it and constantly reiterate that partners are a great tool for success and revenue. I believe that buy-in from sales comes from upper leadership.
Support from upper leadership is crucial for driving revenue through partnerships.
As a younger Partner Manager, I have had a great experience with the sales team at LogicGate. They are respectful and work well with me. However, I know from colleagues that it can be difficult to get that buy-in.
Having the support from upper leadership is crucial for driving revenue through partnerships. It needs to be an entire organization commitment to partnerships in order to drive that revenue.
Focusing on what drives your sellers and figuring out how to best support them is also important. At LogicGate, our sales team has a lot of visibility into what we do and we are given time to speak with them during big organizational events. This helps a lot.
I've seen from previous organizations and from colleagues in the space that without that leadership buy-in, it's really difficult to gain traction in the sales team. I am grateful for the organizational structure at Logic Gate for supporting our work.
Liz: Yeah, I asked the question because I've definitely heard that side from a lot of other interviews and other tech partner managers that I've spoken to. Thank you, Katherine, for taking the time.
Katherine: My LinkedIn is great. Probably the best way to reach me. Search for Katherine Tooley. There you can find a little bit more about my background, and I'm always happy to answer messages and connect with people and other partner leaders as well.
Or also anybody who's interested in getting the space, especially young women engineers who are looking for that dynamic piece of their next role. I'm always happy to talk to anybody who's interested.
If you enjoyed this interview, check out our Youtube channel and subscribe for more content on all things APIs, integrations, and technology partnerships.
If you're someone who is working on building and scaling SaaS product partnerships, we invite you to apply to be a member of our community and network with other leaders like Caitlin working on this at SaaSecosystemalliance.com.
