We have a great team at Straight Path already. But there are two hires where a bit of timing, opportunity, and all the right stuff at the right moment happened. Oddly, they both came from the same place. When we added Tara we were just talking about growing and on the fence of “do we hire now, do we wait? do we really want to be known as a, what, 6(?) person company?!?!” and she became available and things led to things and we brought her on.
It Happened Again – Welcome, Richie!!!
Well we’re in the midst of some major development work with significant investment (more on Skopos in a minute) and Richie Rump recently became available just as I was entertaining some of those same type of scary and hopefully good thoughts… “Are we a software company? Do we just continue to spend on some amazing outsourcing partners and lean on one AMAZING developer, Buck, and a bit of ingenuity, AI and outside consultants?! Do we actually save and hire? What do we do?!?!” Then – a guy who I’ve known for a LONG time in the SQL Server world, and is a really great match with our culture, values, and mission and one who has literally developed the same “genre” of products and community tools we’ve been building became available. We talked. The case is closed. He just signed his offer letter.
Richie will be starting in the next few weeks (exact date to be ironed out) as a Senior Dataveloper (he asked on the title, I obliged – and it makes sense). If you’ve been around the SQL Server community for any amount of time, you know Richie already. You’ve used the Consultant Toolkit, Statistics Parser, maybe even ConstantCare or many other tools he’s built and shared for free with Brent over at Brent Ozar Unlimited. Many of you have benefited greatly from all of his contributions he’s made kind of quietly behind the scenes over there.
Richie has built tools that connect to live production environments, collect the right diagnostic data and turn it into something useful a DBA can actually act on. He built it cloud-first, made it scalable, backed it in Postgres and iterated and improved on it. He knows Postgres (ConstantCare ran on it) and he helps us on two of our most important Rocks for this year (Support PostgreSQL with DBA as a Service… And Release, and begin the lifelong journey of continuing to improve on our own flagship DBA as a Service monitoring tool that we will use to alert on our client environments, provide a daily health snapshot for each and help us better track proactive work needed for clients, find the things that other tools miss, and continue to make their environments scalable.)
Why a Dev Team for a Services Company?
I get it. It seems odd. We’re a DBA as a Service firm for 130+ clients that does professional services and health checks for SQL Server. We brought in Buck Woody to do CDO/Chief AI officer work for us and clients and he helps with Azure Architecture and analytics needs. Why a software team?
Because the main tool we use to check the health, proactive reviews, and provide alerts and health snapshots of our client should be something we can control. The data we store should be more useful to us and our clients than just “this thing just happened please respond” – We need to be able to find trends and patterns, proactively predict the next problem and help our clients most efficiently use their hours where they need it most.
We looked. We used a good third party daily health check and alerting tool for the longest time. Built by great people and it served us and our clients well – it just didn’t give us the ability to easily scale improvements, to use the data to find the things the tool isn’t programmed to find. We wanted modularity, control, and as we go through our SOC2 process, first party control of security so we can know beyond a shadow of a doubt that the data is secure. We want to be able to do monthly checks, build security checklists, compare clients against anonymous data to see where they stand show the trends over time, find the patterns that lead to problems and stop the bad thing before it happens instead of wake someone up to fix it.
So about 18 months ago we started building Skopos (the word comes from Koine Greek meaning a target/goal/watcher), our own database monitoring platform. Skopos connects through a lightweight agent, collects diagnostic data from SQL Server every couple of minutes, prioritizes alerts back to our team, and stores everything in our own serverless cloud environment. Alerts are fired off when needed, daily health check snapshots are fired off, and the metrics and data are stored in the data warehouse behind our proactive work. It’s how we will be watching our clients’ environments and how we will spot trends before they become outages, and it’s the foundation for where we’re headed next: deeper analytics, better client reporting, Postgres support, and who knows what the future will hold.
We built Skopos the hard way, on purpose. We use AI tools to help us develop – they are great speedups for testing, for boilerplate/easily repeatable steps, great for a second set of eyes and initial PR reviews. But we don’t let AI design our architecture or build our product unsupervised. When your tool holds diagnostic data from other companies’ production environments, “move fast and let the robot write it” is not a security posture I want to have. Which is also why we’re in the middle of our SOC 2 audit right now – our investment in doing this the right way, because our clients trust us with a lot, and that trust is our whole business.
So that’s why we need a dev team. It’s why we already had one. It’s why adding a Senior Dataveloper on our payroll instead of outside per hour is the right decision, and probably a better financial investment long term. Richie will work alongside our own David Seis, a dataveloper himself who started with us on our support team, grew into a dev role, and now gets a senior architect to grow alongside and geek out with (they’re not too far from each other – and they don’t just love data and development – they’re going to bond pretty hard over Star Wars interest also – I don’t know who knows more – I guess we’ll find out at our annual on-site this fall in Boston. (We’re remote – so we’re all going “on-site” – I know most of you call it an off-site)
Richie Comes to a Solid Foundation
The work we’ve done to date is solid. We’ve had a great dev partner made up of a friend I’ve known and trusted for almost 15 years when we partnered with Bossie Hurley to help us build this product. Craig, Josh, and their team have been instrumental in this work. Evan, Buck, Jeff, our full team here have been key to our success to date as far as architecture and Buck asking the questions I never asked at the start and should have (some of the same questions Richie asked me in our phone screen – that’s a good sign I hope), Evan helping us keep the plane flying and progress as we go. Jeff continuing to give feedback and make awesome community tools. And we would not have a data warehouse, a proactive footprint with our proactive dashboard in PowerBI and the discipline of dev and best practices if it weren’t for David Seis on our team. Also Martin Schoombee, a PowerBI and warehousing partner at 28 twelve consulting has helped us build that initial warehouse and dashboard and help our NPS rise from a pretty good 88% to an impressive 93.5% this year has been key to us realizing we had to go down this path.
Richie joins a dev team in progress. He is going to work with David a lot on taking over and moving forward with the next releases of Skopos. We are GA and solo on Skopos for 18 clients, with more and more moving to it over the next several weeks. Jeff Iannucci will work with the dev team more and more on helping to think of what’s next, to tie our community SP_Check tools into more checks and more support for our clients. I think we’re going to have a lot of fun.
What This Means If You Work With Us (Or Want To)
For our clients: better tooling, faster answers, and more of the proactive “we saw this coming before it hit you” moments that our team lives for and you keep noticing on our annual surveys. The whole point of owning our platform is serving you better with it based on your feedback each year and each monthly check-in call. THANK YOU.
For the community: our free tools stay free, they get more attention, and there’s more coming. No promises yet other than we love the data community, the SQL Server community, we can’t wait to get to meet the Postgres community and we want to give back where we can – even if the only goal is “giving back.” It’s a small world.
And if you’re a company running SQL Server (or soon, Postgres) without anyone truly watching over it – that’s exactly what we do, every day, with a team that now includes one more really awesome human being. Reach out and we’ll take a look at your environment together and see if we are a fit.
Welcome aboard, Richie. Let’s build.