Peter Bogart-Johnson on Product Management, Poetry and Listening

Ron Minsky introduces Peter Bogart-Johnson, a Jane Street program manager who has worked across many projects and teams. Before discussing that role, he asks how Peter arrived in technology from a less conventional background.

Bogart-Johnson studied theater and English literature, then pursued graduate study in creative writing and poetry in New York. While studying in the evenings, he worked for nonprofits serving low-income families, doing advocacy, fundraising and program development. He also edited the literary journal Lit.

A fellow editor who worked at D. E. Shaw introduced him to the firm. Bogart-Johnson joined D. E. Shaw Research, which develops supercomputers for biomolecular simulation, alongside other writers, musicians and artists in work initially adjacent to the deepest technical work.

Minsky asks whether the firm deliberately hired poets for project organization. Bogart-Johnson says it sought talented, creative people for roles that were not strictly technical. The idea was that they could bring comfort with abstract and holistic thinking, even if they eventually left for creative careers.

The approach worked well in his experience. Engineers could concentrate on technical problems while colleagues focused on operations, project management and other surrounding work. Several people who started in those roles, including him, came to enjoy the field and stayed.

Minsky asks whether the value came from skills learned in creative work or simply from having a different perspective. Bogart-Johnson thinks both matter. A poem and a project can have constraints, an audience and a beginning, middle and end; both involve people trying to make something.

The outsider’s lens can help a team see its work differently. Yet the longer a PM stays, the more language and context they naturally learn. Bogart-Johnson tries to retain some separation between perspectives while still gaining the knowledge necessary to work effectively.

He still writes poetry, tries to write every day and participates in New York’s writing communities. He has run readings, edited a journal and exchanged work with other writers. His interests include the New York School and institutions such as the Poetry Project at St. Mark’s Church.

Minsky explains that for much of its history Jane Street operated without a distinct PM discipline. When the company had roughly 30 or 40 people, engineers could sit beside users and think about software end to end without a separate coordination role.

As the firm grew beyond 2,000 people, projects crossed more teams and users. Coordinating priorities and understanding needs became harder. A language feature, for example, might also require editor integration, library changes and refactoring tools; a missed dependency could delay delivery.

Larger efforts crossed developer tools, server management and trading software. Jane Street began treating organizational work as a discipline in its own right, but bringing in PMs also meant asking both the organization and the new hires to learn how to work together.

Bogart-Johnson joined during this early phase after a former colleague came to Jane Street and his startup approached an acquisition. The chance to help establish a new practice appealed to him. His first conversations with the firm took place during the pandemic in 2020.

His first team was networking, several layers removed from the firm’s trading activity but fundamental to it. Two data centers were being built while a large research compute cluster needed to move between them. The work involved many teams and moving parts.

The immediate need was someone to bring the work together, clarify requirements and ensure participants shared an end state. The longer-term goal was to make future projects sustainable. At the same time, he had to learn Jane Street while the team learned how to work with a PM.

One early gap was a single place to track complex work. Project information had been spread across spreadsheets, PM tools, email and chat. Establishing one point of entry reduced the context switching needed to understand the project and its dependencies.

Minsky asks how a newcomer can understand existing workflows well enough to improve them and persuade people to change. Those workflows may have grown reactively, but they also reflect real needs and relationships. Bogart-Johnson says building trust takes time and starts with meeting the team where it is.

A PM could arrive and mandate a complete agile framework, sprints and story points without understanding the team. Instead, he suggests borrowing only the practices that help. A small initial version of a product, placed in users’ hands for feedback, may be more valuable than a large bureaucratic process.

Incremental changes show their value over time and build trust. Minsky prefers learning from narratives and approaches rather than adopting a methodology wholesale. Bogart-Johnson calls the work anthropological: learn the team’s behavior, practices and relationships before trying to reshape them.

Understanding those details takes months and continues as people join or leave. Even small changes can affect a team’s culture over time. For Bogart-Johnson, paying attention to that evolution is part of the pleasure of the work.

Starting remotely made that learning harder. From his dining room in Brooklyn he interacted with a relatively small set of colleagues and tried to understand a much larger global organization through video calls. For his first nine or ten months, he could not easily perceive the firm’s broader culture.

