Luminance
Why Luminance's CTO sees Span as observability for engineering
120 engineers
Legal AI
Cambridge, UK
After leading product and AI engineering at ClickUp, Greg Pelander recently joined Luminance as CTO. His mandate is to help evolve its Cambridge-based AI research organization into a modern SaaS engineering company.
Greg had already evaluated several developer intelligence platforms and used Span in a previous role. When he arrived at Luminance without a clear view of how engineering work was happening, choosing Span again was a no-brainer.
We spoke with Greg about understanding where engineering time really goes, investigating bottlenecks, measuring the broader impact of AI-assisted development, and why working with Span feels more like a partnership than a traditional software relationship.
From ClickUp to Luminance: building visibility at an AI research lab
You recently joined Luminance as CTO. What did you walk into, and what are you focused on changing?
Our engineering organization is about 120 people and is based mainly out of our lab in Cambridge. It is a unique organization because it is both very senior and relatively junior. We have a good number of PhD graduates from Cambridge developing the AI, alongside a lot of more junior engineers.
A large part of my mission is to help transform the organization from more of a research lab into a modern SaaS AI software company. That means bringing in some of the operating practices, systems, and visibility you need to run engineering effectively as the company grows.
The problem: no visibility into a 120-person engineering org
What visibility did you feel you were missing when you arrived?
When I came into Luminance, it was earlier in its engineering journey, and we didn't really have much tooling in place. I was digging through pull requests myself and manually building metrics to understand what was happening. I didn't have a broad view of the organization or an easy way to see where I should focus my attention.
As an engineering leader, I tend to think of developer intelligence software as the observability stack for my organization. Just as you might use New Relic, Datadog, or Grafana to answer questions about the health of your technical stack, you need a way to answer questions about the health of the engineering organization.
"I tend to think of developer intelligence software as the observability stack for my organization."
Why Span is 'observability for engineering orgs'
You describe Span as observability for an engineering organization. What does that mean in practice?
It starts with looking for smoke. Where are things not fitting the expected patterns? Where might there be a problem, or potentially an opportunity? You want a tool that surfaces those signals and then lets you drill deeper to determine what is really happening.
Span gives me the bird's-eye view of the organization. I can see whether the things I care about are trending in a positive direction and where something looks different from the norm. But the rolled-up view is only useful if you can understand what is behind it. If a signal tells me something is off, I want to drill down into the team, the metric, and ultimately the actual pull request.
That is one of the things Span really nails. It seems like there are endless levels of drilling in. Every time I want to know more, I can click and get more information. I don't only want to know that there is an anomaly — I want to understand why it doesn't match the pattern and whether there is actually a problem.
How Span bolsters cross-functional collaboration with data
One area you look at closely is where teams are spending their time. Why is that so difficult to understand?
It is amazing how often the different answers don't line up. I can ask an engineering manager what the team has been working on and get one answer. I can ask the product manager and get another. Then I can go into Span, look at the actual pull requests, and see where the work has really gone.
That doesn't necessarily mean anybody is wrong. People are looking at the work from different perspectives, and it is difficult to keep a complete picture in your head. But it is helpful to go into a conversation and say, "I know this is what we think the team has been working on, but this is what the underlying data shows."
It gives you a much stronger basis for understanding whether engineering effort is going toward the priorities you intended. It also makes conversations with engineering managers and product managers more useful because you are starting from the actual work.
Why Luminance chose Span over DX, Jellyfish, LinearB, and Multitudes
You had tried several other developer intelligence platforms. What made you choose Span, and then choose it again at Luminance?
Before Span, I had been an avid user of developer intelligence software. I started with Jellyfish when I was an engineering manager, and over the years I also tried DX, LinearB, and Multitudes.
My introduction to Span came through its founders. I was using another platform at the time, and I didn't necessarily expect to switch. I just wanted to try it. Honestly, the biggest reason I wanted to move was that Span felt like it could read my mind. It did everything I wanted from this type of software, including things I didn't yet know I wanted.
Some of the other tools I tried were essentially data lakes. They gave you a lot of numbers but not much additional value on top of them. Others hid so much of the underlying data that it was difficult to trust what I was seeing. Span gave me both. I could see the rolled-up insight, but I could also understand exactly where it came from.
I also watched how much the product improved over a relatively short period. New features kept appearing that felt like exactly what I would want from a tool like this. By the time I joined Luminance, I had already evaluated the category, used Span, and watched the product evolve. I knew it was the best tool on the market for what I needed.
How AI coding tools are changing engineering effectiveness metrics
How is AI changing the questions you need to answer about engineering effectiveness?
As we have moved toward more AI-focused development, it has been interesting to see what has changed and what hasn't. For me, many of the fundamentals are still the same. I care about output, the quality of the work, and its impact. We expect those things to improve because of AI.
What is more interesting are the unexpected side effects. It is not enough to see that developers are producing more code. What is the impact on quality? How much additional time are engineers spending reviewing that code? How often are they rejecting it? Are certain engineers or teams producing significantly more AI-written code, and is that placing a burden elsewhere in the organization?
You also want to know whether the bottlenecks have moved. Perhaps writing the code is faster, but review has become the constraint. Perhaps output is up, but rework has increased.
Span helped me begin answering those questions in my previous organization. That helped shape our AI strategy. It showed me where I wanted to apply pressure, where we needed to try a different approach, and what happened after we introduced a new tool or process.
"It's not enough to see the productivity boost. I want to understand the effect AI is having across the system: on quality, code review, and where the burden falls on the organization."
Working with Span as a partner
What has it been like working with Span as a partner?
Working with the Span team has been a joy. In some ways, it feels like working with one of my own engineering teams. I'm able to bounce ideas off them and have real conversations about what is working, what isn't, and what I would like to be able to do. They are hungry for feedback, and the relationship feels genuinely collaborative.
I also love the pace of innovation. I can have a conversation with the team about something I need and then see a feature addressing it just a few weeks later. That pace was part of what originally stood out to me about Span, and it was part of why I chose it again.
"Span to me is like a CTO's best friend. It is what observability is to an SRE team, but for me and my engineering organization."
It shows me where there is smoke, where there might be a fire, and how the organization is performing. That is the kind of visibility I wanted when I joined Luminance, and why choosing Span again was such an easy decision.
Everything you need to unlock engineering excellence