Building GRC

The question

What would a research environment look like if it treated people, software, and ideas as parts of the same system?

GRC grew from a practical need. Ambitious systems work takes longer than a semester and involves more than a paper: repositories, releases, machines, proposals, documentation, mentoring, collaborations, and the confidence to try a direction that might fail. Those pieces compound only when someone tends the connections between them.

The organizational bet

My bet is that a center can be rigorous without becoming impersonal, and entrepreneurial without pretending every prototype is a company. It can give people real ownership while maintaining enough shared structure that their work survives a graduation, a deadline, or a change of direction.

That means treating research operations as design work. How do we decide what to build? Who owns a component? What evidence makes a claim ready? How does a student learn to review, release, teach, and explain, not only implement? What should become shared infrastructure, and what should remain a focused experiment?

What we are building

The visible outputs are systems, papers, talks, tutorials, and open repositories. Underneath them is an operating practice: regular technical exchange, explicit ownership, public artifacts when work is ready, and a willingness to connect foundational research with tools people can actually run.

The institutional site owns the complete record. This story is deliberately narrower. It is about my part in creating the environment, the tradeoffs I keep revisiting, and the kind of builder I want the center to help people become.

Leadership as infrastructure

My role is to frame directions, build teams, find resources, create useful constraints, and remove obstacles without taking away ownership. I do not always get the balance right. Too little structure strands people; too much structure turns research into ticket processing.

The goal is independent judgment. A strong mentee should eventually disagree with my architecture for reasons I did not see, then have the evidence and communication skill to carry a better idea forward.

The entrepreneurial edge

I use “entrepreneurial” here in its oldest useful sense: noticing an unmet need, assembling people and resources, accepting uncertainty, and making something durable enough to test in the world. Sometimes that becomes software infrastructure, a new collaboration, a community, or a proposal. The measure is not performance theater. It is whether the work creates new agency for the people around it.

What I am still learning

• How to preserve speed without building around a single person’s memory.
• How to make evidence and disclosure boundaries part of everyday development.
• How to give emerging researchers consequential ownership with a safe place to fail.
• How to keep the center technically ambitious, publicly useful, and human as it grows.