On his first visit to the office in 2021, he saw unfamiliar colleagues from other parts of the firm and could again have spontaneous conversations over lunch or at a desk. People welcomed him, giving him a more tangible experience of a culture he had previously heard about.

Minsky says those incidental encounters reveal colleagues’ default willingness to help. Bogart-Johnson agrees and notes that PM work is relationship-driven: being able to walk over, discuss a problem and understand it together was something remote onboarding had limited.

The two turn to tools for remote and hybrid work. Early in the pandemic Jane Street used conventional video conferencing alongside a low-latency audio tool originally designed for gaming. Each served a purpose, but people using the different systems still needed to communicate.

The firm built a bridge: users could combine low-latency audio with video from the conferencing system, muting the latter’s audio. Calendar integration made the setup easier, and people could switch between tools when a different form of communication suited the conversation.

Returning to the office did not make these tools obsolete. Minsky notes that remote work had also improved communication across offices in New York, London and Hong Kong. The aim was to retain those gains while supporting people working from different locations.

The team developed lighter, more mobile versions, hired an external developer for an iOS app and equipped desks with devices, microphones and cameras. Developers and users could sit together, discuss the emerging solution and refine it as it reached more people.

Minsky observes that this resembled a consumer product more than Jane Street’s traditional internal trading software: hundreds or more than a thousand people might use it. The organization had to learn how to gather feedback and build for that broader user base.

A deadline helped. With a large group about to return to the office, the team needed a minimum viable version. It chose performance over a fully polished design initially, accepting a less-than-final experience in order to give people something usable.

Before launch, the team tested with people from technology, trading and other parts of the firm. It could not interview everyone regularly, so it sought representative users who understood the needs of their groups. The team kept iterating for a year and a half and beyond.

Supporting different devices also required trade-offs. Bogart-Johnson describes releasing an Android version that was not yet as good as the team wanted but was usable, then improving it. That scrappy approach helped deliver value while learning from actual use.

Minsky appreciates the ability to operate in two modes: careful, reliable improvement of existing systems and fast action during an emergency or opportunity. A pandemic, flood or new market opportunity can require the organization to shift priorities and accept different compromises.

Bogart-Johnson says Jane Street often relies on consensus and discussion, which can take time, yet can also gather around an urgent problem and move quickly. In his experience, retaining both capacities at the firm’s size is unusual.

He sees cultural preservation as deliberate and gradual. New practices are considered from multiple angles. One example is the PM role itself: initially he sometimes felt like an outside resource for an engineering team rather than a full member of it.

Over three years, multidisciplinary teams increasingly included engineers, PMs and sometimes designers. The communication-tools project combined internal developers, an external firm, PM work and release notes. Each contribution affected the final experience and adoption.

Minsky says some engineers feared PMs would import unhelpful practices from other organizations or stand between developers and users. Jane Street valued engineers’ direct connection to users and their responsibility to understand problems end to end.

Bogart-Johnson agrees that a PM should not add layers between a builder and the product or its users. The goal is to improve focus and give the team more insight into users, using a lightweight process that remains useful even if the PM steps away.

Minsky adds that developers also need to understand the PM’s contribution: identifying what to build, organizing work and helping a group deliver. Bogart-Johnson says the relationship ultimately depends on mutual respect and learning how to work together.

One challenge comes from a positive impulse: people want to say yes and help colleagues. As requests multiply, that willingness can erode focus. When a major emergency arrives, a team that has twenty active efforts may struggle to recover them all afterward.

It is acceptable to tell a colleague that help can come in two weeks or a month if the delay is manageable. That protects time for what is important now. Bogart-Johnson says the firm is improving at making such choices, though it still has work to do.

Minsky calls overcommitment a scheduling problem. Assigning people to many projects can reduce anxiety about requests while producing little progress on any one of them. Users receive value only when something works and reaches them.

He has seen teams improve delivery by having three people focus together on one or two projects instead of each working on six. Being nice is a good baseline, he says, but it is not a plan: an organization must compare options and choose where to spend effort.

When hiring PMs, Bogart-Johnson places particular weight on empathy and willingness to meet a team where it is. Experience and domain knowledge help, but listening, observing a process and becoming a constructive agent of change matter more than imposing a solution.

Basic skills still matter: a candidate should be able to break down work, make it visible, track progress and risk, focus on delivery, learn from projects and collaborate with people whose skills differ. The interview also needs to explore less tangible qualities.

