I’ve spent a good 18 years building software and I’m so grateful to have found something that matches both my interests and skills. To even say that aloud is wild! And although a ton of things have changed there have been an equal amount of things that have stayed the same; some things more welcome than others!
Among the more welcome (and exciting) things that have changed are the introduction of new and more powerful languages, technologies, and platforms that are enabling more people to build solutions faster than ever before.
The tools have also gotten better and the rise of “frameworks” and discrete methodologies have allowed the conversion of ideas into real software to become even more resource efficient. For instance, these things have allowed me to dip my toe into the “indie” software development world deeply and I’ve been fortunate to have some of those projects do quite well!
But even with the growth and emergence of all of these newer and more powerful tools it is still just as hard as it ever has been to build a thriving business through software. In other words, although we can build all the software that we’d ever want and hope and dream for, our ability to transform those products into money-making companies is still very much of a challenge.
You see, what I’ve come to realize is something quite profound: There is an ever-widening gap between “good” (or mediocre) software and “great” software, where the latter are the types of software that customers will use and enjoy and who will express their appreciation through purchase (and continued financial support through monthly & yearly subscriptions).
One part of the “gap” is the connection between engineering productivity and verifiable business metrics. I’ve seen this in large enterprise companies as well as the young, early-stage startup, as both a leader and as an engineer / individual contributor.
In both cases (and from all sides), everyone simply wants to know whether the engineering work being done is actually moving the ball forward; if the amount of productivity was helping the business simply make more money.
This is especially poignant for the engineer since I always wanted my work to “count” and to make a difference. It just wasn’t enough that I built such-and-such technology or contributed to such-and-such product: I wanted to know that I was really helping the company build financial velocity and momentum. There’s nothing more depressing than not knowing if my work was really making an impact (and not having great engineering work noticed or accounted for).
And, on the flip-side, as I grew from individual contributor to technical manager and then senior leader I wanted to know how to best manage and support my technical and engineering teams and individuals.
To be honest, as I take a moment to reflect on my previous roles as manager I have to admit that a lot of my management decisions were based on “hunches” or educated guesses around productivity and not on concrete facts or real intelligence.
So I’ve begun investigating and hacking on some ideas that might be able to fill the gap(s) of information, that may fill the void of engineering intelligence, and enable individuals, teams, and organizations build better software.
And that matters, a lot. If better, more powerful infrastructural tools can be created that help developers, software teams, and organizations as a whole know, with certainty, the relationship between engineering work and business metrics, then everyone wins.
The result(s)? Companies will build better software. Engineers will know that their work matters and be motivated and incentivized better and build better software. And customers will encounter and purchase better software (and stick around longer).
So, that’s the mission: Build Better Software.
I’m calling this project “Pinpoint” for now but I imagine this will change as I get more feedback and as the project and product gets more fleshed-out.
Oh, and “Hello World”.
Also published on Medium.