Knowledge Sharing Portal – Seth Demsey, Configure8

This is texturing TV. io. Welcome Seth.

Hey Mitch, how are you? Good even better because we're gonna talk about some developer stuff. We love love that time.

Yeah before we get into that tell us a little bit about yourself and tell us a little bit about configuring. Well sure. Yeah, my name is Seth Dempsey said I'm the co-founder and CEO of configurate and I've been writing software a long time.

It's it's been my passion ever since I can remember starting. You know, when I was young. I was lucky to be in a school that gave me a computer young and it took me to where I am today.

Yes spent a ton of time at large technology companies like Microsoft and Google and also co-founded a number of small companies myself that led me to where I am today, which is a configurate and you know, as I'm sure we'll talk a little bit more about like you if actively you know, what we're what we're up to here is trying to solve some of the problems that I had scaling larger teams building large complex Cloud native software. You know, it's interesting. So so I jump into it.

I don't mean to over stereotype any any individual job or group but developers tend to be pretty independent. They like, you know, the creative and the technical side of their job and running small teams is you know, one of the best things you can do in life. It's a lot of fun doing that at scale though is a much different environment and not saying you don't in your technical or there's a different fun to that too.

But managing bigger teams multiple teams things like that requires a different set of maybe skills for the leader but also tools, right Absolutely, it also requires different skills and mindsets for the for the individual contributing Engineers as well because it means that they are in larger code bases that have a larger history, you know, sort of more changes embedded in them, you know, maybe maybe great documentation, maybe not so you know, I think as much as you know, I romanticize about you know five person team. The good news is when you when you have a large team is is that you can just do more right like you can you can create more benefit for more people using your software and that's exciting and that added complexity that you talked about both from, you know, the leadership and management, you know perspective as well as the engineers working in that it's just the price you pay for for scaling something to be big and popular but we have to we have to figure out how to deal with it and you know to your point how do we retain the creative spark and the independence of developers? Well at the same time enabling, you know large organizations.

Yeah, I'm curious too because often times you talk about it, you know existing code base, which means you're working on. Software you didn't develop right? Maybe you don't even know well yet oftentimes.

I know there's been parts of application. Nobody wants to touch because they're afraid to break. It just understands it but there's also new things that you're creating.

It's part of the two say some more about what what are some of the things that developers have to either know think about be skilled up on that are different in a larger love your team environment. Yeah. I mean, you know one thing that you said was yeah that code base has more Legacy, right?

There's there's pieces that you understand and you know pieces that you don't there's dependencies inside of your company that you take that you either understand or you don't but I think anymore even you know, as a developer on it even medium or small team you have a lot of those same, you know issues because you're taking dependencies on third party open source libraries that you can create you're taking dependencies on, you know, SAS managed services or you know SAS hosted infrastructure that you certainly didn't write and To some extent like it's the most liberating time to be a developer because you're you're really standing on the shoulders a Giants, right? The amount of reinvention you have to do is pretty low. But at the same point in time all of this, you know, you third-party this third party that whether it's infrastructure or libraries or code or Services, it just creates this massive amount of things.

You don't understand knowledge fragmentation, right and that fundamentally whether you're you know, a team of 15 people working on on a monolith or something that's microservices or a team of a thousand people working on something that's either a monolith or micro Services that's sort of the same. So, you know, maybe there's even a contrarian that says that a small team today may have the same problems or some of the same problems that only a large team used to have Team 20 years ago. You know with example talking about his knowledge sharing right you get into larger organizations.

That ever not anyone can know everything and not everyone can know all of the pieces but you want to be able to help people know who to go to where to go to or maybe disseminate information that is going to be helpful to folks like okay. Yeah. Here's the API to talk this ticket application.

But why here's what we're doing with it or some of the challenges with using it. Okay, great. I'll go your do your stuff.

You don't need any more help for me. Yeah, yeah that knowledge map is something that is, you know, critically important right and and for a number of reasons so you could be like you said a brand new engineer coming into a company trying to figure things out you could be on a new team in a company. You could be on call having to look into something that you really don't touch much but you have a dependency on maybe directly maybe indirectly, you know, you're you're absolutely right.

