A Brief Discussion About Resources

If I were a different person this would be a white paper but I literally have a folder in my Google Drive called “Katie Makes Too Many Presentations” so this comes in Google Slides format:
The Little Dog Robotics Resource Guide

Note: There’s a lot in the notes section that helps contextualize the slides.

Disclaimer that this was made long before the VEX stuff happened and the reliance on VEXpro was a reality for my teams. I chose to leave that in for the sake of historical accuracy and to highlight how kit-like products were beneficial to my teams.

Who is Little Dog Robotics?
Long story short, Alex (my partner) and I were eligible to put a logo on 253’s 2020 tee shirt. Obviously that means we needed a “company” name. I also use it for my quilt business because I already made a logo.

What is this?
It’s a presentation I made two years ago because I was thinking a lot about what made our specific FRC teams successful (by our own metrics) and what lessons we thought were valuable.

That’s a good question.

Teams are aware of the obvious resources: Money, Time, and Equipment. However, you can give a team infinite of each resource and they can still struggle to be successful because there are other resources missing, namely: Experience, Network, and Institutional Knowledge.

Experience: Ability to recall common solutions and best practices (but not specific to FRC)
Network: Ability to ask for help
Institutional Knowledge (IK): The ability to recall & apply specific solutions from the field of work (ie FRC).

Additionally, resources aren’t a binary yes/no thing - they’re a spectrum. I used Pokémon evolution as an analogy in the presentation.

In the Pokémon analogy, a lvl 3 Experience Resource might be having folks like carpenters, machinists, or other people who Make Stuff For A Living on your team. A lvl 2 IK might be FRC senior students and lvl 3 IK is having a 10 year FRC veteran mentor (with an asterisk that pure Time Spent on The Team isn’t the point, it’s about being actively involved and improving and learning in those years of experience).

Is experience and IK a roundabout way to say “mentors?” Yeah. But one the key points of this presentation is that I believe you can work around what you don’t have… to a point.

I can’t TLDR this part, but basically there are a lot of ways to work with what you have and around what you don’t - it’s all in the slides. I outline how that worked for 4 different years of two different FRC teams.

And here’s the part where I completely contradict myself: when I wrote this, I genuinely believed that on some level, “all you need to succeed is a can do attitude.” And depending on your definition of success, that can be true. However, a positive attitude doesn’t change that it was a lot easier to be successful when I was on a well-funded team with access to free sheet metal and a full shop than when I was on a team with a limited budget and only hand tools.

Which brings me to my last note:
Why are you publishing this now (so much later) without an actual video of you presenting?
I did present this at WRRF in 2020 but can’t find the video. However, I workshopped this with my Network and since then it comes up occasionally that they want to reference an unpublished presentation. I don’t love every single thing in this and there is always so much more to say, but I’m not revising it any time soon and I’m so flattered that people want to reference it. So here we are.

So knowing that this was made a while ago, here’s some food for discussion: what am I missing? What resource work-arounds are your teams using? What resource work-arounds can my team use? Why is it that a productive network seems to have a sweet spot between 10 and 200 active people?


Can I please have information regarding how you put such awesome slide decks together???

1 Like

This is a fabulous paper/deck, especially the resource analysis section. Lots of great insights that are incredibly easy to miss.


Awesome presentation! Bonus points for dog photo.

Permission to shamelessly steal the Pokémon analogy?

1 Like

common LittleDogRobotics W

See More

y’all are awesome, here’s a digital hug :hugs:

1 Like

I spend a lot of time in my head, ask a lot of questions, write out way more than I share, and use gifs :wink:



Thanks for the share! Some of this we just figured out this year because historically, our resource issues were different when we start vs where we are now. This will be a very useful guide for us to re-evalute every year to gauge where we are at the present.

I almost made a counterpoint to the “manpower is not a resource,” but reading the slide notes I pretty much agree. An additional point to that is more manpower can give a team more time (with quickly diminishing returns).


This is everything I have been trying to present to our team but hadn’t put it on paper yet. Excellent work!

This is one of my all-time favorite “how to FRC” presentations. It’s not only full of useful info that isn’t really presented elsewhere, but it also turns you on to some new and valuable ways of thinking about your team’s problems, limitations, and opportunities. Great work on it!


Heads up, the third link in your resources tab is currently broken. @Allison_K, do you still have access to this or something similar, I’m interested in reading it


Yes most likely, but I’ll need to ask @Katie_UPS if she remembers which particular thing she was referring to/what it looked like. My content generation approach is a bit… divergent. I can think of a few things that match that description.


