Interview with Dorothy Paredes: Career Paths to TPM, Public Safety Agile, and more

This was first published in my newsletter, Velocity Agile. Subscribe to get new posts and interviews about agile every month, direct to your inbox.

Subscribe to Velocity Agile

Last month I had the opportunity to sit down with Dorothy Paredes — Technical Program Manager at RapidDeploy, for a great conversation. This transcript has been edited for brevity.

Ed: Let’s start with your journey to being a technical program manager and into this field as a whole. Tell me a bit about how you got into this role?

Dorothy: It’s kind of funny because when I think back on it, I feel like it started decades ago when I was working at Samsung Austin Semiconductor in their quality department. All the software was developed in S. Korea, where the company was headquartered, and part of my duties was to outline and lead the plan for rolling out the new programs which started my journey into project management.

At Samsung I got my hands into Quality Assurance, particularly understanding quality auditing practices, Lean, TPM, and quality control. Then software tech really started becoming more of an industry in Austin, and I moved to what’s now Advisory Board (at the time it was called Crimson), who developed software for performance metrics for hospital systems.

I worked my way up into quality management and saw myself having a long term career there. Then we went through an acquisition and my role changed to a principal engineer. At the time, I was sore about the change because I’d been really trying to work my way to a leadership position. During my time in QA, planning was central. Planning releases, how and what to test, understanding impacts, determining how to meet timelines and customer expectations — sound familiar!?!

At the time of my role change, I felt like I was set up for a little bit of failure because I was not a coder or had a software engineering degree. Looking back, though, I feel like it could have been an opportunity. I could have taken time to learn to code or learn some basics to understand what engineering management really was like.

Ed: That’s interesting, that imposter syndrome of becoming an engineer, when you’re not from a software engineering background, can be really hard when you’re in this industry.

Dorothy: I felt like an imposter. QA was shifting to be under engineering, which, if you’re coming from a traditional software QA role, that’s seen as conflict of interest. I was asking myself ‘Do I still want to continue QA or do I want to go down another route?’

That’s when I had to do some personal digging and really understand what I was interested in and what I wanted from a caterer. That’s when I became very interested in roles in tech around project and program management. They were very new in 2016, which I think they’re still kind of new. To be honest, I think the industry as a whole is trying to figure out what to do with us. I like how it’s a strategic role and I don’t think people really focus on that a lot for project and program management.

I loved working with the product and engineering directors to define the direction of the product, being an advocate for quality. I really enjoyed the strategic side of planning and collaborating across teams to see through the implementation of a product or key features.

That led me to my decision to go into project and program management.

Ed: So many points I want to pick up, but lets talk around the strategic element of program management. Could I ask you to just talk a little bit more about what you think is the strategic element of being a program manager, and how you can help the organization in that way?

Dorothy: That’s a great question. I think it comes in two pieces, the first piece that came to mind was a lot of times we get our initiatives from a person in a leadership position — it’s usually a manager, Director, VP, CTO. So a lot of people think it’s task management, but really it’s more strategic because we have to understand what the ultimate goal of this project is going to be and how it’s going to impact the company. We really do have to make sure that we’re clear on what was said and what is expected.

What I find the irony in, is that sometimes that’s the hardest part to figure out. Why are we doing this? What’s the point of it? What are the outcomes we are trying to drive? Understanding the strategy of the project, overall, and how it plays into ultimately the bigger picture of the organization.

Ed: I think that’s exactly true — there is a big difference between having something completely defined for you versus what actually happens as a program manager, which is an idea and shaping that idea into something that can actually be something useful is the most enjoyable part, but also the hardest part.

Also, while you’re going through the project you become the subject matter expert for that area, so you become the person who knows everything about it because you’re taking the different disciplines to get things done. It also means that you end up being pulled in strategically for your view on how the project links in with other programs and initiatives, and for your views on what we should do next.

Dorothy: You’re actually contributing a lot yourself or you’re pulling the stakeholders together. If I think about my day to day at Babylon or my day to day at RapidDeploy, most of the people that I’m working with are at a director level or above in strategic roles. I’m providing them with information that will help them make a decision on what we’re doing within the business. So you’re right — we become connectors.

Ed: You are that collaborator bringing everyone together, which is really interesting. So let’s talk a little bit about Rapid Deploy. If you just tell us a little bit about what Rapid Deploy does?

Dorothy: RapidDeploy builds mapping for public safety call centers. The mapping pulls location information from as many sources as possible so that we can help our first responders get to where they’re going safer and faster.

Ed: That’s super cool, I’ve never heard of a company doing something like that. So, what is the product?