It's it's that knowledge now is difficult, right? Because I think we've all you know being an organizations that have tried to do a really good job building these knowledge maps and sometimes you know, I have this this sort of metaphor I use with, you know leaders that I manage in the past which is you know, the fastest way to get promoted is to you know, hit by a bus and you're my college if your team doesn't operate just as well. If not better if you get hit by a bus, you've got a problem as a leader or you know, as you know, sometimes I think we've all run You the one person that wants to keep everything in their head and and you know be that Central resource.

I call it being a bottleneck, right? Because the one thing we know is developers is we want self-serve right? We want to be able to discover reliable information consistently and not have to you know, search through Oh, I thought somebody posted on this in slack 13 months ago.

Let's go find you know, that link will need to have it be gone or outdated that's you know, sort of almost antithetical that knowledge that knowledge Now concept you talk about in the devops world and in return back to the Phoenix project we call that brand you don't want to be brand, right? Yeah one person can shut up the environment only person it's all that kind of a problem pretty soon. Nobody can do anything because it's all depended up on a person or a group.

You don't single threaded right a single threaded exactly. Yeah, you make a good point, you know have had situations where like you're so valuable. I can't promote you.

I can't move you to another opportunity to get somebody else. Well, and yeah from there. Yeah, and it more than just promoting it.

You know, what I'm really trying to say is hey look like if you're creating these Central dependencies, you're stopping your team from being successful without you right you're stopping others from from you know, you being free-threaded, right? And we don't want that we want to enable, you know, people do self serve. Knowledge as much as we want them to be able to self serve anything else.

Yeah, that's I ever said you'd sure like to be the smartest person in the room. But if you are you're probably in trouble at least you know, you are if I'm just smartest one. Yeah, you want to hire people and have but folks that are gonna help other people not just help themselves by being smart.

We'll talk a little bit more. I'm curious. I mean, there's always questions about who do I talk to where do I go to find this?

What is it? We're supposed to be doing. What do I work on next?

What's important here? If I'm a new person on the project or we're making shifts and what's happening, you know, we've revamped the whole idea for this product or the system or whatever and kind of recasting where we go next and you want to be you want people need to know what and why what are we doing? Why are we doing it and okay.

No I have context for that. But I need other resources. What are those?

How do you solve those kind of problems? That's you know, what you said is is really sort of you know, what our thesis was when when founding configurate, which is we needed this Universal catalog of information. That you know cataloged your services and your service functions or your microservices or your etl's or you know, all the stuff that you're building but also your applications and also the infrastructure that's attached to the services and also all of the tools that you're using whether it's your, you know, Source control or your CI CD or your you know, you're you're bug monitor security runs or your test system or you're on all of these things, you know, it's that that old adage of like that cobblers children go barefoot, right?

We spend all our time as developers and and you know people building software building centralized data where houses and schemas for all of our customers, but we're still running 25 tools that don't know about each other with data that can't be queried or joined. You know, that's our daily Our Daily Grind. And and we thought well it was it was just about time for us to connect all of these things in a universal catalog, you know, whether it's the services or your infrastructure in you know, any of the clouds or I mean geez, like it's even hard to manage a cross multiple accounts.

We have a you know, one person I know has a work to the company that has like a thousand. Ews accounts inside their Enterprise and you know boy, it's it's hard to hard to get things done. So having you know, A universal Corpus what Universal place for all of this data to come in and be connected properly.

So hey, I know this service works with these environments and these Cloud resources and this rotation for on-call and these deployment pipelines and these build pipelines and you know, you can imagine these, you know, jira ticket, you know topics or components and now oh wait, it's gonna have, you know, a link to my run book or I have, you know, anything else that you need in the dependencies not just from a you know, which Cloud assets do they run on but what services are calling them? What services do they call? You know having that in one place to some extent is that living knowledge now with the word living being he because we know that they get stale when they're in a Wiki or when they're sitting in in slack, right?

