New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Developer Communities With METT-TC, Orbital Model, and Bridge Building | Patrick Skinner - ar.io

Ethereum DenverThu, Oct 9, 2025, 12:00 AM

The tactical approach to building developer communities. Former US Army Ranger takes his experience from the military and makes it his mission to deign a clear system for building developer communities using systems the three systems: METT-TC, Orbital Modal, and Bridge Building. 🚀 Get Ready for ETHDenver 2025! 🚀 We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2025—it’s going to be epic! 🌟

Transcript

hi welcome back to our very last performance today I would have I have the pleasure of introducing Patrick from R weave with our last presentation so please take it away see hey everyone my name is Patrick Skinner and uh I am a senior developer relationship engineer uh for the RO ecosystem I I work for uh PDS who runs uh the Aro as well as the r Drive uh Tech behind R weave and today I'm going to be talking about uh something called met TC uh for Devils which basically is a Army Ranger Special Operations uh methodology for prep uh prep preparation and uh for basically any type of mission possible it could be uh combat missions or even like humanitarian missions and I've taken this principle and I have uh basically implemented it specifically for devels and it seems kind of like a stretch but as you go through and you learn a little bit about MTC you'll actually see why it applies uh so well my favorite quot quote in the world is always uh if you find yourself in a fair fight you didn't plan accordingly and that's something that's always been near and dear to my heart because every single time uh I've ever planned plan for anything I've never felt like there's ever been any type of like over planning you've never told yourself that you over planned for something and and because you over planned something went wrong that almost never happens it's best to over plan and always have success then to under plan and risk the probability of having some sort of failure either during or uh during the event or for the entire event itself so a little bit about my background I'm a former Army Ranger medic uh a paratrooper medic and I was a mass casy coordinator I've got several uh deployments uh I was actually the mass Cas coordinator for the earthquake in Haiti so I mean it it's interesting how much planning goes into not just the combat side of things of the military but also the humanitarian side of things and I'll tell you that in the military we spend especially in the Rangers we spend so much much time planning for something that could only take maybe 20 or 30 minutes you know a single Mission depending on the situation could be a couple hours could be 20 to 30 minutes could be a couple days it just depends on uh what the mission is and I came into the web 3 space and started working as a Devo and real it just it really astonished me how much there was a lack of planning for for online events uh lack of planning for IRL events uh lack of planning for execution of pretty much anything either by the engineering team or by the developer relations team or the by the marketing team uh it it was astonishing to me and so I really uh decided to go back into my principles and started saying okay I feel like I want to spend much more time planning and have the perfect execution so so that way I'm not always chasing my tail the team itself isn't losing resources or constantly chasing their tails on what went wrong on the last event or on the last execution of any mission that they had so something you're you're going to learn is like in the Army Rangers we have this book called the uh US Army Ranger handbook and it's 200 plus pages of just Mission planning basically it it's it's astonishing how much planning goes into missions uh so when we plan for anything uh we would plan and not only just plan but we would do tons of research we' get as much Intel as we can uh we do all kinds of reconnaissance and we would take days maybe weeks even months of planning even if the mission was only supposed to be executed in a 20 minute 30 minute window it would take months and months of data and planning and I feel like we need to spend more time doing that inside of the tech space because so much resources are lost because of poor planning and so what I've done is I've taken this principle which is called metc metc it St for the Army Rangers it mean means Mission enemy ter uh terrain and weather troops and uh support available time available and civilian considerations now when you turn that into Devo make a couple changes still stays stands for metc but it's uh ecosystem understanding your target market uh troops and uh support still say the same I like to call my teams troops and then at the at the last two the time available and cost considerations because at the end of the day cost considerations is still a casualty if you have very poor planning that's the biggest casualty in web 3 is a lot of cost considerations I understand that there are millions uh actually obviously billions of dollars in in the web 3 space and yet I feel like we spend way too much time thinking we have all this money so we have room for mistakes but in the reality of situation we need to take in consideration that cost in itself is very much of a casualty uh because of poor planning okay so Mission understanding the mission is ridiculously important so I have this quote up here I I love military quotes I I live and Breathe by them all the time but this one's by General Mattis very uh famous uh Marine Corps General he says the more clearly we understand what we're trying to accomplish the greater effect we can have in accomplishing it people need to understand the purpose behind what they're being asked to do it is so important to make sure everybody is so Mission driven if we lose sight of the mission then execution not only just execution on the overall mission but execution on the smallest average tasks just become lacking on an a average basis by you it could be something as simple as a PR by an engineer it could be something as simple as a single tweet by a marketing person the moment they start losing sight or uh maybe not even understanding the greater goal of or the greater Mission that's when things start lacking and every single little mistake inside every single little task whether it's a PR whether it's a you uh whether it's a post or anything like that whether it is an update to the documentation or the SDK those little mistakes add up very very quickly into basically creating a critical failure overall so it's very very important to understand the who the what the why the when and the where uh when when it comes to missions uh for the overall team and this is also very important this is a great question to have too when you start hiring people or you're start talking to people inside of the ecosystem you work for if the people you're hiring or the people that are building inside your ecosystem if they themselves don't understand the mission then maybe you don't live by the mission yourself that enough because the people that you are basically supposed to be you know perpetuating that mission too don't see it coming from you so it's very important to make sure that that mission is overly stated not only to yourself but to your team and the people building inside of your ecosystem all right so the ecosystem it is perplexing at the very least to say that so many Devils when I ask them general questions about their ecosystem so many don't have any of this done market research SWAT analysis they don't have competitor Intel I it's now uh at the end of the day competitive Intel is interesting because all of us Deval there's this uh running joke that Devils probably have more loyalty to other Devils than they do the company they say work for which is so true but at the end of the day it is still important to understand what is the competitor technology like what is what are they doing that's making them successful but it's also good to also understand what is what are they doing that's maybe causing them to fail it's important to understand those kind of things and try to act as best as you can can uh to make sure that you're taking advantage of the information that you have advantage of the Intel that you're receiving um also understanding the overall Tech stack uh I work in the RO ecosystem so that means I haven't touched solidity in a while and I probably should I haven't done it in a little while but uh it's important to understand like what tech stack are you working with so then that also means what tech stack are you expecting people uh to build with in your ecosystem that's also means who am I targeting who am I trying to reach out to does so if I'm in the Roe ecosystem should I be constantly pushing information to people that have no care about decentralized front ends or uh decentralized data storage and all they want to do is build I don't know AI or they want to build just with solidity that's probably not my target market all the time but it's there may be overlaps where I do want to Target those so it's important to understand the tech stack and make sure that you are constantly communicating not just to The Ether of web 3 and hoping that that information lands in the right to the right people but you're actually really directly talking to the people that you intend to have build in your ecosystem uh and then regul regulatory landscape there's a lot of times where a lot of people are trying to talk to people that honestly are uh vastly restricted and or uh maybe they don't even have the the means to be able to build inside of your ecosystem so instead of just like I said shouting in The Ether we want to make sure that we're talking to people that are either trying to maybe solve these problems with your technology or are unrestricted by regulatory land the landscape that uh that is existing in in specific parts of the world so again down to Target Market you want to understand the demographics the EOG graphics and then uh behavioral patterns of the engineers or of the people that you are trying to have build inside of your ecosystem this is really really important because this I think this really is linear to let's say the mission because you can find let's say Engineers that are building with the tech stack that is linear to your technology but maybe the demographics psychographics and behavioral patterns aren't matching with your mission maybe they're not interested in building with that type of Technology because that's just not what what drives them so you want to make sure you truly understand what drives the people that are building uh the people that are building actively in your ecosystem and then obviously engagement channels we all know that web 3 in general is very very busy inside of you know X and channels like that um so I'm not going to sit there and push all of my content and all of my information or anything like that and and spend a lot of time on Facebook because Facebook isn't going to really drive a lot of traffic for me I I'm not finding a lot of active engineers in that space so understanding the channels in which I can best engage with those people uh obviously you know I'm leaving out things like forecaster and such but forecaster is a great place for that um and then Community leaders Community leaders inside your ecosystem but also Community leaders that could be linear to your ecosystem those are great people to communicate to because the moment you communicate to them and you've won them over and they start communicating to their Community that's a great way to also grow your ecosystem overall so troops and support uh with internal teams uh I I I actually just got done having this conversation with a with a couple people and one of the things that's really interesting is devell there's not a single Devo that is like another Devo and there's not a single Devo role that is exactly like another devell role um for myself I like to say that devils are a bit of a sliding scale of like you have the technical content creator and then it slides all the way to the opposite side of a little bit more of like the introverted side and that would be like a Solutions engineer and you have to understand that if you're building a devell team that that devell team needs to be able to complement each other if I have a bunch of content creators but nobody is really good at the solutions engineering side of things then your team is very off-balance you need to make sure you have a very balanced team uh great quote by General Phil uh Scher and uh this is the strength of the team is is each individual member and the strength of each uh member is the team so you want to make sure everybody's uh skill set as a devel is uh is actively compliment each other and it's not polarizing they're not trying to do the exact same thing uh they're all executing on the same Mission but in different ways so that also covers team skills uh tools and platforms so the support side is like what tools are available to you and this is also going to go into cost considerations and everything as well uh if I can have tools that are 10 Xing my efforts on a regular basis then yeah absolutely that should be part of the tools that you're actively using but it's important to make sure you're doing consistent research and finding tools and and things that are going to be able to help you execute exponentially on a regular basis so you know this could be anything from like Claud or cursor or any of those tools like that uh I'm able to build starter kits ridiculously fast with cursor and then I just review the code make sure it's sound and um and make sure that it's all tailored to the engineers that I'm targeting and I can get that done probably five or six times faster using something like cursor then I am able to do it you know pretty much on my own hardcoding it external Partners this is where the Devo love really happens and this is why Devils love to meet up at devell brunches and so and and and and so and so on because Devils we love to communicate to each other and see how we can collaborate how can our ecosystems work together how can we uh pull basically developers from each other's ecosystems and kind of almost like create a singular ecosystem this is really really important to make sure that you're constantly developing new external Partners to support each other and that's where as much as like we like to say it's important to understand competitor in uh competitive Intel or have competitive Intel it's also important to have external Partners to find synergies between other protocols or maybe even competing protocols depending on where there could be Synergy and then resource gaps always always always try to identify where the gaps are because those gaps are the ones that I I uh on missions we call those blind spots because and without having proper intel if you don't have information on something then that's a gap and you're not going to know it until that Gap is exposed and then that weakness becomes something that is honestly fatal in a mission in our case it could be very very uh cost heavy having something like well you know good examples like there's a uh the r weave Booth right now was not properly tested before the event so because of that they're having tons of electrical issues and everything like that so it's important to check those gaps and make sure that you have uh the ability to prevent things that are could be very costly either costly with uh financially or costly by time time available which by the way I've got three minutes left the time available is also very important to understand you need to understand project timelines you need understand what the event linen is is you want to understand how much you need to have done before a specific event so that execution of the event itself is smooth resource planning Market Windows buffer zones these are all very very very important to understand very early on and then cost considerations this is the casualty of poor planning if we don't understand fixed costs of you know things that we know are going to cost a specific amount and we need to understand the variable cost and how can we uh how can we benefit from variable costs and how do we not get hit by variable costs when they're the most expensive uh this could be a variable cost a good example of this is waiting till the last minute to buy tickets to eth Denver you know making sure your team is very forward thinking realizing okay who physically needs to be there who doesn't need to be there let's get these tickets in December let's not get these tickets you know a week before the event let's be C let's try to be very proactive in that kind of stuff Roi understand the the return on investment when it comes to sending either 15 people or five people depending on what's going to be the uh biggest benefit and the contingency funds and uh uh the funding strategies we're talking like burndown charts and everything how much does the dev program cost me so that I understand what am I going in with on the mission so that as I'm starting to execute I don't overspend or underspend and then in implementation this is just basically the having this uh plan that being able to execute on this plan uh uh repeatedly because the terrain always changes that's something that's very very important when it comes to Mission planning the terrain will always change but the process of planning will always stay consistent so as long as you're managing and staying consistent with planning no matter how the train terrain changes uh whether it's at eth Denver or whether you're at Singapore you always want to make sure that you're constantly executing in the same way each and every single time so that it becomes like a muscle planning is always something that you want to execute on repeatedly all right so that's pretty much it but uh if you actually want to see a very very detailed article on metc and how to execute with metc this is a QR code that you uh you can use it's a very long article but by all means uh I I highly recommend going through it cuz I do have quite a few resources in the article as well and I'll give it just a one second okay cool so on this one this QR code this is actually a PDF document that you can download and you can use to go through the metc planning for anything that you want to do if you want to go through metc for your entire devil strategy this is a uh a PDF that you can fill out and be able to try to do all of your pre-planning for either eth Denver or could be for the entire uh the entire devil program of yours so it's it's something that you can repeat on either small task or or very very large tasks and that's it if you don't you know please follow me on X I appreciate you guys being here thank you so much Patrick love I end it with 3 seconds left yeah we did it nice um if there are any questions uh please let us know we can definitely um bring you forward and have some comments on that but if not but if not we'll call it at that this is the last presentation of the day so let's all go home and eat cuz we all we're all hungry so thanks for being here thank you

Automatic transcript — names and jargon may be misspelled.