Skip to content

Technical Program Management

Relentless drive towards results

TPMs own "when" something is going to get done top most, getting products out the door. Get shit done; figure it out.

PM owns -> what will the team do, what are the goals and priorities

SDM -> owns the details of how we do it

TPM -> owns making sure the top level technical plan is viable AND when we're going to deliver this thing. Get the thing out the door.

TPMs never quit, when it gets hard/rough we find a way around it. And if it's not possible we'll figure out what is.

Not a clipboard carrier. Not a project manager. Not a date pusher. PjM is definitely part of the job but it isn't the whole job.

Need technical acumen to understand systems and dependencies.

Super important to build relationships. Must be outgoing. Tribal knowledge is a fact of life, TPMs actually need to build a lot of that up to be effective. Then use playbooks and information sharing to help disseminate and share so the TK isn't hoarded (TK always exists, fact of life).

TPM is a watermelon hunter.

TPMs need to lead with a lot of influence. Influence comes from earning trust. Need to earn trust from all stakeholders but especially engineering. Be respectful, listen, be helpful. Not a date pusher or beat you up about a status report.

I want to actually understand the challenges you face so I can help you AND add value. Whether it's information, or suggestion, or technology, or help. TPMs do a lot of coaching.

Be a source of help. Full stop. Providing resources, or escalating a conflict, or bringing clarity. BE USEFUL.

Work the non-functional requirements. Are downstream teams/systems ready for more load? Disaster recovery & backups, security & compliance, data residency.

Knowing which teams will take longer or are harder to work with. TPMs know who they need to get to first; and you need to figure this out ASAP when you are new.

Be curious. Go dig in to things yourself. Technical acumen matters, this is the T. Read the wiki, read the code, talk to an engineer and understand. Need to be capable of this.

You need to like pulling on threads to understand how things work. Need to be curious and like to understand how things work.

never give up, delivery matters, doing it in a timely way matters -> that is the job

  1. be proactive
  2. have grit
  3. always speak the truth
  4. dont let things fester
  5. be resourceful
  6. chase things down
  7. relentless drive towards results

Executives worry a lot. They deal with a lot. tl;dr of all reports is essential. Reliable and frequent communication is expected. No news is TERRIBLE news. Green things often get no followup, which is ok, but leaders will respond to Yellow and Red things and help. Exec's job is to deliver 100 different things in their portfolio.

When you encounter something unachievable, you work to reset the expectations.

Work with product to shape the work and give the upfront insights. Take the product plan and help break it down into a project plan along with eng -> find the dependencies, the rough spots, the unknowns -> then action on them and repeat

Track all the things, hold people accountable, make sure momentum is sustained

Ask lots of questions, probe when someone raises a concern and make sure the details are captured and not hand wavy concerns or FUD

Setting up a TPM org

Visibility across the org on priorities and roadmap. Keep teams organized, keep product honest. Help get frameworks in place.

Status reporting of work to be delivered. Create awareness, dig into the Reds and Yellows, share info and ensure dependencies and stakeholders are informed and aligned.

Celebrate the wins, keep teams functional and happy. Recommend process improvements, get involved in Agile ceremonies as needed. But scale self and empower engineering teams to own their own process.

Quarterly planning process in place with rigor.

Measuring impact in place with rigor.

Work the most critical programs for leadership. Put out the fires, ensure the biggest and riskiest programs are successful.

Coordinate huge bodies of work that span CapOne Software and other parts of CapOne.

Status reporting, rolling up to executives so they get R/Y/G info and summaries. Flag early and often when help is required, do not let things fester.

DACIs and decision register to capture details and create artifacts for reference.

Every project needs a plan. The spec is not the plan.

Make sure you're not leading death marches. Reset expectations as needed. Present tradeoffs: you can fix this with more resources or by focusing on problem X first and moving the date out to Y.

Coaching, TPMs do lots of coaching.

Non-functional requirements

Big part of the job is picking apart the non-functional requirements and ensuring what is delivered can function and scale.

tl;dr Fault tolerance, performance, & SLIs

  • Availability -> percentage of time service/infra is operating normally
  • Reliability -> MTBR and MTTR, frequency and impact of failures
  • Scalability -> can the system handle an increasing workload without compromising performance
  • Maintainability -> operability (smooth operations under normal conditions), lucidity (simplicity of codebase), modifiability (capable of expanding without rewriting it)
  • Disaster recovery -> RTO & RPO
  • Data & storage