The EO Visionary Voices Podcast

Brent Peterson (00:01.454)
Welcome to this episode of EO Voices. Today I have Nate Amidon He is here with, well, you know what? I'm gonna let Nate do the introduction. He'll do a much better job than I will. Nate, do an introduction for yourself. Tell us your day-to-day role and tell us a passion that you have in life.

Nate Amidon (00:19.697)
Sure, well, thanks for having me on, Brent. So Nate Amidon, you pronounced it correctly, which is great. The CEO of Form 100 Consulting. And so we're a staffing and consulting firm that specializes in helping software development programs align their processes and deliver better results. So we're experts in the process of software development.

how we get everybody aligned on the same page and communicating effectively. So, work with mostly enterprise organizations and been doing it for about eight years. what's a passion of mine is really helping veterans transition into the private sector. And so, part of what we do at Form 100 Consulting is hire former military officers.

and we bring that leadership skill set to software development orgs.

Brent Peterson (01:20.29)
That's great. That's perfect. Thanks, Nate. Before we get into content, and today we're going to talk a little bit about EO, we'll talk about Agile. I have so much to talk about in Agile software development. It's like one of my passions that it's not on my profile, but we can talk for hours about it. I need to tell you a joke. You just give me a rating 8 through 13. So here you go.

If you watch Jaws Backwards, it's a heartwarming story about a shark who gives arms and legs to people who need them.

Nate Amidon (01:55.185)
Pretty good. I give you 11.

Brent Peterson (01:56.911)
Thanks little dark but still fun, right? Yeah, all right so When the green room you're a pilot with the Air Force How did you transition into agile tell it tells into software or agile project management or however? You want to say it tell us a little bit about that background?

Nate Amidon (01:58.757)
Yeah. Cool, man. But that's good.

Nate Amidon (02:18.725)
Yeah, I it's a different background than most people in the software development space, for sure. I really just fell into it when I got out of active duty Air Force. thought I would just get a job. I thought it would be easy. People asked me like, well, what what do you want to do? And I just said anything because I didn't really know. And it was it was a struggle to get a job. And when I finally got in as a I got in as a contractor and

started to realize like, hey, you know, there's a lot of parallels to what we do in aviation to the business community. And then I fell on an agile team internally with a client and really started to fall in and understand what, software development and agile is all about. And so I really fell in love with it because it really operates a lot like we operate in the military. There's a lot of, I love working with engineers.

very just get things done type of attitude and making, always prioritizing, making decisions fast, trying to get feedback. I that's what we would do in the military, especially as a pilot. You know, you're always just making decisions and if you make the wrong decision, then it's better to find out early. So, yeah, that's how I fell into the Agile world and it's just fit.

Brent Peterson (03:45.455)
Yeah, I mean that's such a great parallel and I don't always think about that, but now that you mention it, you know, think that waterfall is the other, type of project management you can do where everything is set in advance, right? And you just go along this, along this path that's already predefined. And more than often what happens in software development is that something changes along the way or more, more often, more than often the client says, Hey, you know what? I like this idea instead. We need to pivot, right? So I think that's where agile comes in.

Give us a little bit of background on how you found that and then how you work, how you consult in a workflow to have a successful agile development.

Nate Amidon (04:28.709)
Yeah, I mean, think your parallel is pretty accurate. We'll say a lot of times plans don't survive first contact with the enemy, right? So we've heard that before. And it doesn't mean you don't plan. The military is great for coming up with tons of plans, exercise plans, war plans. So you go through that exercise, but then in execution, you have to be able to pivot quickly, because things are always moving. And software...

and the military, especially in aviation, it's a very dynamic environment. So, you you're always in a complex domain. It's more than complicated. There's unknown unknowns, if you will. And so there's a lot of those parallels. And the things that we did in the military to operate and execute really well in that domain is the same thing software development teams and programs need to do to