My best guess would be your “bus proofing” spreadsheet (which I am absolutely wink-wink-nudge-nudge’ing at my mentors to implement on our team as well, it’s fantastic).

Either it was or I wanted it to be a document that categorized the skills students gain as they move from beginner to expert in different roles. It might be what Kiera mentioned of a bus-proofing* spreadsheet

I am just as happy to link to 3538’s website in general as I think Allison and Co are running a fantastic program and have a really great approach to managing a team.

*Bus-proofing, for those who aren’t sure, is making sure that knowledge and skills are spread out such that a team or organization isn’t reliant on a handful of individuals to be successful. In blunt terms: if a key individual got “hit by a bus,” how screwed is the team?


Alrighty, after some investigation I think that this, or something similar, was the resource that was originally linked. There were many iterations of that chart.

That was indeed a precursor to the bus proofing concept. My first mention of the bus factor on CD was in this post here. The key leap between the original chart and the bus factor chart is a developing idea that problem solving is key, so I wanted to take the discrete knowledge and skills from the chart and start forming a paradigm that is more conducive to problem solving.

The bus factor concept continues to evolve.

(Aside, I’m really leaning into hieroglyphics as a form of communication. Emojis are actually great for providing visual cues.)

I’m trying to write top level descriptions for each skillset, and then each one will also have a one pager with the associated responsibilities and skills (a bit like a job description). They can still be charted out and tabulated as metrics of bus-proofing.

There’s also various tangentially related bits regarding how to gauge skill level development for individuals. My biggest struggle with this at the moment is how much resolution really needs to be assessed or communicated.


I agree with most points certainly that it is not a weakness to match scope with capability. As you outlined, make-or-buy and analysis-of-alternatives are critical. My experiences lead me to continue to believe that labor (“manpower”) is a resource but it does not apply linearly. There is a famous book called “The Mythical Man-Month” that expands on that reality and analyzes the causes. As much as I see the truth in what you say for most people, my career has been filled with counterexamples. It is my dream to replicate my constant unlikely technical successes with others. I am not extraordinary but when my mother used to say “You can do anything you put your mind to.” I took it too seriously and never stopped. That is one of the biggest reasons for my involvement in FIRST.

BTW an established team has another resource - trust. When students are in a team that has institutional practices and knowledge they trust that those are there for a reason. There is more knowledge and access to experts here (CD) than you might ever need but without trust that just seems like people up in a high palace to students.

1 Like

That is exactly what I wanted it to be so the link is now updated :smiley:

What I like about that document is it’s really hard to self-assess your skills because you don’t know what you don’t know - this gives students and mentors a way to see “What are the skills I have? What is the next step?”

I like to share the story of how my senior year I designed and built our claw (tube game) and I was so proud of myself, but the failures that I ran into with the design during competition were because I didn’t know what I didn’t know.

That’s actually how this whole thing started. 2020 got cancelled and I was really bummed that our robot wasn’t going to be seen. I was thinking about how proud I was (and am) of 253 and how it felt like we were able to pull off robots far better than what we should be able to. While there are a lot of things that go into a team’s performance, I knew that something about how Alex and I operate with teams does seem to work and I wanted to “bottle up the magic.” Originally the presentation was about game strategy but the hindsight conclusions were that we successfully matched our goals to our resources which is how we got here.


QFT. For y’all not in Northern California, 253 has experienced a step change improvement in competitive level in the last couple years. The bots still have that handmade look, but the on-field performance is :fire:

1 Like

I wasn’t sure if I should include the following in my original reply because it already felt like I was at risk of sounding patronizing. However since you mentioned “I didn’t know what I didn’t know” I will write it after all. The process I follow getting started in any new area is:

  1. Minimal orientation. Skim, do not read, the “instruction manual.” You don’t want to learn the song, just enough to pretend you’re singing.
  2. Do a small, related, aggressive, but inconsequential project. Make sure you are safe but otherwise simply throw yourself into a pit beyond your depth. No one is better at this than Simone Giertz. I love her videos but they are unfiltered so I can’t always recommend them.
  3. Reorient, now consulting “the manual,” experts, etc. Observe the difference in how they approach. How do they detect and deal with issues? What are the stages of their process?
  4. Do the main project.
  5. Define the metrics to improve
  6. Iterate

If you consult with experts and do your learning first then you have no context to integrate the information. The details will be missed. Trying a throwaway project gets you past unknown unknowns. You have to be willing to set the success criteria as “learned what not to do and lived to tell the tale.” though. It should in no way resemble a quality product. I prefer there to be a lot of laughing and humility along the way too.

1 Like