TNS
VOXPOP
Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
0%
At work, but not for production apps
0%
I don’t use WebAssembly but expect to when the technology matures
0%
I have no plans to use WebAssembly
0%
No plans and I get mad whenever I see the buzzword
0%
Cloud Native Ecosystem / Observability / Operations / Software Development / Tech Culture

How to Know If You’re Building the Right Internal Tools

In this episode of The New Stack Makers, Rob Skillington of Chronosphere shared what he’s learned from building platforms and tools for his colleagues.
Dec 5th, 2023 7:16am by
Featued image for: How to Know If You’re Building the Right Internal Tools

CHICAGO — Engineers love to build cool stuff. That’s the reason they’re engineers in the first place. But how do they know if what they’re building — what they’re building in particular for users in their own organization — is something people will use?

In this episode of The New Stack Makers, Rob Skillington, co-founder and CTO of Chronosphere, shared some of his experiences, both positive and not so much, in creating tools and systems meant for his colleagues, and what he’s learned that he applies to his current company.

Too often, Skillington said, engineers think the issue of tooling boils down to a “build or buy” decision. But it’s far more nuanced than that, and it’s not even the correct question. After all, unless you’re coding your own operating system from scratch, and manufacturing your own microchips, you’re already building on top of someone else’s work.

The first question to ask, he told TNS host Heather Joslyn, is “What are the different abstractions? And once you understand the abstractions of what you’re trying to do, then you can start to understand well, where are the boundaries in which you can build and buy. And combine the build and buy into a solution that solves the whole problem.”

It’s also important to build not just for the short term, he added. “You’re not just solving for today, the short term. You’re solving for the longer term because you understand the entire landscape better.”

Thinking along these lines, Skillington said, helps innovators figure out which individual components of their proposed solution can be purchased and which need to be bespoke. And they should also consider whether they’ve given themselves a path to customize and scale their tooling further as needs change.

“If I do want to ever revisit this decision, can I do so without having to change the interface between the abstractions?” he asked. “Will the protocols still keep working?

This On the Road episode of Makers, recorded at KubeCon + Cloud Native Con North America in November, was sponsored by Chronosphere, a cloud native observability platform.

Lessons from Uber and Microsoft

Skillington pointed to an example, from his time at Uber, the ride-sharing platform. His team was building a visualization platform for the company’s engineers. Despite the work on the new platform, only about 60 engineers used it daily.

By contrast, about 1,000 engineers continued their daily use of the platform the new tooling was meant to replace.

The lesson learned: know your audience/customer base, including when the customers are your coworkers.

“We should have really understood that as a KPI going into the project, right?,” Skillington said. “Not working out at the end of it, ‘Oh, yeah. Is anyone using this?’ It’s really important to do a bit of that thinking upfront.”

Another obstacle to getting colleagues to adopt new tools can be “not invented here syndrome”: some organizations shy away from anything they didn’t build themselves.

Skilington started his career at Microsoft, whose culture had a strong case of “not invented here syndrome.” The company often improved the products it customized, he acknowledged. “But they were building things that I don’t think necessarily needed to be rebuilt, for the sake of rebuilding.”

Younger companies, like his former employer Uber, have more of a culture of moving quickly and might have less of an impulse to build their own tools, he suggested.

Where an engineering organization falls on the “not invented here” spectrum “shows up in conversations really easily,” Skillington said. “Like when you’re around a table, a set of engineers on Zoom, or some other conferencing software, just seeing where the center of gravity is when people start to propose ways to solve problems. You can kind of see if they gravitate towards the, ‘should we check out how other people do it, or should we just jump to a solution?’”

Check out the entire episode to learn more about what Skillington’s learned from building internal tools and platforms — including M3, the observability platform that started at Uber and became the basis of Chronosphere.

You can also check out his earlier appearance on TNS Makers.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.