And that's ultimately what we want about building because we had talked to so many people who had suffered the same sort of issues that I had at one point. I was managing it, you know north of a thousand engineer team and we had seven people whose jobs that were to go and collect information on a semi regular basis and Mitch pulling back to what you said we decided we needed to migrate this database from this to this. Well who's got databases of this type the postgres and what versions are they on and who made the migration and you didn't make the migration it was sort of an arduous Journey but to be able to pull that stuff in a central, you know.

Catalog and have it, you know sort of, you know, always up to date you would have been nice for us and then to be able to interrogate that data and ask it questions, you know joins across these tools. I would have been even even more interesting for me. So that's you know, that sort of how we got started.

So I'm curious about this too because on one extreme sort of the wiki model of everything you have to write down. And if nobody writes it down or stops writing it down, you know, you sort of lose the battery. Yeah, so the other is or take a day to like approach for developers again, here's all our daily put in one place put the query tools and the kind of structured applications on top of that.

I mean, you meet somewhere in the middle to do that by the way, I'm dog sitting today. So if you're good, it's not it's not me. Yeah, I think we have some cats over here.

But yeah. No, I think you're right. I think that the data Lake as a repository is an interesting thing.

But but we don't want to make it high friction for developers to be able to understand this knowledge. There's this, you know this concept I love Sarah and get this discovery just being able to look at things and click around and navigate through the structure of services and applic Some Cloud resources and Cloud consoles and you know dependencies in the in sort of like a good looking, you know UI that you want to use that's that's quick and has good search in it. And that's where we wound up the lake is there the API is there you want to query the the graph database and see how these things are interconnected and very interesting and unusual ways great.

But if you just want to see a service and see who's on call or file an incident or find the Run book or see the last deployment or see how many open PRS there are they're sort of sitting there for you to click on and at the same point in time. I think if you're gonna over build Every piece of technology in the developers Arsenal, I think I think that that's probably not something that's going to be successful. Just given how many tools and how much depth there is the ability to contextualize that data and have it be related to data.

That's that's you know associated with it. But also deep link into the native tool exactly where you would want to be if you knew exactly where it was is another sort of piece of the puzzle. So that goes to you know, I think overall what you're saying, which is this experience needs to be data driven and data queryable and aware.

But at the same time needs to be an enjoyable experience that is easy to use and easy to discover for developers who just want to find the information and don't want to write, you know custom queries to get there. Hmm. Yeah.

Well definitely get get the the reason why you know, if great to use UI is going to be important. It seems also that the natural old tendency working with the developer audience. So the first what the first things they're going to ask is what Integrations do you have?

What apis do you have? I want automate that stuff. Right?

Yeah have to do that. I want that to be taken care of when I do check-ins and my cicd process runs or yeah going to my my Ops tool for scheduling for whatever the uncle rotation is you talk to you do with that to get that data. That seems like a hugely important part of this because they're not going here all that information.

Yeah, I think that there's another aspect to being able to see that data which is also understanding the ownership right ownership doesn't stop at the service level like ownership is a fundamentally deeper concept that like a specific deployment pipeline or a specific build action probably needs owners rotations. Probably have owners, right? And so yeah the concept of yeah deep ownership.

To help you get to that right person with the fewest number of calls or clicks or questions asked in public forums. I think that's you know, part of what this is about as well, which is was making sure that there's Optics and you know being able to run a query to see what happens when somebody's not mailed out database anymore because they're gone. Where do we not have double coverage?

Where do we not have owners anymore? You know, it's it's you can sort of see you know, how this would come together. Yeah very much.

So make sense. Well, I'm I'm interested. I'll definitely check out your stuff.

Thanks, looking folks find out more about configurate and what you do and you have some free offers accounts or software. Yeah. Yeah.

It's you configurate that I/O is the place to go. io browser Integrations browser documentation and single click sign up get a freak out. Mm-hmm.

Go ahead and use it. Yes based in case liberal free tier and and you know, you were our goal is to make customers happy low friction easy onboarding, you know linked up your accounts your catalogy services and Great in this configure and then the number eight. Yes.

All right. Nothing here. Number eight dot IO.

Yeah. Well, great stuff that's been a pleasure talking with you with configurate would come back again. Thanks.