Async Documentation Alone Will Not Save Distributed Teams | Vincent Chu, VP of Engineering, Visier Inc.
On this week’s Dialog, I spoke with Vincent Chu, VP of Engineering at Visier Inc., a workforce analytics platform used by HR and finance teams, where he leads a ~90-person engineering organization across platform, product, and SRE.
Before Visier, Vincent was Chief Product Development Officer at AgencyAnalytics and Head of Engineering at Later.com through its 2022 acquisition by Mavrck. Earlier, he spent four years at Apple on the iWork suite and got his start at Electronic Arts (EA) on FIFA.
Vincent Chu also writes about engineering leadership and team culture on his personal site, where he shares practical reflections from his experience.
Takeaways
Async collaboration across time zones breaks down not because of bad documentation, but because you lose the informal signals that tell you who is stuck, overwhelmed, or quietly disengaging.
Distributed teams stop functioning when a site is just an execution arm for headquarters. They start functioning when each site owns a problem space end-to-end and can ship without constant cross-timezone coordination.
AI tools spike output, but velocity without comprehension is a liability. The bottleneck shifts from writing code to reviewing it, and engineers end up shipping systems they no longer fully understand.
Engineering leaders who stop writing code lose calibration. Without firsthand experience of the tools, opinions get formed on secondhand summaries, and the gap between what people say is possible and what’s actually practical becomes invisible.
Yassine: You have expertise in leading Engineering and Product teams across multiple time zones. What took you the longest to figure out about making that actually work? What assumptions from your earlier years in leadership didn’t hold?
Vincent: What took me the longest to figure out was that async by itself is not the answer.
Earlier in my career, I genuinely believed that if we wrote everything down, kept a clean repo, recorded meetings, and were disciplined about documentation, cross-time-zone collaboration would mostly take care of itself. I thought the problem was operational. It turned out to be structural and human.
The first thing that broke that assumption was trust and visibility. When you do not have prior working history with someone, especially more junior team members, you lose all the informal signal. You cannot tell who is stuck, who is overwhelmed, or who is quietly disengaging. Documentation does not fix that. You have to intentionally design clarity around ownership, expectations, and what “great” looks like.
The second assumption that did not hold was around time zones themselves. Most people will say they are fine working in the center of gravity time zone. I would have said that too. But if someone is waking up at 5am or staying online until 1am five days a week, that is not sustainable. It looks fine for a quarter. Then it shows up in energy, decision quality, and retention.
What actually works is not heroics or better note taking. It is structure:
Each site needs a real mission.
Clear delegation.
Independent release cycles.
End-to-end ownership.
If a location is just an execution arm for another office, the friction compounds. If that location owns a problem space and can ship independently, the time difference becomes manageable.
The real shift for me was stopping the question of how to collaborate better across time zones and starting to ask how to design the organization so it does not require constant cross-time-zone coordination to function. That mindset change made everything else simpler.
Yassine: During your tenure as VPE at Later, you rebuilt the career framework and scorecard definitions for engineering to provide “fair and transparent progression.” What prompted the rebuild, and what design choices made the new system work?
Vincent: I would not frame it as walking into something that was broken and trying to fix it. It was more that the system was incomplete, and the team had clearly outgrown it.
There was strong ambition across the engineering org. People wanted to grow, to understand what good looked like, and to know how to get to the next level. What we had at the time was directionally right, but it was not fully fleshed out. Different managers were interpreting expectations slightly differently. That creates noise, even if everyone has good intentions.
At Later, transparency and fairness were core cultural values. So the question became, if we actually believe that, what does it look like in practice? For us, that meant building a clear job matrix with explicit expectations at each level. Not just technical depth, but scope, ownership, cross-functional impact, and leadership behaviors. It gave managers and team members a shared reference point instead of relying on informal calibration.
One common fear leaders have is that once you make everything explicit, people will treat the matrix like a checklist. They will point to each bullet and say they qualify for a promotion, regardless of business context or financial constraints. In my experience, that is manageable.
The key design decision was separating job level from title. Level reflects scope and impact. Title is more about external signaling and organizational design. By decoupling the two, we could have honest conversations about readiness and progression without every discussion automatically translating into a title change or comp event.
What changed after that was the quality of the conversation. Instead of debating whether someone was “good enough,” we were discussing evidence of impact relative to a clear standard. That shift alone made progression feel much more fair and much less political.
Yassine: Engineering leaders have been pressured to accelerate AI adoption in their orgs and products over the past 2 years. You describe yourself as “pragmatic with software development processes” and say you “thrive in organized chaos.” How have you been navigating the pressure to adopt AI at Visier? What are some pragmatic decisions you’ve made amidst that chaos?
Vincent: These days every conversation has some version of “what’s your AI strategy?” I think the mistake would be to swing too far in either direction, either blocking everything or chasing every shiny tool.
The way I have navigated it is pragmatic and structured.
First, we encourage experimentation, but with guardrails. Security, IP protection, and data handling are not optional. Teams are free to try different tools, but within a clear boundary. That gives people room to explore without putting the company at risk.
Second, we accept that the tools are evolving faster than any policy. A guideline that was perfect one quarter can be outdated six months later. So instead of trying to lock down a permanent standard, we revisit guidance regularly. The goal is not to standardize forever. It is to create clarity for now and be willing to update it.
Visier has been supportive financially, which helps. If you want teams to adopt responsibly, you cannot force them onto free or crippled tiers and expect magic. We invest where we believe there is leverage.
Where I have been particularly cautious is around long term ROI. AI can absolutely increase output. It can also create a maintainability problem if people are merging code they do not fully understand. We talk a lot about whether our developers still understand the systems they are shipping. Velocity without comprehension is a liability.
There are also very practical side effects. PR volume can explode. Review time can explode. If you do not adjust expectations and review practices, you just shift the bottleneck from writing code to reviewing code. We made that explicit early so managers were not surprised by the second order effects.
Organizationally, we have a central owner coordinating at a high level, but execution is pushed down. Each manager is accountable for how their team uses these tools and whether they are actually becoming more effective. Part of my role has been educating people managers on the tradeoffs of different tools so they can make informed decisions, not just mandate adoption.
It really is organized chaos. The key is not to eliminate the chaos, but to put enough structure around it that experimentation compounds instead of fragmenting.
Yassine: You’re a tinkerer, and you’ve kept your GitHub green across your leadership career. Most executives end up operating at pure abstraction like OKRs, roadmaps, org charts. What does staying in the code prevent you from losing?
Vincent: I do operate at the abstraction layer most of the time. OKRs, roadmaps, org design, people management. That is the job. But staying in the code prevents me from drifting too far away from reality.
The first thing it protects is technical intuition. Especially right now with AI accelerating development. If you are not actually using the tools, building small things, experimenting with agents, copilots, MCP servers, whatever the latest wave is, you end up forming opinions based on secondhand summaries. The delta between what people say is possible and what is actually practical is huge. Writing code keeps my judgment calibrated.
It also directly informs product strategy. When I experiment on nights or weekends, I am not just tinkering for fun. I am pressure testing ideas. I get a feel for what feels magical versus what feels brittle. That helps me recommend what we should build, where we should invest, and what is hype versus leverage.
The other thing it prevents me from losing is credibility. Not in a performative way, but in a grounded way. The teams I lead know I used to code heavily. But in this AI era, everyone is a beginner again. The tools are changing fast. If I am not learning alongside them, I slowly become the person who talks about transformation without understanding the friction on the ground.
Staying close to the code reminds me how hard the work actually is. It keeps me honest about tradeoffs. It keeps my empathy sharp. And it makes sure that when I talk about velocity, architecture, or adopting a new paradigm, it comes from lived experience, not abstraction.
📚 Vincent Chu’s Go-To Resources:
1 podcast I make time for:
A newsletter I rarely skip:
A book that shaped my thinking:
Thank you Vincent for your time and insights!
This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.
If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.
Yassine.