APIs, Process, and Getting with the Program Link to heading

Four months into working at Australian Payments Plus, and I’m still adjusting to what it means to work in financial services at scale. Coming from smaller teams where you could wear multiple hats and change things quickly, the structure and processes here have been both eye-opening and necessary.

The Reality of Specialisation Link to heading

In my previous roles, I could be designing the database schema in the morning, implementing the API in the afternoon, and tweaking the frontend styles before heading home. At AP+, that’s not how things work.

We have people for that.

  • Frontend team lives and breathes React, handling the web interface
  • Mobile teams (iOS/Android) with dedicated native developers
  • Backend/API engineers (like me) focused purely on TypeScript/Node.js services
  • DevOps team manages the serverless infrastructure and deployment pipelines
  • Database administrators who understand the performance implications of every query
  • Security team that reviews every change touching financial data

I’m here as a backend/API engineer, building JSON APIs in a TypeScript/Node.js world. No frontend work, no mobile; just pure API design and business logic. The adjustment has been significant when you’re used to controlling the entire stack.

API Contracts Are Sacred Link to heading

This was probably my biggest cultural shock. In smaller teams, if you need to add a field to an API response, you just… add it. Maybe mention it in Slack. Deploy when ready.

At AP+, API contracts are sacred agreements between teams.

The Reality of API Changes Link to heading

When I casually suggested adding a new field to our user profile endpoint:

Me: “I think we should add a last_login timestamp to the user object.”

Team Lead: “That’s a breaking change. We’ll need to:”

  • Document the change proposal
  • Get sign-off from the mobile team
  • Update the API documentation
  • Version the endpoint
  • Schedule the rollout across environments
  • Coordinate with QA for testing
  • Create migration documentation

What I thought was a 10-minute change became a 2-week process involving 6 different people.

The Jira Industrial Complex Link to heading

Coming from smaller teams where we used GitHub issues or simple project boards, entering the world of enterprise project management has been… educational.

The Ticket Lifecycle Link to heading

Every piece of work must flow through The Process™:

  1. Epic Creation - High-level business requirement
  2. Story Breakdown - Epics become user stories
  3. Story Pointing - Team estimates complexity
  4. Sprint Planning - Stories allocated to sprints
  5. Development - Actual coding (finally!)
  6. Code Review - Pull request review process
  7. QA Testing - Dedicated testing team
  8. UAT - User acceptance testing
  9. Release Planning - Scheduled deployments
  10. Production Deployment - Often weeks after coding

The first time I created a ticket for what I thought was a simple bug fix, it came back with comments like:

  • “Please add acceptance criteria”
  • “Story points missing”
  • “Component field not set”
  • “Missing business justification”
  • “Needs security review flag”

Learning from Better Engineers Link to heading

The flip side of all this process is working with genuinely excellent engineers who’ve solved problems at scale I’ve never encountered.

The Frontend Specialist Link to heading

Even though I don’t touch frontend code, I occasionally need to understand how our APIs integrate with the React components. One conversation with our lead frontend developer was enlightening:

“Your API response structure makes our component rendering inefficient,” she explained during a cross-team review. “Can we flatten this nested object?”

What followed was an education in:

  • How API response shape affects component performance
  • The cost of deeply nested object access in React
  • When CSS-in-JS solutions prefer certain data structures
  • Why frontend teams care about response predictability
  • The frontend implications of API design decisions

The API Architect Link to heading

The senior backend developer who designs our APIs thinks about problems differently:

“Size is irrelevant, but accuracy is not,” he said during code review. “This settlement file processes hundreds of thousands of dollars daily. It must be accurate to the cent.”

His approach to API design considers:

  • Data accuracy and validation at every layer
  • Idempotency for financial operations
  • Audit trails for every transaction
  • Backward compatibility for mobile and web clients
  • Rate limiting and abuse prevention
  • Monitoring and alerting at the endpoint level

The DevOps Engineer Link to heading

Our DevOps engineer casually mentioned they’re migrating us from containerised microservices to serverless functions. “The existing system was built by multiple teams over multiple years,” she explained. “The stress is starting to show as we scale; it’s punishing the main user database.”

Their perspective on reliability makes my previous “it works on my machine” approach seem dangerous in a financial context.

The Tools of Big Business Link to heading

The tooling ecosystem in large companies is overwhelming but comprehensive:

The Atlassian Suite Link to heading

  • Jira for project management and issue tracking
  • Confluence for documentation and knowledge sharing