Dorothy: It’s a couple of things which are really interesting about this space. We have a product where there’s actually a piece of hardware that goes into the centre, and it connects with their systems. I never really thought about this until I was in their space, but if you’ve ever seen the pictures of 911 dispatchers, they sit with lots of screens. They’re managing so many feeds of information — I don’t know how they do it, it’s amazing.

RapidDeploy is a disrupter in terms of trying to put these products in the cloud, because right now 911 call centers have their own on-premise servers and hardware, which can cause latency. This matters when losing a fraction of a second in life or death situations.

Ed: Interesting, okay, so Dorothy what do you do day-to-day?

Dorothy: My role is a Tech Program Manager. It’s interesting being a program manager in a tech company, because I think yes, we do manage projects and we roll out strategic initiatives, but I think a lot of times we also end up with a big variety of projects. We’re not like construction project managers where all your work is construction projects.

Right now I’m working on projects to help improve organisational efficiencies. We’re trying to really get ourselves established with our agile processes — we’re trying to understand our life cycles, working with our business stakeholders, and how we can do cross functional alignment better.

Ed: Could you tell me a little bit more about those projects, like what are you trying to do specifically?

Dorothy: Yeah so more specifically, we are just trying to move the needle forward on really being more of an agile company. This is more of a challenge when serving one of two spaces, and that is healthcare or government — anything that has to do with public safety.

While we are building technology, our customers are much different than the customers of Facebook, Google or Atlassian, who can literally roll out anything whenever they want and people will consume it. They’re not promising to give me a feature. We have a different way of having to do that, because of the customers that we serve.

Ed: How do you go about agile in healthcare or government, where do you think are the places where we can still apply agile ways of working?

Dorothy: I saw the same at Babylon — the bottleneck is; we want to be an engineering company that puts releases out every two weeks, we want to be fast, we want rapid deployment, we want continuous integration, we want continuous development, we want to get to blue green deployments. That’s the golden devops model, we want to get there.

Problems arise when customers don’t know how to take on releases that fast. Our users can’t consume features that fast, so how do we get things out at their speed while also needing to fix things that are broken in production. I think it’s an interesting dynamic that we have to try to find in the tech space, specifically for healthcare tech, public safety tech, government tech.

Ed: I’ve never heard it put that way before and I think it’s a really interesting insight.

I wonder if that’s a problem with other B2B businesses. I suppose it might be another problem if you’re rolling out the latest version of Oracle to loads and loads of different companies — it’s probably the same perception of it being a slower deployment process that comes out on a regular basis, compared to the companies you mentioned beforehand, which is a lot more customer facing businesses rather than B2B.

Dorothy: I wouldn’t be surprised if they’re facing those same issues as well, because I think the other problem when we say ‘we want to be agile’ is defining what that means. We all have this idea that being agile means fast deployments, but that’s not to me necessarily what it means being agile.

It means we have a plan for this product and we’re going to deliver this amount of features, but we get customer feedback. It would be great if someone could define what agile is for a healthcare tech company, or a B2B tech company, because I do think that there are inherent differences in those, especially when you start bringing in the contractual factor.

Ed: What do you like and what do you dislike about your current role, what is it that really motivates you to get up in the morning and what is it that you dread?

Dorothy: I do feel as project and program managers you really get to see the value of your work. If you’re working to roll out a whole new system that’s going to go into the hands of your users, you get a lot of value from seeing the work that you are managing be useful.

I enjoy working at the strategic level, working with the directors and VP and understanding the direction and really helping to drive that direction. I think another thing about project management is I enjoy being able to provide opportunities for improvement and I think that’s another big thing about our role that gets maybe overlooked.

Ed: What about dislikes?

Dorothy: Sometimes, I find the level of documentation that program managers have to do not the most fun. I can be a procrastinator at that.

I think the other dislike — and this isn’t specific to just Rapid Deploy, this goes along with just being a program manager in the tech industry — is that it can have this stigma of waterfall. That we have to plan and we can’t deviate from anything. There seems to be a lot of project management bashing in the industry, especially in software engineering, people think it’s going to hold them back.

Ed: Thank you so much Dorothy for your time and insights.

Dorothy was also kind enough to provide a list of book and resource recommendations from her career. Here they are:

Top Agile Project/Program Books:

• Solutions for Agile Governance in the Enterprise (Sage)
• Manage Your Project Portfolio

Top Books for Work Management

• Radical Candor
• Radical Focus
• Making Work Visible

Book to help with being in Tech Space

• Accelerate
• The Agile Samurai

Books for Strategy

• Project to Product
• HBR Guide to Thinking Strategically
• Good to Great