Interviewers present a problem and watch how a candidate investigates it and learns how the team wants to work, not just whether they produce an answer. Minsky compares this with engineering interviews that simulate collaboration rather than merely testing a memorized algorithm.

Both look for how well candidates listen, explain, recognize uncertainty and update when new information changes the problem. Someone who keeps pursuing the same answer after the situation changes may have missed a chance to listen and adapt.

Bogart-Johnson sees writing as both communication and a way of thinking. Summarizing a problem helps a PM refine the narrative, scope a project and discover how to solve it. Good writing is not just a report produced after the thinking is complete.

Minsky asks how much technical background a PM needs. For developer tools, he finds direct experience useful for understanding users. Bogart-Johnson says careful onboarding and opportunities to learn can help PMs build context regardless of where they started.

Jane Street’s OCaml boot camp is open to non-engineers as well. Bogart-Johnson completed a self-guided version, which helped him understand engineers’ workflows and release cycles even though he does not code every day. Empathy and a willingness to learn remain essential, he argues, including for technical candidates.

The conversation returns to technical debt. Minsky describes the pressure of an endless request queue: if teams never improve the platform or retire debt, friction grows and future delivery slows. A PM can help make space for that work without losing sight of users’ needs.

Bogart-Johnson’s storage team periodically holds a two-week toil-reduction sprint, roughly every six months. Engineers curate recurring operational tasks and build small automations so they can spend more time on clusters, tooling and other substantive work.

Some important tools used across the firm grew from these efforts. They also build camaraderie: teammates can remove a frustration they encounter daily. A PM can notice an appropriate gap between projects and help the group reserve time for the work.

Minsky resists framing this solely as taking care of the team instead of serving customers. Enjoyable work matters, but reducing manual effort also improves the team’s capacity to deliver for the rest of the organization. The engineers’ time is itself a valuable resource.

Bogart-Johnson agrees and stresses curation. Rather than clearing twenty unrelated small annoyances, a team may achieve more by identifying recurring themes and addressing two or three deeper problems that benefit both its own work and its users.

Minsky introduces a recent GPU infrastructure expansion. Jane Street’s research had shifted toward deep neural networks, requiring more training and execution capacity, on-premises hardware, cloud resources, networking and storage capable of feeding data to GPUs.

From Bogart-Johnson’s core-services perspective, the first sign was that someone was buying more GPUs and needed data-center space. The team quickly had to move beyond reacting to individual requests and understand the larger goal those purchases served.

Conversations among research, core services and other teams mapped choices about on-premises versus cloud resources, scheduling and networking hardware. Bogart-Johnson says PMs can bring the relevant people into those decisions rather than merely receiving orders after choices have been made.

That turns the interaction into a partnership. Teams can understand the timeline, scope and purpose of their work, and identify other commitments they must defer. Clarity about why an urgent project matters also affects morale.

Minsky values getting requesters to explain what they are trying to accomplish, not just the precise item or feature they think they need. A requested solution may have a long lead time or may not actually address the underlying problem; shared context lets others propose alternatives.

Bogart-Johnson suggests testing a smaller version before purchasing a large, specialized system. For storage, a team might try existing storage with a smaller networked GPU setup to learn what the workload needs before committing to a powerful new cluster.

Minsky frames this as optimizing for the rate of learning, not merely a predetermined end state. Hardware and machine-learning models were changing quickly, so infrastructure had to be built, tested and revised as teams learned what they needed.

That approach also meant accepting mistakes. Foundation teams such as networking take pride in reliable systems, but producing a fully hardened solution takes time. An uncertain and urgent effort requires explicit bets and permission to try things that may not yet be production-ready.

Bogart-Johnson says a failed experiment should not automatically mean a team must drop everything as though a stable service had failed. People need shared expectations and trust to remain comfortable with some uncertainty while they learn together.

Concretely, a PM can bring people with different concerns into the same room: a networking engineer may care about a stable design, while a researcher cares about models that can run on GPUs. The group needs a shared end state and an understanding of how its decisions affect one another.

The PM’s role is to sustain that shared framework, surface assumptions and help people remember that they are working toward the same outcome. Bogart-Johnson says having someone who cares deeply about that coordination is valuable.