Gitlab Link to heading

  • Repository Deeply neseted project storage for code and pull requests
  • Runners for CI/CD pipelines

Monitoring and Observability Link to heading

  • DataDog for log analysis and alerting
  • Grafana for application performance monitoring
  • ServiceNow for IT service management

Communication and Collaboration Link to heading

  • Slack for team communication (thank goodness)
  • Microsoft Teams for company-wide meetings
  • Miro for collaborative whiteboarding

Each tool has its purpose, integrations, and training materials. The learning curve is steep, but the integration between tools is impressive once you understand the ecosystem.

The Deployment Reality Link to heading

Every change, no matter how small, goes through multiple approval gates because money is involved:

Production Release Cadence Link to heading

Production releases are few and far between, and never on a Friday.

When hundreds of thousands of dollars flow through the system daily, there’s no room for errors. A simple API endpoint change becomes:

  • Week 1: Create Jira ticket with detailed acceptance criteria
  • Week 2: Sprint planning, story gets accepted and pointed
  • Week 3: Development and comprehensive unit testing
  • Week 4: Code review focusing on financial accuracy
  • Week 5: QA testing with real transaction scenarios
  • Week 6: Security review for financial compliance
  • Week 7: UAT with actual settlement file validation
  • Week 8: Staging deployment with production-like data
  • Week 9: Final approvals and deployment scheduling
  • Week 10: Scheduled production deployment (not Friday)

If the money stops moving, it’s all hands on deck and crisis calls.

What I’m Learning to Appreciate Link to heading

Despite the frustration, there are genuine benefits to this approach:

Financial Accuracy Link to heading

The Beem app handles millions of transactions. The process exists because when things break, money stops moving. Settlement files must balance to the cent across hundreds of thousands of dollars daily. The careful approach isn’t just about scale; it’s about accuracy.

Knowledge Sharing Link to heading

The documentation requirements mean institutional knowledge isn’t trapped in individual heads. When someone leaves, their knowledge remains accessible.

Risk Management Link to heading

In financial services, mistakes aren’t just embarrassing; they can be regulatory violations with serious consequences. A prod P1 incident demands everyone’s attention. The approval gates catch issues before they become crisis calls.

Team Collaboration Link to heading

The defined processes mean everyone knows what to expect. Handoffs between teams are smooth because everyone follows the same playbook.

Adapting My Working Style Link to heading

I’m learning to work within the system rather than fighting it:

Instead of making incremental improvements one at a time, I now batch related changes into larger pieces of work that justify the process overhead.

Invest in Documentation Link to heading

Since everything needs to be documented anyway, I’ve started writing better documentation from the beginning rather than treating it as an afterthought.

Build Relationships Link to heading

Understanding who needs to approve what has made me more strategic about stakeholder management. Building relationships with the QA team, product owners, and DevOps engineers makes the process smoother.

Focus on My Expertise Link to heading

Rather than trying to do everything, I’m focusing on becoming genuinely excellent at my specific domain while learning from specialists in other areas.

The Big Picture Link to heading

Working at AP+ has taught me that different organisational sizes require different approaches. The agility and flexibility of small teams comes at the cost of reliability and coordination at scale.

The process that feels bureaucratic is actually the solution to coordination problems I’ve never had to solve. When you have hundreds of engineers across dozens of teams all working on interconnected systems, the overhead of coordination becomes justified.

I’m still adjusting, but I’m starting to see the wisdom in systems designed for accuracy rather than speed. The question isn’t whether the process is good or bad; it’s whether it’s appropriate for the stakes of the work.

At AP+, where we’re handling financial infrastructure for millions of Australians, maybe a 10-week process for an API change that affects settlement accuracy is exactly the right level of caution.

Looking Forward Link to heading

Six months in, I’m starting to appreciate the benefits while still missing the agility of smaller teams. The key is finding ways to be effective within the constraints rather than fighting against them.

The engineers here are genuinely excellent, and the scale of problems we’re solving is fascinating. Learning to work effectively in this environment is making me a better engineer, even if it sometimes feels like I’m moving through molasses.

Plus, there’s something to be said for knowing that when you deploy to production, there’s a whole team of people making sure it doesn’t break anything important. The safety net is reassuring, even if it comes with process overhead.

What’s your experience working in large organisations? How do you balance process with productivity, and what strategies have you found for working effectively within corporate constraints?