A Day in the Life: Trish Craine (Technical Program Manager, Squarespace)
Trish shares with us her story of becoming a Technical Program Manager, what her typical challenges are and the tools and methodologies she uses to manage her workload.
What has been your journey in tech so far?
I feel like I’ve always been a project manager, even when I was a kid. At a young age, I was always trying to find the most efficient way to do something and had a keen awareness of dependencies. My liberal arts education (read: English Literature major) led me to the book publishing industry, where I eventually became a managing editor at a publishing house — effectively, a project manager of making books. When a redesign of one of the company’s websites was going sideways, I was given the opportunity to project manage my first software project, and I haven’t looked back since.
In all my project and program management roles since then, my favorite part of shipping software was working with a cross-functional team — especially the software engineers. With each move and role change, I worked more and more closely with engineers; learning from them and proving the value of project planning to them (it usually took them a while to come around, but I got them there).
I joined Squarespace when the Technical Program Management (TPM) team was in its infancy (I was TPM #3!) and worked with teams in our Infrastructure Engineering organization before taking on a team lead role once our team started growing. Now, as a TPM Manager, my teams’ programs span across our Infrastructure, Product, and Security & Compliance Engineering organizations.
Briefly describe the role of Technical Program Managers at your company
Simply put, TPMs aim to make shipping software easier and more predictable at Squarespace. From asking tough questions in meetings (“How do we know we’ll be done with this feature?”) to updating our stakeholders on project status to driving technical roadmaps to meet company goals, we help drive the project planning and delivery process by systematically identifying and solving problems.
A big differentiator for TPMs amongst our peers is that — while everyone wants to get the right work done as quickly as possible — TPMs focus exclusively on maintaining efficiency and effectiveness. This allows members of our cross-functional teams to focus on their areas of expertise. So, engineers can focus on the technical approach and execution, and product managers can focus on identifying and defining the work that helps us reach our goals. We help these cross-functional teams work and deliver together by scoping, scheduling, and tracking the project, as well as identifying, tracking, and removing risks and dependencies.
What has been the biggest challenge you’ve faced moving into your current role? How are you working to overcome the challenge?
Having built a career as an individual contributor, it was a tough shift in mindset when I was no longer managing my own program, but instead taking responsibility for the output of others. At times I found myself handling obstacles my team was facing as their peer, but I was the person who could actually unblock them by making a priority decision and increasing their bandwidth. Once I fully realized that I can help improve the output of others — whether by coaching or unblocking them — I was able to support my team more effectively.
What does your typical day look like?
My days are usually split between weekly one-on-ones with my team (direct reports, manager, and fellow TPM leads) and pockets of time where I can focus on what I need to get done for the week, like strategic thinking around TPM staffing and giving input on our company’s planning process. The dedicated time to speak one on one with my team every week is the best place for me to hear about their wins, understand and coach them through their challenges, learn about risks a business-critical project is facing, and pass on any information I have that can help them move their work forward. The time I spend with my manager is similar, but with me on the other side, and when I meet with my colleagues who are helping lead the TPM team, we learn from our shared experiences and take action on things that will help our team overall.
For my own work, I apply Scrum methodology, which is ingrained in my head after years of coaching teams on it. That long list of ideas, projects, and to-dos in my head? That’s my backlog. The stuff I need to get done this week? That’s the sprint (chosen backlog items) I committed to.
There are three very real ways that applying Scrum methodology helps me in my day to day. First, as new to-dos come up during the week as they inevitably do, adding them to my list for the week forces me to think about if I can still get everything done or if the least urgent thing should move to the next week (sprint). Second, when I have focus time between meetings, instead of wasting time figuring out what I should work on, my list for the week takes the thinking out of those moments; I can quickly get to work feeling confident that this is the right thing to spend my time on. And lastly, if I’ve planned and adjusted throughout the week properly, the sense of completion at the end of the week is really satisfying (and if I haven’t finished everything, it’s a lesson learned to take on a little less next week).
What’s the best and worst part of your job?
Instead of getting my energy from shipping software, these days the best part of my job is matching my team with the right opportunities and seeing them succeed and add value to the company. I’m grateful that so many of those opportunities have been in that sweet spot of filling an important business need and getting that team member closer to their career goals.
One of the hardest things about this role is that I have almost no day-to-day interaction with individual engineers or cross-functional team members, which was my favorite part of running a program and the projects within it. In practical terms, this means I have a very small pool to choose from when peer reviews come around, but overall I just miss the camaraderie of a large project team who’s solving problems together and learning from each other.
What is the best piece of advice you’ve received?
I’ve always gravitated toward being transparent. When I was running a program with projects, I made sure that my teams knew every piece of information I knew. Having shifted into a management role, my instinct for transparency remains strong, but it’s not always required and can sometimes create confusion or frustration. I’ve been advised to ask myself: “Is this piece of information truly going to help this other person?” That has helped me clarify the intention of my instinct to overshare.
What is your most useful resource (book, blog, newsletter)?
Lara Hogan, who is a management coach for the tech industry, gave a talk at Squarespace a couple of years ago on sponsorship and mentorship that really resonated with me. (The irony is not lost on me that having this opportunity to share my version of “A day in the life” is the result of being sponsored by someone.) Since then, I listen to everything she has to say and find that her advice is an appealing blend of concrete actions managers can take to improve and timely topics (e.g., inclusivity and leading through crises).
What’s one thing you’d like to learn, develop or work on in 2020?
I want to master the art of being brief and to the point when communicating.
