Meet the Engineer: Shankar Gopalakrishnan

Meet the Engineer is a recurring series on the Docusign Engineering blog where we sit down with the people building our platform, in their own words. The clearest way to understand what it's actually like to work here is hearing our engineers talk about the problems they're solving and how they think.

What are you working on right now, and what’s the hardest part of it?

I'm working on the next phase of Storage-as-a-Service, especially the multi-cloud platform for Docusign Redis, PostgreSQL, SQL MI, and Docusign Blob. The work spans the control plane, data plane abstractions, security guardrails, and clear ownership between platform and product teams.

The hardest part is sequencing. It's tempting to describe this as "build an abstraction layer over clouds," but that's only the beginning. We have existing workloads, regulated environments, and legacy dependencies that need a safe migration path, not just a new API. We also want each cloud to operate independently wherever possible, rather than hiding cross-cloud routing and failure modes behind a layer that becomes difficult to reason about.

Outside of work, what’s something you’re into that ends up shaping how you think about your job?

Outside work, I do a lot of road cycling, including a recent ride from Seattle to Portland, Oregon (206 miles). When I think about road cycling, I see it as a perfect model for how complex systems behave under pressure. You can't just brute-force your way through a ride. You have to understand the system from first principles, like power-to-weight ratios, aerodynamics, and energy conservation. You're constantly managing feedback loops, monitoring your heart rate, power output, and physical fatigue against the changing terrain and the dynamics of the pack.

The most valuable lesson is realizing that a simple local fix, like a sudden, aggressive burst of speed to chase a breakaway, can have negative second-order effects, such as exhausting your energy reserves or breaking the cohesion of your team before the final climb.

That mindset carries directly into my work at Docusign. It makes me patient with ambiguous problems, skeptical of "heroic" solutions that optimize for only one metric, and focused on building robust systems that remain sustainable, predictable, and understandable even when the pressure is high.

What’s a problem unique to Docusign’s scale that you didn’t anticipate until you joined?

I expected scale to mean traffic, data volume, and uptime requirements. What surprised me was how much of the difficulty comes from the interaction between systems, teams, clouds, and compliance boundaries.

A decision that looks local, like how we provision Redis, how a service accesses Blob, or who owns a storage abstraction, can affect hundreds of services and multiple operating environments. At Docusign's scale, the challenge isn't just making one system work. It's creating a common platform contract so product teams can move quickly without every team solving provisioning, security, and disaster recovery differently.

The goal is to give teams a consistent experience while allowing the underlying implementation to be cloud-agnostic, depending on where the workload runs.

Nearing the finish line in Portland, Ore.

What’s the most interesting problem you’ve solved that customers will never see or know about?

One of the most interesting problems is making a restricted environment operationally safe without giving every engineering team direct access to it.

For restricted environments, the model requires a secure operations team to execute deployments and incident actions, while service teams provide the code, configuration, runbooks, and subject matter expertise. That creates a proxy-and-evidence workflow via standardized pipelines, a single deployment record, scrubbed logs, and clear escalation paths.

Customers will never see those mechanics. They should simply experience a service that's available, secure, and deployed consistently. But underneath that outcome is a lot of careful engineering around access, evidence, alerting, ownership, and fail forward behavior.

What’s a bug, outage, or incident that taught you something you still carry with you?

A recurring on-call pattern taught me more than any single dramatic outage. First-time deployments were failing repeatedly, while teams were also dealing with pipeline failures, Terraform state drift, Key Vault and DNS issues, and unclear ownership across teams.

The lesson was that recurring operational pain is usually a platform-as-a-product design problem, not just an on-call problem. The right response isn't to ask engineers to become better heroes. It's to create an operation-ready gate, actionable runbooks, and a deployment flow that captures evidence and validates the customer journey.

I still carry that lesson. A platform isn't complete when the happy path works. It's complete when the next team can operate it safely at 2 a.m., during a migration, under compliance constraints, and without needing to reconstruct tribal knowledge.

What’s the best piece of code-review feedback or architectural advice you’ve received since joining?

Make the tradeoffs explicit, especially the uncomfortable ones. Say what the design optimizes for, what it doesn't solve, what can fail, and what the recovery path is.

That advice has shaped how I review and write proposals. I try not to hide uncertainty behind confident language. If a migration isn't yet defined, if a rollback is unsafe, or if a dependency creates an operational risk, it's better to say that directly and design the next decision around it.

What made you choose engineering, or what keeps you in it?

I chose engineering because it combines analytical thinking with the chance to build something real. What keeps me in it is the leverage. A good design, a well-chosen abstraction, or a reliable platform can make hundreds of other engineers more effective.

At Docusign, that leverage is connected to workflows people genuinely depend on. The work is satisfying because it isn't technology for its own sake. It's about building trust infrastructure that has to hold up under real business and customer pressure.

What’s a skill you’ve had to build that surprised you the job required?

Executive-level technical communication. I came in with a bias toward technical depth, but the role increasingly required me to communicate architectural tradeoffs in terms of customer risk, operating cost, sequencing, organizational ownership, and investment decisions.

The skill isn’t simplifying the technology until it becomes vague. It’s preserving the important complexity while making the decision understandable and actionable. My current work has been a great forcing function for that because the design touches platform architecture, cloud strategy, security, compliance, migrations, and team boundaries at the same time.

What does career growth look like for you at Docusign, and how has the team supported your professional development?

Career growth for me has meant expanding from solving technical problems to shaping the systems, operating models, and organizations that solve them repeatedly.

The current work has pushed me to deepen my architecture skills, but it's also required executive communication, cross-team alignment, and mentoring people with different goals. The team has supported that growth by giving me room to own ambiguous, high-leverage problems, involving me in design and roadmap conversations, and creating opportunities to work directly with partners across Cloud & Production Engineering and the product organizations.

I've also benefited from the internal learning culture and from using AI to pressure-test designs, specs, and decisions before bringing them to a review. The biggest shift has been learning that growth isn't only about becoming better at technology. It's about becoming more effective at helping an entire system, both technical and human, make better decisions.

-

Interested in solving problems like this? Docusign's engineering team is hiring across search, storage, identity, and AI infrastructure. See open Engineering roles → opens in a new tab