to execute well in their domain. So we want to make sure everyone's on the same page. We're super clear on who's doing what, what the objective is, why we're building things. Why does your software team exist? Now, sounds like a stupid question, but it's not. It's a question that needs to be asked. And if you're on a software team, you should know the answer. And so really driving alignment and then making sure we're communicating effectively. And that doesn't mean...

we communicate everything in the world because then you have noise. And so there's certain things that are really important for a two way positive communication. Like for example, like if I flew C-17s, it's a large cargo airplane. We had two pilots that would fly the plane. And so when I asked to put the gear down and the co-pilot puts the gear down, I want confirmation that the gear is actually down. Cause if it's not down, your landing becomes more sporty. So

Those two way types of communication, well it's the same thing in the software development world. There's going to be big dependencies, big bugs, big things that it's really important you get two way communication on. But then at the same time, there'll be things that maybe you don't need to. All so we really focus on alignment, communication, and then the right type of processes to keep those in place. that I see a lot of times with clients where you either have too much process,

Nate Amidon (06:53.995)
or like almost no process and both of those end in chaos. So we try to find what I would call the MVP, the minimum viable process.

Brent Peterson (07:04.628)
I like that minimum viable process and I'm just going to go back in the conversation. I think I heard you say that our clients are our enemies. No, I'm joking with you. So, one of the things you just said, never mind. the, you know, one of the things that I found success with and you mentioned communication in the project management world was continuous integration, with your client and sometimes verbose written information.

Nate Amidon (07:12.855)
I hope I didn't say that.

Brent Peterson (07:34.465)
Because a lot of times at the end of a project the client has has some narrative in their head And if you don't communicate and especially if you don't document that communication Their narrative becomes the actual narrative at the end of the project no matter what happened Whatever they think happened is really what happened in their head right and there's no way to get around that unless you've documented this the process along the way documented each sprint each

each success, each failure along the way to help them understand this is how we got here. Tell us a little bit about your documentation process. We don't have to go into deep detail, but you've already mentioned how important communication is, but I think documentation is the same as important.

Nate Amidon (08:16.975)
Yeah, mean, they're one and the same in some ways. so as military officers, and I think why we fit in large enterprises better is because they're pretty bureaucratic. There's large bureaucracies. And well, the military's a very large bureaucracy, but you still have to get the mission done. Okay, so as an officer, I'd have my crew, and I would need to make sure everyone on the crew understood what was happening.

Then I also had to make sure that the colonels and the generals all knew what was going on on the battlefield. So you have to pair both of those together. And so a lot of times people think communication is a one way street where it's just, you know, from senior leader down to the team. And it really needs to go the other way. And I think that there's a huge opportunity for really kind of taking ownership of

Maybe you say the client or the director or whoever's in charge of a program. There's an ownership piece on the teams to make sure they're giving them the right information. so I think documentation is a piece of that, but it's the right documentation. It's kind of making sure we identify the right things and understanding what's important to them. Like what are they looking to get out of it and make sure that we're providing that information so they don't.

They don't make a good decision off bad information.

Brent Peterson (09:48.367)
I know earlier you had mentioned same page and that's an being on the same page is such an EOS term. We're both in EO. Tell us a little bit about it. It'll tell us do you follow any EOS patterns? you you espouse that and then tell us a little bit about your EO chapter and your journey through that?

Nate Amidon (10:11.419)
Yeah, so EO has been a great organization and it really because I never, I never set out to start a company. It sort of just happened when there was an opportunity and so being in a forum, being in a small group of people that have been through a lot of different business cycles, but also have different perspectives from different industries. And what I like about the EOS,

And for those that don't know, it's the entrepreneur operating system, right? is it really takes a diverse set of, know, everyone's business is different, but at the same time, everyone's business is kind of the same. And so a lot of what we do when we work with clients, especially if they're really struggling with their software development program, their teams aren't delivering, there's a lot of miscommunication. You know, we apply a similar type.

