Business and technical teams typically approach a project in pursuit of the same outcomes. They just describe it in very different terms, and somewhere between kickoff and delivery it gets easy for everyone to get lost in the sauce.
Sarah Wimberley, founder of Ulster Technologies, has spent 14 years in healthcare sitting between the people who run the business and the people who build the systems for it, finding language both sides can work from.
In this episode of RPI Tech Connect, she walks through her five-step framework for IT project communication, built to turn strategic objectives into successful delivery: defining the problem before chasing the perceived one, bringing the right people into discovery early, designing the future state around people before picking a platform, connecting the work back to strategy, and keeping the lines of communication open once delivery picks up speed.
She also shares what organizations most often discover about their current-state documentation, why a discovery session only works when the room feels safe, and the one piece of advice she’d give anyone stepping into a translator role.
If your stakeholders agree on the destination but keep getting stuck on how to get there, this episode is for you!
Interested in listening to this episode on another streaming platform? Check out our directories or watch the YouTube video below.
Meet Today’s Guest, Sarah Wimberley
Sarah F. Wimberley, Principal & Founder of Ulster Technologies, is a detail-oriented leader with twenty years of experience in marketing and technology. She has served as an enterprise architect, product owner, graphic designer, and program/project manager at leading regional and national healthcare institutions as well as organizations in the financial, professional services, consumer, and nonprofit sectors.
A graduate of Rosemont College with a Master’s in Strategic Leadership, Sarah is also an active volunteer, serving as a Higher Award Coach for Girl Scouts of Eastern Pennsylvania and President of Village on the Ridge.
With a strong foundation in both technology and leadership, Sarah is passionate about driving innovation and fostering collaborative, data-driven environments. Sarah has spoken virtually and in-person on various topics, including change management and leadership.
Meet Your Host, Chris Arey
Chris Arey is a B2B marketing professional with nearly a decade of experience working in content creation, copywriting, SEO, website architecture, corporate branding, and social media. Beginning his career as an analyst before making a lateral move into marketing, he combines analytical thinking with creative flair—two fundamental qualities required in marketing.
With a Bachelor’s degree in English and certifications from the Digital Marketing Institute and HubSpot, Chris has spearheaded impactful content marketing initiatives, participated in corporate re-branding efforts, and collaborated with celebrity influencers. He has also worked with award-winning PR professionals to create unique, compelling campaigns that drove brand recognition and revenue growth for his previous employers.
Chris’ versatility is highlighted by his experience working across different industries, including HR, Tech, SaaS, and Consulting.
About RPI Tech Connect
RPI Tech Connect is the go-to podcast for catching up on the dynamic world of Enterprise Resource Planning (ERP). Join us as we discuss the future of ERPs, covering everything from best practices and organizational change to seamless cloud migration and optimizing applications. Plus, we’ll share predictions and insights into what to expect in the future world of ERPs.
RPI Tech Connect delivers relevant, valuable information in a digestible format. Through candid, genuine conversations and stories from the world of consulting, we aim to provide actionable steps to help you elevate your organization’s ERP. Whether you’re a seasoned professional or new to the ERP scene, our podcast ensures you’re well-equipped for success.
Tune in as we explore tips and tricks in the field of ERP consulting each week and subscribe below.
Transcript
Chris Arey
Welcome back to RPI Tech Connect. I’m your host, Chris Arey. Today we’re going to be talking about one of the most important skills in technology projects, and that is communication. My guest today has spent the last 14 years in healthcare doing something that sounds simple but is anything but: translating between technical teams and the operational staff they’re building for.
Sarah Wimberley is the founder of Ulster Technologies, and she’s here to walk us through her framework for getting IT projects across the finish line. Sarah, welcome to the show.
Sarah Wimberley
Yeah, thanks for having me. Pleasure to be here.
Chris Arey
For folks who haven’t met you, would you mind sharing a little bit about yourself?
Sarah Wimberley
Yeah, absolutely. As you mentioned, I’ve spent 14 years in healthcare. I actually have an art background and a design degree, so it’s a very nontraditional path to land in healthcare, and especially IT, in this day and age.
I’ve kind of embraced public speaking the last 18 months or so and ultimately founded Ulster Technologies about two years ago to formalize some work I’ve been doing for a long time in the public sector and nonprofit space, in a lot of ways translating pieces of work on their side of the house as well as in the healthcare industry.
So happy to share this framework, combining all my lessons learned over the course of my career, and sharing it with listeners here.
Chris Arey
Awesome, thank you. And just a real quick thing there: you mentioned the art background. I find that those skills tend to lend themselves to good communication, so I’ll be interested to hear your perspective today.
You also mentioned the translator role there, so I think that’s a really unique framing. Because usually I think about the word in a traditional sense, like making sure that language carries over from one language to another. But in this case, it’s English, and it’s distilling those needs between very technical teams and the people who don’t speak that way.
Sarah Wimberley
Right, yeah. And even though it is the same fundamental language, a lot of times there’s just a disconnect in the baseline business needs. And what really ends up happening is people are talking past each other.
There are gaps, and more often than not, it’s not necessarily a gap in knowledge. It’s really just different terms, different terminology, slightly different definitions. But what’s great is everyone usually has the best interest at heart. Everyone has great intentions to come together and solve the problem.
As we’ll talk through the framework today, getting the foundational understanding of what the thing is you’re trying to solve definitely starts to help build that foundational understanding, defining the key terms and making sure we’re all talking about the same things in the same way, so that we’re all starting from the same space and place, regardless of background, formal degrees, and tenure in the industry or the organization. It really sets the stage to have productive conversations going forward.
Chris Arey
Awesome. Well, thank you for sharing a little bit about your day-to-day there. So, as I understand it, you’ve got a five-step framework for translating objectives between teams. And I think your first one here is step one: define the problem. It sounds like there are actually two things happening there: you’re documenting the way the business currently operates, and then defining what it is they’re trying to solve for. Is that right?
Sarah Wimberley
Right, yeah, it’s really kind of a two-in-one step in a way. Defining the current state, the processes, even the data that’s in the weeds of that- everything from the products and platforms involved down to processes and reporting- having that current state understanding really gets everybody on the same page and helps break down complexities.
From a business perspective, those teams and resources are in the day-to-day. They’re running those processes; they’re reviewing dashboard reports every day. But the IT folks might be more on the data product side of the house, managing the big platforms or the cloud solutions, making sure the pipelines are running, but they don’t necessarily understand how the business is using the platform.
So, if the current state documentation is up to date, that’s great. But if not, it’s a perfect opportunity to take the time, even though it does delay the project a little bit, to get all of that up to date and make sure it’s available to the teams, so everyone is reviewing it and starting from that same foundational base understanding.
Because if they don’t have that exposure to where everyone is now, everyone comes in with their own perspectives and opinions, which is great- you want that, but you really need to understand how the business is operating today to know how to go forward.
Chris Arey
In your experience working with different organizations in healthcare, how often is it that the current state is documented and up to date?
Sarah Wimberley
I guess it definitely depends on the industry. A lot of my healthcare experience was in the Medicare space, so from a compliance perspective, we were required by the federal government to have our documentation updated at least annually. Worst-case scenario, it was 12 months out of date.
Not all healthcare plans have that requirement or expectation from the state or federal government, so it’s a little more of a gray area if you’re not operating in that space. But I do think it’s something that should be reviewed annually, if not every two years, so that when you’re making updates and reviewing it again, you’re tweaking it a little bit based on what’s changed since then. It will definitely take longer if you’re starting from scratch with nothing.
It is an important step, though, and unfortunately a lot of organizations skip it and dive right into defining the problem, which is still an important step to do. But if you don’t know where you’re starting from, it can be difficult to really put your arms around the actual problem, as opposed to the perceived problem.
Chris Arey
Got it. I love that you mentioned compliance. I feel like there’s a lot of fear associated with compliance, but I feel like it’s a good driver for getting people to do things they need to do. Question for you: when you’re going through this exercise with businesses, is there a common thing that surprises people during this step, or a recurring issue you’ve seen across various projects?
Sarah Wimberley
Yeah, I think the most common thing I’ve seen is just that documentation doesn’t exist. Or they think it exists for the particular pieces they’re looking for, and it just doesn’t, or it’s well out of date, and you basically have to start over from scratch because the platforms referenced don’t exist in the organization anymore.
The second most common thing is that it’s kind of an eye-opening review for people. The process is doing the thing we need it to do, but there’s a systemic failure or red alert that we might be ignoring because the IT teams don’t understand what the implications of that are.
Or they’re rerunning a job or a process behind the scenes and not necessarily understanding the ripple effects when there are delays, especially from a compliance perspective, where there are SLAs and expectations that the data is updated and things are handled in a reasonable amount of time. But yeah, documentation flat-out not existing is probably one of the biggest things I’ve seen across industries and across clients I’ve worked with.
Chris Arey
That seems, and I guess in a situation like that, it just proves that even though taking the time to actually document that stuff is going to delay the project, it’s such a worthwhile endeavor, because, like you mentioned, everyone’s starting from the same place, you’re getting alignment, you understand the problems, not the perceived problems, and you know what you’re working toward. I love that as step one.
The next thing I see here is bringing the right people into the room. That’s one that really resonates with some of the stuff we do here at RPI, where, especially in healthcare supply chain, there are silos and certain people aren’t getting looped in until way later, and that just creates more confusion and disconnect. I would love if you could walk me through what early cross-functional discovery looks like, and why having the right people in the room makes such a difference.
Sarah Wimberley
Yeah, cross-functional discovery can mean different things to different groups. In my experience, cross-functional is a swath of representation across every impacted team, not just the vision, but down to more of the operational team.
You have the business teams that are actually pushing the big red button to start the processes, kicking off and doing the actual day-to-day work in the systems, the data, the platforms. And then you have representatives from IT and compliance, maybe even finance if there’s a big cost implication, whether it’s a cost expenditure or a cost savings associated with the project that you’d like them to help calculate to get that ROI and funding, as well as leadership at the top, or reasonably up at the top.
In a lot of circumstances, decisions come top-down, where there are strategic plays and conversations happening, where a top decision says we’re going to solve this problem, or we’re going to bring in this new platform, and it’s a bottom-up reaction to make that happen. There absolutely needs to be some transparency from leadership at the top to define the scope to some degree and share their perspective on the rationale for the project.
But the hope is that the bottom-up SMEs, the subject matter experts, can validate that challenge, and using the current state documentation and these open, transparent, collaborative discovery sessions, can build trust with each other to really vet and prove whether or not the perceived challenges, whether from leadership or frontline staff, really exist.
That can happen really quickly if the data is well organized, the documentation is clear, and you have the right people in the room.
One good and bad challenge, to some degree, is there’s a lot of interest sometimes in keeping those circles small, having only the critical folks in the discovery session, which is totally fair, because scheduling with more than three people can be a nightmare.
But at the same time, if you don’t have enough of the right people in the room and enough diverse voices, you’re going to continue pushing the same challenges down the road into new platforms, or not really resolve the root cause of the issues you might have today.
Chris Arey
Well, you mentioned, it’s understandable when folks keep discovery sessions smaller for scheduling purposes, but when you don’t have enough representation in those sessions, I feel like it presents a blind spot, like you’re not hearing about a different side of an issue or a process that would be really valuable when you’re going through this exercise.
So, when you’re doing these exercises, have you seen missteps, or mistakes organizations sometimes make where you have to reel them back and tell them they should do it a different way?
Sarah Wimberley
Yeah, you make a great point with the blind spots on not having ideal representation. They have the people in the meeting invited to check the box and say compliance was invited, but is it the right compliance resource? Is it the right compliance resource with the right subject matter expertise or interest, or the ability and prioritization on their calendar to actually come to the call?
So that’s definitely a big challenge and area of opportunity for organizations, making sure the right people are in the room. A close second would be, what’s the right way to phrase it, making sure the conversation is transparent and collaborative at the end of the day. In a sense, we’re thinking back to the communication you mentioned at the top of our conversation.
If it’s not a safe, trusted place to have a conversation, you’re not able to really have an open dialogue and talk about challenges and problems in a way that’s actually helpful. You absolutely don’t want a discovery session to be like a finger-pointing hour, or people throwing each other under the bus.
We don’t need that. We get enough of that outside of work. You don’t want to be a part of those kinds of conversations. So, we really need to have that foundational level of trust. And a lot of times in discovery sessions that I’ve been a part of, that I’m not running but maybe listening in on, or as a stakeholder, or just another set of eyes and ears in the room or on the call, one big misstep that’s good to start with is just expectations and rules of the road: we’re here to solve X problem, and this is a collaborative conversation; we’re expecting people to discuss and have a discussion.
It is not a kumbaya, everyone’s-going-to-get-on-the-same-page-right-away kind of thing. We’re expecting a passionate and professional conversation, and a big misstep is not necessarily having the foundational level of trust in the organization or the teams to let that happen. It happens maybe in smaller pockets, one-on-one, but not from a broader organizational perspective.
Chris Arey
I really like that you talk about building the trust and creating an environment where people feel comfortable talking about the things they’re trying to solve for, or challenges they come across, and how they’re going to work together.
I think that segues really nicely into your next step, which is designing for people first. It’s taking those first two things we talked about: you start with the future state process design, and then you layer in use cases that demonstrate to the folks in the room how this change is going to affect them and benefit them. I feel like when those discussions start happening is when people start to let their barriers down and see that this change is going to benefit them.
So, first of all, is that right? And second, can you share more?
Sarah Wimberley
Yeah, no, absolutely. It’s very much, just like in a sales pitch, a what’s-in-it-for-them kind of conversation. Sometimes, not to harp on compliance, but sometimes it really is: we have to do this; it’s non-negotiable; we’re out of compliance now, or we know after this regulatory change we will be out of compliance, so we’ve got to get on the bus.
Other times, the product or platform is up for renewal on a contract, and you’re going through an RFP, so you’re taking the opportunity to step back and reimagine: are we doing things the way we should? Does another five-year contract with this particular vendor make sense? So, yeah, it’s absolutely people first, whether that’s employees, other stakeholder teams inside the organization, or external stakeholders.
If it’s a platform-based app, for example, your end users are the general public; in healthcare, you have patients, caregivers, providers- people can be pretty open-ended depending on the specifics of what you’re working on. But it’s important to consider the people outside the organization just as much as the people inside the organization who are maintaining the products and keeping things up and running, both business and IT.
Chris Arey
Very good. When you’re going through this part of your framework, is there anything you tend to prioritize, or things you want to make sure don’t get glossed over when you’re demonstrating this portion?
Sarah Wimberley
Yeah, so when we’re thinking about designing future state, it’s tough to separate current state platform work from the how and where of things between current state and future state, but especially in the RFP example I used, it’s really important to separate that and go platform agnostic, because you don’t necessarily know if the current solution could solve the problem.
You might need to start from scratch. You might need to reinvest in a brand new platform or a new vendor. So it’s important to take a step back and take the current state processes. And if anybody’s familiar with Lean Six Sigma, you’ve heard of SIPOC before, and that’s a process flow. They make it sound overly complicated with all their jargon, but that’s really what it is: boxes and arrows, figuring out, pie in the sky, keeping appropriate guardrails up for the industry and the organization.
But if everybody in the room had something to get solved for, everybody’s what’s-in-it-for-them was addressed, what would future state look like? Or what could it look like? Making sure concerns are addressed, gaps are addressed. That really turns into what should be the technical team’s guide, in a way, for either solving things short-term in the current state, or becoming those high-level requirements for an RFP or future state vendor.
Chris Arey
And so when you’re talking about use cases and what’s in it for them, and the technical teams, I guess the technical teams aren’t the ones benefiting, but it’s the people implementing the software, and the technical teams need to understand how to build those things into whatever new system they’re doing. Are those people in the same room at the same time?
Or are you kind of the middlewoman, going through the exercise with the hospital, hearing about their pain points, what they want to solve for, here’s how the new system’s going to benefit them, and then taking that information and relaying it to technical? What’s the dynamic there?
Sarah Wimberley
I’ve done it both ways. Sometimes calendars don’t align and you can’t get everybody in the room together. In a perfect world, though, everyone’s in the same room or the same meeting, because then everyone’s hearing it firsthand. And with the joys of Copilot and Teams and AI and all these snazzy tools nowadays, I still do take meeting notes, because that’s just the way I do things.
But you don’t necessarily need to, nowadays as a facilitator, you can really focus on facilitating. You don’t have to do double duty while also taking notes. Ideally, everyone’s in the room, and you’re recording the session for posterity’s sake. But then, for folks who can’t join, there’s some of that secondary relay. I’ve also been in scenarios where, even after facilitating one discovery session, there might be part two, part three, and then smaller offshoot working sessions, to make sure that if a particular group has really big concerns and wants to talk about it in a smaller, safer setting, I might have a smaller discussion with just that group.
But I think it really is an opportunity for everybody to get on the same page and hear from each other directly what their challenges and pain points are. And I know you mentioned maybe IT wouldn’t get as much value out of the current state, future state stuff, but I think they could, and they can.
It comes back to that base-level foundational understanding of the nuances of the business process: to know, okay, the business needs these five fields, and most of the time IT is responsible for that data getting where it needs to go. Sometimes, depending on the IT resources, they may or may not be as interested in the business use cases and the business need for it, but having that understanding can definitely help clarify and give context to the why behind what they need.
Chris Arey
Have you ever been in a situation where everyone, both parties, are in the room, and the technical team is saying we need to do X, Y, and Z, and the business operations side has no idea what they’re talking about, and you literally translate into layman’s terms? Is that something you do?
Sarah Wimberley
Yeah, it’s happened. And admittedly, it happens more often in the nonprofit space that I support, because those organizations don’t normally have a dedicated IT person or team. Most of the organizations I support or work with are volunteer-run completely, so they have no IT staff, no paid staff, period, or very minimal paid staff.
It’s a lot of sourcing the right volunteers with the right skill sets or interest to make that work, and a lot of it is translating, figuring out what that person’s background is, and finding a way to equate what they know with what they don’t know to connect those dots. It does happen, and honestly it’s a fun part of the job, figuring out how to connect those dots. And when it clicks, it’s obvious, because the conversation becomes a lot more productive, because team members aren’t talking past each other anymore.
Chris Arey
That’s got to feel really rewarding for you too, as the person helping facilitate this, to see that click, right?
Sarah Wimberley
Yeah, it’s great when you see the light bulbs go off. If there was a big neon sign over people’s heads, it would go off, because their demeanor changes. They might relax a little bit, and the way they talk becomes a little more conversational. They ask more questions; they interrupt less.
Chris Arey
They’re more engaged. Nice, I love that. And so that segues nicely into your next step here, which is connecting the dots between strategy and technology. At the beginning of this framework, we talked about the current state and identifying the problem; that’s really setting the goal for what you’re trying to solve for.
Now we’re at step four, where it’s connecting that initial process to how the technology is going to deliver on it. Is that a right description of this step?
Sarah Wimberley
Yeah, no, that’s absolutely it. When you think about connecting the strategy and the technology, it can sometimes feel top-down, but to put it in IT terminology, it’s absolutely bidirectional in a lot of ways, because I think the frontline staff can have a lot more influence on strategy than sometimes we think they do.
But it’s not always delivered at the right time. Strategy can sometimes only be developed at certain times of the year, or even every couple of years. And bridging that gap, in a lot of ways, there are definitely formal artifacts to make that happen: traceability requirements and all those fun project management-related things.
But really, it comes down to those collaborative conversations and making sure everybody is on the same page, top-down, across teams, and even from a leadership perspective. They may have developed the big-picture strategy: we’re going to be best in class in our industry, or hit X, Y, Z financial revenue, whatever the metric is they’re measuring themselves against. But the answer as to how teams get there, how the organization gets there, is sometimes open-ended.
They might have a few bullet points on how they’ll get there, but they really need streamlined technology costs, in a lot of ways, to help move that needle, and more efficient admin costs, whether that’s staff members being more effective and efficient day to day, or getting the right resources in-house to make sure everyone can continue to move the needle. So it really, unfortunately, continues to come down to collaboration and communication across the board.
Chris Arey
So, strategy, two-part question. Is strategy something you communicate throughout the whole engagement, something you continue to bring back up so it stays top of mind for people, so they know why you’re doing this?
Sarah Wimberley
It can be really effective, yeah. I’ve seen it work a couple of different ways, depending on the audience. But it can be really good, just like we mentioned with rules of the road before a discovery session: setting the stage and setting expectations. These are the teams we have represented in the room or on the call. And once you identify the problem you’re trying to fix, having that on screen that everyone can ground themselves in is huge.
Having that as a recurring reminder, just to ground the conversation and remind everyone that no matter what sidebar conversations have been happening, or what tangent we might roll into during the discovery call, we still need to circle back to, is this going to solve the big-picture problem? And that ties back to the strategy.
Chris Arey
Second part of that question: since the technical teams and the business operations teams speak in different terms, while they work together to reach the goal and solve the problem, are their strategies documented differently because of the way they work and operate?
Sarah Wimberley
Yeah, so said another way, because the technical teams, the IT teams, are just more technical; they do operate differently. I think when you’re a person who’s very analytical, more data-driven, you might naturally gravitate towards analytics-type jobs, reporting-type jobs, data analyst or data engineer type jobs. And if you’re more marketing, or more business operational, you gravitate more towards non-IT jobs.
There are definitely folks like me who have a foot in both worlds, which is fun, but also kind of a little bit dangerous, because you can kind of see through it. And when there’s that crosstalk, where IT or the business is using terminology that’s really hyper-specific to their industry, and they don’t do it intentionally- that’s just the language they’re used to using- I’ve definitely done my best in those circumstances to restate what they’re saying in normal English, or in the business terminology, to help bridge that gap.
In a way, it’s translating, but I’m not an expert in pipelines or Python or any of those things the IT folks are. And I’m not boots on the ground from an operational, marketing perspective in a lot of these conversations either. So, I restate it in a way that’s less tech and less IT, to make sure the marketing people or the business teams are following along, and also so that the IT people are validating that the way I’m understanding what they said is accurate.
Those kinds of translation conversations work in more than one way, which is good.
Chris Arey
And so your fifth and final step here, which I feel like has been a major theme of today’s discussion, is keeping the lines of communication open. Do you want to elaborate on that a little bit?
Sarah Wimberley
Yeah, we talked about it a fair bit, the trusted foundation. If you’re newer to an organization, it’s definitely tougher, because you’re coming into well-established patterns of behavior and conversation and team culture that you’re not necessarily as familiar with.
But when you’re starting on a net new project, everyone’s starting from scratch, really, in a way. As a result, building on that trusted foundation is absolutely huge. Being proactive is difficult because it’s a lot of work, especially when you’re getting started on a project, but it pays off in a big way down the line.
When you are first beginning that process, having sidebar one-on-ones with new people is a great starting point. I also find that if you’re new on a project or new in an organization, it can help to maintain an open-door policy so that teams or individuals can come have a conversation with you should they have questions or concerns.
That’s something I try to say in every discovery session, every meeting I have: if anybody has any questions or concerns they’re not comfortable asking or raising in the call, reach out to me, because sometimes there’s concern over maybe they misunderstood something that was said, and they don’t want to openly argue or disagree, but they really just want to make sure they’re on the same page.
Having those lines of communication open from the very start is huge. And then, as more and more projects happen and more engagement happens with those different stakeholders, it’s only going to build that relationship trust in the organization and make further conversations easier, and later projects easier. And then, if push comes to shove and there’s a challenge in the work you’re doing, you at least have that foundational level of trust to be able to have those tough conversations and, hopefully, have them be productive and get to a good outcome for everyone involved.
Chris Arey
Yeah, I really like that too. From the very beginning, being transparent, being collaborative, establishing a process for having these kinds of conversations. It might feel like something you have to make a conscious effort to do in the beginning, but like anything, with repeated behavior, you keep doing it, keep reiterating that this is the way, don’t be afraid to speak up, and there are several ways to do it. I feel like you do that so often throughout the entire engagement that it becomes almost a gut instinct for these folks to know that communication, at the end of the day, is everything, right?
Sarah Wimberley
Yeah, yeah, and turning it into gut instinct is absolutely right. Any new habit is tough, no matter what it is. Like, I’m trying to cut sugar right now, and it’s insane. I’m constantly finding Oreos, and it’s not great.
Any new habit is tough. So it’s asking the question, raising your hand. Change is not easy, no matter what. If you’re being very intentional about it and putting in that conscious effort, it does get easier over time, and, to your point, it becomes gut instinct, and looking back, you’re like, why did I take so long to get on this bandwagon?
Chris Arey
That’s the moment that makes it all worth it right there. Well, thank you so much, Sarah. We talked about your five-step framework here: defining the problem, bringing the right people into the room, designing for the future state, connecting the dots between strategy and technology, and this last point of keeping the lines of communication open.
That’s awesome, I love how digestible that was. We’re getting close to time, though, and before we wrap up, I always like to ask my guests: if you have one actionable takeaway for the audience, what would it be?
I’d love to hear this: your 30 to 60 seconds, you have to know this, it’s the most important thing. What have you got?
Sarah Wimberley
Yeah, and I guess my closing thought is related to our conversation, but a little bit bigger. I would challenge everybody to do the scary thing. That scary thing could be a little different for everybody. For me, the scary thing was public speaking, but for you it could be building the network.
You might have folks in these meetings you’re working with that are maybe challenging individuals, or people you don’t know as well, but reach out to them and have virtual coffee, or real coffee. Build the network, right? Build the network and start to get that foundational trust going for yourself. It doesn’t need to be a big thing, and you don’t have to meet with everybody.
But I think that’s something really tangible, that if you’re in these types of conversations, discovery sessions, or requirements conversations, or you’re wanting to move into an architecture-type job or a program-manager-type job, where you’re playing this translator role, having the support and trust of your stakeholders will go a really long way.
Chris Arey
I really like that. That’s a first on the show, but it’s so memorable, and it’s just good advice, period: do the scary thing. Wonderful.
Well, thank you so much, Sarah, it was a pleasure chatting with you this morning. For those of you listening in, if you have questions about today’s discussion, want to learn more about the framework, how RPI can help, or want to learn more about Sarah and Ulster Technologies, we’d love to hear from you. You can contact us at podcast@rpic.com.
Sarah Wimberley
Yep. Thanks.
Chris Arey
Again, that’s podcast@rpic.com. Until next time, thank you.
