The Management Philosophy Limiting Your Engineering Output | Allen Cheung, Former SVP of Engineering, ujet.cx
This week’s Dialog guest is Allen Cheung, former Senior Vice President of Engineering at ujet.cx, a cloud-based customer experience platform.
Allen ran engineering at UJET, leading a 300-person org spread across four continents through the company’s push into AI-enabled customer service. Before that, he served as VP of Engineering at Kiddom, where he managed the company’s largest team and rebuilt the platform to handle five times the user load it was carrying when he arrived.
He’s also held senior engineering roles at Affirm and Mystery.org. Allen writes regularly on engineering management at allenc.com, where much of the thinking behind this conversation first appeared.
Takeaways
Productive environments shouldn’t be a perk for top engineers. They need to exist so the average engineer gets it right the first time without having to jump through hoops.
AI adoption gives managers cover to invest in CI/CD, tests, and review discipline, because coding agents only deliver when those systems are actually in place.
Hiring for complementary skill sets only works if the existing team has the self-awareness to value different work styles, otherwise differences get rejected instead of integrated.
High team satisfaction paired with mediocre business results is a warning sign. A leader’s job is to make the team productive, not happy.
Yassine: You’ve said your goal is to “build great teams by creating productive environments so it’s easy for normal folks to do great work.” What does that look like in practice? How do you actually build those environments?
Allen: Great environments are really just about encouraging wanted behaviors, through the path of least resistance. Whereas you can sorta rely on your best people to jump through hoops to build the right things, the point of productive environments is to make it easy for the average engineer to get it right the first time.
I remember a blog post from 25+ years ago from Joel Spolsky, who wrote about building great teams and products in the era of desktop applications, on his Joel Test. It was this 12-part checklist that highlighted the things that made for a productive environment, informed by the experience he had at Microsoft plus his own startup (Fogbugz and eventually Stack Overflow). Many are still surprisingly relevant today.
As managers, the challenge is to carve out the resources to invest in these systems: CI/CD, testing suites, PR review best practices, etc., all while continuing to deliver products and features. Fortunately, one major factor that goes in our favor right now is AI adoption. Every CEO now understands that coding agents are a productivity accelerant, so companies are racing to get AI tooling to their engineers and are encouraging usage. And it just so happens that coding agents work best when you also integrate them into great environments, where they can run builds and tests and their code is properly reviewed. Take advantage of this alignment!
Yassine: You’ve written about hiring for complementary skillsets rather than chasing “A players” who match the people already on the team. What helps you evaluate whether someone will actually complement the existing group, versus just being different?
Allen: To be clear, being different itself is not a bad thing! If the goal is to have a team that doesn’t have wholly overlapping skills/personalities/domain knowledge, then a necessary prerequisite is to have different folks on the team across some of these dimensions.
But you’re right in pointing out that difference is necessary, but probably not sufficient by itself. One of the ways that I’ve tried to solve this is to get as many of the current team to interview potential new team members as possible. What I’m looking for are emergent collaborative dynamics, bouncing ideas off of one another, building solutions that leverage each person’s domain expertise or individual strengths, etc. I sometimes have to remind interviewers that they’re not there just to evaluate knowledge, but to simulate what a working relationship would feel like.
This strategy works reasonably well for complementary functions or skillsets, but it’s a bit harder to suss out personality and working style differences and whether they’d work in practice, particularly in the context of an interview. I’ve found that teams that have a degree of self-awareness and humility are better able to integrate new members and give it an actual chance to work; if the existing team members acknowledge and appreciate a breadth of work styles, then there’s a better chance of the arrangement becoming actually complementary over time.
Yassine: You’ve written about the limits of servant leadership, that engineering managers who define their role solely around supporting their team can miss other critical qualities like decision-making and consistent output. How did your own understanding of that balance evolve? Was there a point where you realized the “servant” framing wasn’t capturing the full picture?
Allen: For me, it was receiving some tough managerial feedback about my teams’ effectiveness. Essentially, I had a series of performance reviews where my teams gave me very high marks as their manager. I was following all the best practices that I could find on what it meant to support my teams. But the business results were mediocre, which spoke to a real gap between perceived and actual excellence. Another manager of mine framed it like this: your job isn’t to make your team happy; it’s to make them productive.
And honestly, embedded within the “servant” framing and ethos is a level of idealism that, unfortunately, I’ve grown more cynical of over time. Yes, it would be great if everyone in your organization just needed some nurturing and support to do amazing work, but that doesn’t square with reality. Some do just need some managerial support and basic blocking and tackling, but others require much more investment across your entire team to get them on the right track, and few of us have the luxury to give them that level of support. And some,I speak from experience, will take full advantage of your supporting nature and offer up a litany of excuses.
Maybe an alternative way to think about servant leadership is to expand what it means to support your team. Sometimes that support comes in the form of holding strict accountability and providing tough feedback.
Yassine: For leaders who naturally default to support mode, what’s helped you develop those other muscles? The decisiveness, the willingness to be directive when it matters?
Allen: I always think it’s important to stay true to yourself, especially when you’re trying something unfamiliar or against your natural instincts. You have to evolve your management principles to allow for something that’ll come off as less supportive, more directive, otherwise you won’t really believe in what you’re doing and burn out.
For instance, I strongly believe that everyone has amazing potential, and given the time and motivation each one of us can accomplish amazing things. The challenge is that none of us have infinite time and energy, and it’s fundamentally unfair to the rest of the team if I spend the bulk of my efforts on 1 or 2 people and underinvest in others’ potential. For me then, the real constraints of finite resources and business realities means that I can’t operate in pure support mode; I’m forced to make tough decisions and have difficult conversations. At the same time, because I believe in people reaching their potential, I offer to keep in contact and chat regularly with folks after we no longer work together, and some do take me up on that arrangement.
Yassine: You’ve written about the “feedback void,” how leaders can become isolated from critical perspectives as their conviction hardens. Your advice is to intentionally hire people who think differently, and work hard to listen to them. What does “work hard to listen” actually look like for you? Is there a rhythm or habit that helps you stay connected to perspectives that might otherwise not reach you?
Allen: You know how sometimes, when you’re talking with a non-technical person about a technical subject and they’re describing something that you suspect is wildly misinformed, and there’s just this instinct building up where you just want to interrupt them and tell them how wrong they are?
Working hard to listen means suppressing that reflex.
But really, for me it’s about giving space for others to articulate their perspectives. I heard on a podcast recently that one of (CEO of Apple) Tim Cook’s tactics when he runs a meeting is to not say anything in the first 10 minutes, to not even react, so that his team has a little bit of space in the beginning to give honest assessments. My version of that is to try to take feedback or suggestions, and instead of reacting in the moment (which ends up being defensive 9 times out of 10) I nod and tell them I’ll sleep on it. A lot of times, I’ll be writing notes as they’re talking so I force myself to give them space to say the whole thing, and then I’ll review those notes at the end of the week as a way to reflect on the perspective.
Another technique I use is to paraphrase what they said back, both to ensure that I really understand the feedback, and to signal to the other person that I’m taking them seriously. With enough iterations and repetitions, I’m usually able to get folks to open up a bit, and feel like they can be a little bit more honest with me than before.
Oh, one last thing: I also remind folks that while I can and do listen to them, I cannot promise to act on every single piece of feedback. With larger teams (or many different functions), there’ll be a lot of back-and-forth, and suggestions that will end up being mutually incompatible. Or sometimes, an individual’s pet peeve just isn’t all that important in the grand scheme of things. So I always try to draw a line between hearing them out, and invoking major changes based on their commentary.
📚 Allen Cheung’s Go-To Resources:
3 people I follow and recommend:
Matt Levine, author of the Money Stuff newsletter, pointing out the absurdity of finance
Will Larson, who has written multiple books on eng. management with lots of tactical advice
Noah Smith, who opines on economics, geopolitics, and technology
1 podcast I make time for:
Greatest of All Talk, a basketball-focused podcast that has figured out what makes the podcast medium unique (e.g., personalities, takes, irreverent humor)
A newsletter I rarely skip:
Ben Thompson’s Stratechery, for a tech+business lens into our industry that’s also away from SF/NYC
A book that shaped my thinking:
Ask Iwata, a biography of Satoru Iwata, the former President of Nintendo; he was universally beloved and the book gets into some of that, but there’s also a surprising amount of great management advice and mental frameworks presented as well
Thank you Allen 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.