framework. Now it's not the same because it's really niche to software development, but the core principles are the same as far as making sure everybody's aligned. We're clear on the processes. We have quarterly reviews. We know where things, where the blockers are and really what we should be focused on at any given time. And so I think the EOS and I didn't know about the EOS really, you know, until maybe three years ago or so, but I love the idea that

You know, at a core level, we're a bunch of people trying to solve problems. And so how we structure and organize the communication flow between the people is important.

Brent Peterson (11:50.32)
What do you get most out of EO? Do you get most out of your local chapter, your forum, or do you attend regional or global events?

Nate Amidon (12:00.433)
So I haven't done much on the regional global event yet. like I said, I'm pretty new into EO. So the forums where I get, would say the most value and then the local chapter events are also really valuable. But I think the network, like the thing I tell people about EO is like, sure, you're in a small group with seven people, but those seven people know a lot of people and there's a lot of just neurons firing in.

in the universe that allows you to think about other things you hadn't thought of.

Brent Peterson (12:35.759)
How about maybe give us the high level about your chapter in Boise. How did you find out about EO? What is it that drew you to it?

Nate Amidon (12:52.517)
Yeah, so I was, when I got out of the air force, I moved to Seattle area and I was in the air force reserves and still in the air force reserves in the Seattle chapter. So are in the Seattle area. And so I, I moved out to Boise, a couple of years ago. And, when I was in Seattle, I had a mentor that was, very active in, in EO and he kept telling me I needed to get into EO. And so when I moved out here, he said, look, I have.

I know people at the Boise Chapter and you need to get plugged in. So that's how I got into EO.

Brent Peterson (13:28.783)
Do you find as a pilot it's helped you to be a better agile coach because you have to kind of check all the boxes to get the plane started, to get all the boxes or get everything going. You have such a huge checklist just to start. Does that help you be a better coach?

Nate Amidon (13:48.997)
for sure. my, the experience as a pilot in the Air Force, you take a lot of things for granted almost. Like I just started doing checklists, right? I mean, my first job was starting to fly planes. So it just was common sense to me that you would have a checklist for important things. So you didn't have to try to remember it and then recreate the wheel. But then when I got in the private sector, I realized that nobody does, nobody really does that. And so.

A lot of what we do is apply military execution and leadership principles to software development orgs. And I've gone through years of being a leader in the military and you trial and error through that whole process. So I've learned what doesn't work. And I've seen things go sideways. And the more you do this as a coach, the more you can really tell when things are starting to go.

You just have a better kind of spidey sense almost of where the problems are. so a lot of that's based on that foundation of being a pilot in the Air Force.

Brent Peterson (14:59.767)
One of the principles we have is we don't give advice in EO, but as a coach, really, sometimes you need to give advice. In fact, as a coach, sometimes, like I'm a runner, so if I have a coach, I want them to tell me what to do. How do you balance that out as a coach and as also just sharing experiences and resonating with other people?

Nate Amidon (15:23.153)
Yeah, I mean, that's always a struggle. I think anytime an agile coach comes in and starts telling you what to do within the first week, you should find another agile coach because every organization, team, product is different and they all have different challenges. so, and so I really seek to understand. I want to spend more time figuring out what the, what the problem is.

So one of the things we do in our company is when we go into a new client, we have what I call a good idea list. And so we're always just coming up with, if we had to determine what to do right now, what would we do? But instead of just telling the client what to do, we put it down in our list and then revisit it. We treat those as like hypothesis that we have to prove out. And what's wild is it's almost 50%.

of those ideas were the wrong ideas. Because you just don't know. You don't know what you don't know. And you can definitely make it worse.

Like in every scenario.

Brent Peterson (16:35.491)
Yeah.

Yeah, this is probably the second time today that I've mentioned the Jihari window, where you don't know what you don't know, you don't know something about yourself. Is that an exercise that you might do with your team?

Nate Amidon (16:53.937)
Yeah, I think we always come in in a very servant leader humble stance because we want to partner with our clients to come up with solutions. Because sometimes we'll come up with the wrong solution and even after we thought we've proven it out, it turned out to not work. But really, what our clients are looking for is action. They want us to try things. They want us to...

come up with new and innovative solutions. So, yeah, so we always have that stance going into any client that, you know, we're here to help and, yeah, and you can be wrong.

Brent Peterson (17:38.617)
How do you think AI, or how do you see AI playing a role in the future of software development?

Nate Amidon (17:47.129)
Yeah, so we're doing a lot with AI right now. And the more, I mean, it's here. It's not going away.

And I, you know, from a software development standpoint, I'm not, I'm not a software engineer. I'm an expert in the process of software development. Uh, and so I'm not going to speak too much to, uh, code writing code capabilities, but I will say I've heard the spectrum from they've never, AI has never written one line of code that I can use to, it makes me 10 times more effective. And, and both of those are from very senior engineers that I trust. And, and, uh,

and then everything in between. But what I think the real exciting part is from, just from an Agile or from a software development process perspective, is really the ability to implement low and no code automation solutions. so I think a lot, when we say software development, most people will think about us like,

from a sprint perspective, right? From user stories to release to production, or user stories to done, let's say. And so, but really software development is a much bigger process. Cause you have to figure out what to build. Then you have to determine the priority, get the right requirements, right? Come up with hypothesis and then break those things down. So there's a product management process that really goes into software development. And then there's a testing and QA and then the release part.

Right. And making sure that, that what you released is actually getting the benefit that you thought it would. All right. And so I think that those areas, the areas surrounding software development are going to be really ripe for AI. And there's so many cool things you can do just from driving alignment, driving, breaking down silos of information, speeding up processes and then using AI as, as almost like your assistant to make you better. And so.

Brent Peterson (19:56.912)
you

Nate Amidon (19:58.493)
Everyone talks about, hey, AI is going to replace engineers. Well, I mean, it's replace everybody. And we don't look at it that way. We look at it as these are tools to make us better.

Brent Peterson (20:10.991)
Yeah, I see it as making our software developers more efficient and my son is a software developer and he uses AI to help him in his role and I think that you know increases efficiency a lot as long as you're keeping an eye on things certainly it'll do its own thing and it'll it'll make some simple things ultimately super complicated that never work in the end or or Yeah, I can really see if you don't keep an eye on it. It's gonna screw up your project, right?

Nate Amidon (20:41.177)
Right, I look at it as it's a tool, right? Someone told me in a conversation that AI is like a nail gun versus a hammer, but you still need to know how to build a house.

Brent Peterson (20:57.111)
That's really good. Nate, we have a few minutes left. As I kind of close things out, I give everybody a chance to do a shameless plug about anything they like. What would you like to plug today?

Nate Amidon (21:08.337)
Well, I mean, I'll plug what we do. you know, if anyone's listening to this and they're struggling and they feel like they're struggling with their either software development processes or product management processes, you know, anything in that kind of business realm, usually you just feel like something's off. because software development can be hard to see. But, but if, if you feel like there's something off, there's probably something off. And so.

Yeah, I mean, I would say find me on LinkedIn, find our company, reach out to me, have a conversation, let us just kind of talk you through our process and how we approach these things, because we love talking about software development and process and how we can help teams get aligned. And we love to chat with anyone that's interested.

Brent Peterson (21:59.575)
And tell us your domain and your email address.

Nate Amidon (22:04.175)
Yeah, so it's form100consulting.com and email is nate.amidon@form100consulting.com at form100consulting.com.

Brent Peterson (22:14.927)
Perfect, I will make sure we get those into the show notes. Nate Amidon, thank you so much for being here today. It's been great conversation.

Nate Amidon (22:22.981)
Great, thanks for having me, Brent.