Modern problems require modern solutions, right?
The problem is, it’s becoming increasingly difficult to understand what solutions are required for a given problem and even harder to task a team with finding them.
That’s why Bob Ritchie, VP of Software at SAIC, thinks the top-down management model is dead. To replace it, Bob is championing a “team-of-teams” model that provides his developers with far more autonomy - so much, in fact, that they can even self-elect their leaders.
On this week’s episode of Dev Interrupted, Bob discusses the challenges of software development in an increasingly dynamic environment, why he believes developers should be no further than 4 steps away from their CEO and the historical challenges of connecting results in Silicon Valley to those in the federal government.
Who would've expected a federal government tech integrator (Science Applications International Corporation), to be on the leading edge of developer autonomy?
Episode Highlights Include:
- (4:19) Team-of-teams model vs top-down leadership
- (10:17) Devs self-electing their team leads
- (15:21) Why no position should be more than 4 steps from the CEO
- (20:29) Invest in your teams until it hurts
- (34:00) Treat hiring like sports organizations treat the draft
- (35:45) Historical challenge of connecting results in Silicon valley to results in the federal government
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
Transcript:
Dan Lines: Host
Rob Ritchie: VP of Software at SAIC (Science Applications International Corporation)
---
[Music Playing]
Bob: [00:00-00:19] In the software world, I can't think of a case where anyone knows the right answer, for even above an 80% threshold to maximize impact with customers, to say definitively “Build me exactly this in exactly this timeframe, and this will be your guaranteed result.” The Team of Teams model gives you that flexibility.
Producer Ad: [00:20-00:50] Over thirty billion dollars in engineering wisdom will be at your fingertips at INTERACT on April 7th. Join engineering leaders from Netflix, Slack, Stack Overflow, American Express and more at INTERACT, a free, virtual, community driven, Engineering Leadership Conference. One day, twenty speakers, all selected by the thousands of engineering leaders in the Dev Interrupted community. If you are a developer, team lead VP or CTO looking to improve your team, this is the conference for you. Go to devinterrupted.com/interact to register today.
[Music fades out]
Dan: [00:50-01:07] Hey, everyone, welcome to Dev Interrupted, I'm your host, Dan Lines and today I'm joined by Bob Ritchie, Vice President of Software at SAIC, which stands for Science Applications International Corporation. Awesome name. Bob, thanks for joining us.
Bob: [01:07-01:08] Thanks for having me, Dan.
Dan: [01:09-01:20] It's awesome to have you be on the show today. Let's start by giving our audience the opportunity to know you a little bit better. For our listeners who may be unaware you know, what is SAIC? What do you do there?
Bob: [01:21-01:51] Awesome. Yeah, so SAIC is a federal government, federal systems integrator. And what that typically means is government contract work around engineering and science and research and development. And IT managed services to drive solutions for the federal government, whether it's intel community, Department of Defense, or federal civilian agencies, and what I do there, I have the privilege of leading the software organization within the company. So really focused in on how do we make SAIC a software company that happens to deliver solutions for the federal government?
Dan: [01:52-01:55] Yeah, you've been there a while, like fifteen years, right? [Crosstalk 01:55] Long time.
Bob: [01:55-02:18] Yeah, I had a stint where I was part-time consulting employee of SAIC in 16, from 2016 to 19. Where I was-I had the privilege of working for a really, kind of forward leaning leader at Capital One named Gil House and then when he moved to JP Morgan in 2019, I had the chance to come back and take over the-the software org, at SAIC full time and it just seemed like the right time to come back.
Dan: [02:19-02:22] Yeah, that's awesome. What's the size of the org that you got under you?
Bob: [02:23-02:32] So my-my direct line, kind of Team of Teams model we're at a little over two hundred folks, and then dotted line software within the whole company is about forty-five-hundred engineers.
Dan: [02:33-03:00] That's great. We're that-we're going to dive into Team of Teams, we're going to talk more SAIC, I went to the website and I just have to say like the first two, I guess, you know, it scroll-it's like a banner that scrolls, you know, left to right, says some of the coolest things; creating the connected battle space. That sounds interesting. And then the next one is mitigating drone threats. Sounds like you get to-that's like very, very interesting stuff.
Bob: [03:00-03:16] There's definitely some unique and, we’ll call it, exquisite problem sets that especially in the Department of Defense and the intel community that you wouldn't necessarily run into elsewhere. And so, it [crosstalk 03:10] definitely gives a wide range of, you know, not just building a web app, or not just building a couple API's type of thing.
Dan: [03:10-03:11] Yeah!
Dan: [03:17-03:27] Yeah, pretty cool. Now another thing about you, kind of like a more personal thing, I hear you played college ball at V Tech. Is that true?
Bob: [03:27-03:54] So I have to put in air quotes of “playing” yes, I was an unrecruited walk on. But yeah, I got to play-I had the privilege of playing division one basketball in the Big East. And ACC because my time there kind of spanned both conferences, which was really cool from growing up in the DC Metro area and-with Georgetown and Maryland, and Duke and UNC, you know, all was on TV. To then get to play, thankfully, in the same conference that you know, Coach K and Roy Williams, and those guys, were all still coaching when I played. So that was a really cool experience.
Dan: [03:55-04:24] Yeah, I hear you. I mean, that's a big-time conference. And I know you're saying yeah, I walked on, but you made the team even make getting the team as a walk on like, you know, the talent and the recruiting is insane. So that's-that's really cool. So, speaking of teams it leads-it leads us well to like the teams of teams stuff. So, I know you have a lot of opinions and how teams should function in the software delivery process. So, let's talk about that a bit. What is a Team of Teams model? And what is a leader model?
Bob: [04:25-06:06] Sure. So, I'll work backwards. So, I especially in federal government contracting, and just by nature of the way we say the Department of Defense's historical way of operating in a command-and-control kind of leader top-down structure. A lot of historical federal system integrators model themselves in that same kind of pattern because zipper principle, you want to align your leaders to their leaders and be able to speak the customer's language. Some of the challenges with that though, is it creates and it's really more of a relic I'll say of the Industrial Revolution era of having this kind of cog in a machine mentality. And then you have a system of systems built up, and everyone just knows their own role in the machine, you know, “What's my job as a cog?” and the next layer up, and it creates a top heavy and top-down kind of micromanagement ecosystem that is just not what resonates today with kind of knowledge work and thought work that in art form, like software development is in today's day and age. And so Team of Teams model kind of presents a different concept to that same construct, to instead of having this hierarchical, you know, command and control, you know, top-down micromanagement, the leadership strategy pivots to creating a more of an environment where there's a shared vision and a shared mission, shared, kind of, principles and values that all the teams adhere to. And then the teams are granted a level of autonomy, that then lets them define and discover their own purpose and where they'd fit in that vision. And oftentimes, then often provide invaluable feedback of how that vision needs to be altered based on what they're seeing, as opposed to kind of that historical, you know, I'm just being told bow style type of model.
Dan: [06:07-06:15] Yeah. And are you saying the “thou shalt” type of model, is that the leader model? [crosstalk 06:13] Or is leader model a little different, too?
Bob: [06:13-06:49] Yeah. So-so I at least the way I interpret leader model is we'll just because I'm a software guy will say it's-it's the difference between the imperative and declarative state, right, like, the top-down command and control requires imperative scripting all the way down to get exactly the outcome that you're looking for where a Team of Teams model is more, here's the direction we're going, this is where we're headed, this is why we're headed there most importantly and allows kind of the teams to self-organize around that mission, around that purpose, and deliver the outcomes that I guess-what I've experienced a much more effective break.
Dan: [06:50-07:14] Are you saying to yourself, like every day okay, like I gotta-we're a Team of Teams model, and therefore, I need to act a certain way as a leader do you like-do you have to remind yourself not to be a-I don't know, it's kind of like Bill-Bill Belichick. It's like, “Do your job, just be a cog. Don't think you just do what I tell you, and we're gonna win the Superbowl.” No, you can't think like that. So how do you go about your day to day?
Bob: [07:14-08:19] I'll say it certainly takes practice. And-and, you know, when I-I fortunately had the benefit of seeing this model in action, like I mentioned that I'm gonna go house at really massive scale at a fortune 100 companies and that he kind of seated in my mind, okay, this is an effective model, it works. And in some early Vyas, they'll say, towards the-the model works, as far as having to cognitively think about it. Yes, because I mean, I'll say there's one other dimension of kind of the command-and-control structure that feels very natural and human, right, especially for Type A people to feel like I need to be in control. And I want to tell him exactly what to do. So it's just one of those things that you just have to be aware of that kind of natural impulse to react to a situation and just, you know, take a beat, think about it. And really kind of drive every decision through that value lens of is this what's best for the environment, I'm grading for my teams? Am I being clear, and the communication that with teams, which again, the two teams model allows a lot flatter structure to, which then enables some of that kind of cleaner communication?
Dan: [08:20-08:26] What do you do for a team leader that's not performing in aTeam of Teams model?
Bob: [08:26-10:35] Well, it's-so at our current scale, I'll say that, that that situation hasn't arisen too often. But when it does, it's-it's really a, a-excellent second order effect benefit of the Team of Teams model is that the team self-polices to some degree. So, you're already-if something gets escalated, it's-it's only in the cases where the team hasn't been able to self-adjudicate. And the long-standing teams aspect also creates this natural, it's almost like cliques in school, like it's, you know, humans are social animals so they're naturally going to organize into these groups of people that they enjoy spending time with, you know, their quirks and their foibles that they all like and kind of balance each other out. Where one of those player coaches is starting to drift away from this am, I am supposed to be a servant leader within my team and more, you know, kind of thinking about what's my own kind of fiefdoms build out or you know, now bridging into that command-control kind of mindset. The team is really the first line of defense to say you should just check them because it's just like your friend, you know, if your friend is going sideways, like hey, this isn't who you are, right? So that that gives you at least one level of defense that doesn't require a lot of top-down prescription or org engagement. But then certainly when there's a circumstance where someone is just moving completely orthogonal to your values and principles of your team and of your ecosystem, you have to have those sorts of kind of coaching opportunities to say, “Look, that's not who we are as a group. That's not who you are as a person. I know you to not be that way as a person. Let's revisit how you got there and really start to drive at the why of what's going on.” in circumstances, sure, it can lead to an action where maybe the team needs to self-elect a new leader. And again, I'm a nerdy software guy. So, everything to be it's like a gossip protocol within, you know, this distributed system, the teams can elect their own leaders, the player coach themselves weren't appointed top down. It was the team all agreed that, you know, like a James English is the right leader for silence of the lambdas or, you know, a Brad Stevens is the right leader for the Vulcans. And we also encourage all our teams to come up with really clever names, you know, kind of part of it helps.
Dan: [10:36-10:39] So they actually self-elect as opposed to-
Bob: [10:38-10:38] Yep.
Dan: [10:39-10:56] So okay, like, tell me how that works. So, I'll give you like a scenario, you know you-you got to get projects done. Bring a group of people together, this is what I would do as a leader, that I think have all the skills needed to get that project done. And then they just say, okay, we're voting on our leader.
Bob: [10:57-12:13] No, well so, in the context of a given project, at least, the way our model operates is we bring an already existing team to execute any projects that need to get done. The forming of the teams, and the election of the leader is on opposite side of the spectrum from the growth model, right? So, we're-when we're going out and looking of how do we grow our capacity of teams, we're looking for those long-standing groups of people that maybe have stif- been stifled as if there are other opportunities, other companies other you know, elsewhere in the market, where they themselves showed aptitude to grow a team. So, we'll pull them in, and then they can hire up and grow their own team. So that's one model for growth. But the self-elected leader aspect is okay, this person is forming a team so naturally it becomes a self-election. But we've also had cases where a long-standing team would say like the player coach on that team says, “Hey, I am feeling like, my technical growth is taking a backseat to the servant leadership responsibilities.” the player coach, he brings that to us and to his team, and his team then self-elects, “Well, we totally hear you, you've served us well, for two/five/ten years. And now we're gonna, we're gonna give this other great engineer an opportunity to lead the team. So that's-that's where that self-election comes into play. It's not necessarily win forming around delivering an outcome.
Dan: [12:14-12:28] It's like the-you have to have the ultimate self-awareness, to say, “Hey, I want to grow. I want to be on the team, but I need to grow my skills in another area, I'm gonna help promote someone else.” You got to be really have trust in yourself and the team.
Bob: [12:29-12:59] Absolutely. And for the most part, that's-that's where the team kind of takes on the form of a nuclear family structure, right? Like, so a family is going to care about that nuclear family and understand if someone says, “Hey, look, I want to go to art school, I don't want to follow in your footsteps and become a lawyer.” right? Like, those sorts of things is something that a family that cares about each other will always be supportive of. If you don't have that long standing team model, you lose it-you-that's something that in a command and control structure could never happen, because everything's going to be “Well, you're my cog. You can't stop being my cog.”
Dan: [12:59-13:22] “I don't want to do what you did Dad; I want to go to art school!” Yeah, we hear that story all the time. And the good families deal with that in a good way and bad dynamics like “No, you have to go be what I am.” That's like the worst-case scenario. Why do you think that there's so many leader models, which you were describing, it's kind of the opposite of the Team of Teams, why do you think there are so many leader models out there?
Bob: [13:23-14:33] I think-I think a lot of it is more, we'll say remnants of what worked really well for I will say, from 1950s onward, in the growth of a lot of the industries and markets that we're playing in today. In that it was it was very ordered. And the-the problems weren’t as, we'll say, complicated as maybe they are today. And so, an assembly line type of model might have fit better. You know, although the term software back due is very in vogue, it's an uncomfortable term for me, because I think of software as an art form so, putting the factory connotation on it is messed up. But the software industry, you know, if you look at 70s, 80s, 90s, it was more about cranking out continuous product and even just industry writ large, was who can crank stuff out as fast as possible, then the command-and-control structure naturally feels like, well, if I tell you exactly what I want, I'm going to get the most efficient result. The challenge is in the how complicated and complex the world has become; No one actually knows what they need. They might be able to imperatively describe what I want. And that model is where the Team of Teams model is an existential imperative to jumped to.
Dan: [14:34-15:29] Yeah, it's kind of like I mean, if we know what we want, if we're on an assembly line, we're making the same shit every day. Yeah, like I'm going to tell you how to do your job, how to be more efficient, and we'll crank out more widgets, for sure. But sometimes, especially now you're saying, and I can see this too, with like my company LinearB. And as we're growing, we're doubling in size and all of that. It's like no, I need you to-I don't know the answer to the problem. I'm giving you a problem team. Yeah, we'll figure it if I knew exactly what to do. I don't know, just do it myself like that your job is to go find it-find solutions and to implement it do both. So yeah, I can totally see that as well. You, you mentioned something, you said like, you want everyone in your company to be at most, four steps from the CEO? Why is that so important to you.
Bob: [15:29-16:46] So that's an ideal state in any company, especially ours is-because of the importance-In order for a Team of Teams model to thrive, there has to be that cohesion of vision and purpose. And as you add layers between, say, the-the individual contributors on a team, to that CEOs vision, you start to dilute the messaging, personalities naturally come into play, and maybe you'll have a personality shift or pivot the messaging and what the CEOs vision actually is. And so those-at most four layers is really just a representative of, as you get beyond there, I've observed that it starts to break down that kind of a clear, crisp, where what's my purpose? What is my team, what's the problem space, so when I say, “Here's a problem, go solve it.” they have a frame of mind, in your of what the vision of our company, what the business model of our company, what our organization is striving towards, it just really prevents that communication breakdown, which, then in turn, the Team of Teams model is, is you can think of it as almost fragile in that sense that if you start to layer in too many command and control structures, between the teams and the tippy top vision, the teams themselves start to, it's almost like you've-you've clipped the rose off a bush, eventually the rose is gonna die because it's too far removed from its sustenance.
Dan: [16:47-17:02] Or do you think that kind of this Team of Teams model and then staying like closer to the CEO, which is really a translation for, you know, the vision, or where we-are we all rowing in the right direction? How do you think all this affects developers, software developers?
Bob: [17:03-18:02] Well, so I think at the end of the day, I mean, I can't speak for everyone, but most of-myself and most developers that are in my organization, got into software because they like to build things, right. Like, you know, we all did Legos and connector sets, and everything as children. So, we got exposed to software, some of us at very young ages, and said, “Oh, my gosh, I can build things without physical world constraints. Let me go build let me go build.” And then you start to say, well, “Are the things I'm building, is anyone finding them valuable, are they useful?” And so, the Team of Teams model lets them not only enjoy that passion of building and creating, and, you know, really the art and craft of software, but then see it connected to a bigger vision, something bigger than themselves something bigger than their team. And so, you get kind of the-the benefit of both having autonomy, but then also your purpose. We you know, like, I'm a big Daniel Pink subscriber in terms of motivation, that helps you find you know, that joy and happiness in your day-to-day life, because you're seeing it come to fruition.
Dan: [18:03-18:05] Who is the person with motivation?
Bob: [18:06-18:31] Oh, Daniel Pink? He wrote a book called Drive back in the early Aughts that-or the early 2010s. It's a really wonderful set of case studies around motivation 3.0, and how autonomy mastery and purpose for thought workers and knowledge workers specifically which I consider software engineering in that kind of bucket. It's more than carrot and stick models of kind of the command-and-control structure, right?
Dan: [18:31-18:35] Yeah, I highly remember the era everyone was talking about this book now.
Bob: [18:36-18:39] Yeah and the little RSA ANIMATE video. Exactly, yeah.
Dan: [18:39-19:01] Well, we’ll include it. And it's always good to call out what people are reading, or you know, what you're getting motivated by. Last question in this in this area. Do you think for software teams, Team of Teams is always better? Or do you think that there's an, I don’t know, maturity state or a situation where the leadership model is better?
Bob: [19:02-20:20] So I'll say when it comes to execution, in a dynamic landscape, Team of Teams is almost always better. I can't think of a model where when we're not 100%, certain of exactly what we want, and what we need to deliver an outcome, that Team of Teams model gives you that flexibility. And like you said, you're not I'm not telling you what to do, I'm giving you a problem to solve, go solve it using this, you know, here's the ecosystem environment and framework. There are situations where there is a discrete-like, so I wouldn't think maybe, maybe in medical, right, market that there is a prescriptive way to do this surgery, you know, let me-let me Caucus as a team and, you know, I'm gonna operate on you, but I'm going to come up with what my team thinks, right? So, there's certain fields like that. In the software world, I can't think of a case where anyone knows the right answer, for even up above an 80% threshold to hit-to maximize impact with customers to say definitively build me exactly this, in exactly this timeframe, and this will be your guaranteed result, it can happen right, you can have a good result where you meet 80% of your market. But if you start out on that path, it's a really difficult thing to do that you get that 80%, you get some success there to then pivot to ever reach that other 20%. That would be a real challenge.
Dan: [20:21-20:37] Yeah, so totally makes sense. Now, another thing that you're not shy about is investing in your teams, you've said that leaders should be investing until it hurts in continual learning. You have to unpack that a bit. What does that mean to you?
Bob: [20:38-22:21] So the-the foundational responsibility I see in this is to plug some other folks, Simon Sinek in everything he does, we'll Start With Why and Leaders Eat Last and the Infinite Game, the foundational responsibility of leaders is to create an environment where your teams can thrive, right? Like he makes all these anecdotal webs about the CEO is responsible for the people who are responsible for the people who are responsible for the outcomes. They're not responsible for the outcomes themselves, they're responsible to creating that ecosystem. And so, I think continual learning is such an important dimension, not only from the, you know, the three pillars of motivation, 3.0, written mastery, having that opportunity in your day to day lives, right? We spend so much of our time at work throughout the course of our life, if I will have the opportunity and work to find some level of mastery in a craft or in multiple dimensions of my craft, I'm gonna seek an opportunity where I can go get that-you get that done. And cogs don't necessarily, right. And so, this is this is a real dichotomy there; cogs don't need continual learning to do their job. They know exactly what they did yesterday, and what they're expected to do tomorrow. And there's, there's certainly a place in the world for that type of work, I just don't see it as in software. And so specifically, in software, and we'll say cloud and Site Reliability Engineering, and data science, data engineering, it's such a craft and art form that is continually refining and continually evolving. If you're not as a leader, investing in those teams to stay as sharp as possible, you're doing a disservice to your teams of eventually your team skill sets are going to erode. Or the-the actual folks who, you know, subscribe and really thrive and it's going to Teams model are going to go seek opportunities elsewhere that the learning is there.
Dan: [22:22-22:28] So what do you specifically invest in for developers, in terms of training?
Bob: [22:29-24:17] I’m a huge proponent of access to content as a table stakes for any, you know, as a term of employment as if you will. So, access to, I'll say, well, just shameless plugs, Linux Academy and A Cloud Guru, which are now so A Cloud Guru, acquired Linux Academy. And now Plural Sites acquired A Cloud Guru, which are three of the premier kind of, you know, self-paced on demand learning content platforms, having unlimited access to that content. For every team member across every teams, whether solid line in my organization, or in the company is-is like a foundational table stakes almost, right? You need to make that a part of employment, not something that someone has to come ask for. But really where the investment comes, especially in the federal systems integrator market, because so much of our business is time sold, right? The government contracts to you, it's almost like a lawyer with billable hours. If you're not billing to your customer, you're offset, you're not generating revenue, then so you're costing and so that's where the investment happens is; How do you carve out time for your folks to not only have access to that content, but actually immerse in it and go and take that training, do some hands-on hand labs, do some experimentation? But that's again, where the Team or Teams model really benefits because it doesn't mean like-but if I'm a cog, I have to carve out 20% of your time, the whole machine stops while that cog is doing training, the team can then self-pace like where maybe two members of the team are focused on training this week, and to others next week, and then maybe a month from now, then someone else needs to say I'm going to take a bootcamp for four weeks, the team could self-organize and the team gets itself to that billable metric. It creates a brand-new bottle in the-in the federal system integrator space, by which you can do continual learning without having this exorbitant kind of overhead costs, which is really the secret sauce that we're trying to bake in at SAIC.
Dan: [24:18-24:33] Do you have any guidelines of how to carve out time? Because a lot of it-I think that's one of the most difficult things is actually making the time available to learn and improve. Do you have any tips there?
Bob: [24:34-25:55] So I would say don't be shy in budgeting cycles to ask for what you want. Right? So, say you're going through a quarterly or a, you know, an eighteen month or twenty-four month forecasting of your budget, and you're projecting growth of your teams; say “This is the amount of time I need to carve out, so this is the amount of overhead and funding I need.” Worst case scenario you get push back, right, and then so say you get that push back. Step two, now I've got the push back how do I get creative about creating that time, which is probably more to your question. And that's where you work opportunities for that team to work on programs that would provide that same level of learning experience. So rather than go and say, I'm going to do a boot camp and get AWS developer certified, can I, as a team, get signed up and work on a project where I'm gonna get exposed to the exact same learning, but I'm gonna get more hands on, less textbook. And then at the end of that working that customer engagement, you've had real world experience that's equipped you to go get an AWS certification. So really tying that work they're doing as part of their career growth and treating the work opportunities as learning opportunities, and helping the employee see that it's not only you're delivering value to your customer, but you're expanding your growth in cloud and Kubernetes, and full stack and react, etc. And so that's, that's where we get creative with the Team of Teams model to invest in learning without necessarily having such a bottom-line impact.
Dan: [25:55-26:25] What are the pushbacks? So, I-typically you'd have to justify maybe to a CEO, or sometimes a non-like a CFO, like a non-technical folks about why it's important to do training? Do you have any way that you-because it costs money or cost time, and time is money, it's the same thing? Do have to you have any ways that you've positioned it to someone that you're trying to convince?
Bob: [26:26-27:49] Yeah, yeah. So-so there's, I mean, there's a lot of qualitative things you can do, right, like cite studies and Harvard Business Review and things like that of investing in continual learning, and the long-term improving effects that it has on your consistent quality, and the type of talent you're attracting and retaining. But quantitatively, there's actually a really cool company out there called Blue Optima that we've been working with the past year, which then it scans and provides an analytics vantage point, just looking at your source code repositories. And if you're using you know, JIRA, or some other agile SDLC tool, will actually create insights into how your teams are performing. So you can tie tangible results to say by investing in this-so say I do a learning campaign where I want to focus on getting a bunch of people, CKAD because Kubernetes is a big push; I can show quantitatively how that investment in training has resulted in more maintainable code, better solutions for our customers, that then differentiates us in the market to go with new business. So, you create that business case for leadership. Say, it's not just about investing in people, which I wish it-you know, altruistically, I wish it was just about investing in people. But like you said, at the end of the day, these are businesses. So how do you quantifiably tie that to a business case, you can show this objective evidence lead to these additional new contract awards, and so that that helps justify kind of that perpetual motion machine.
Dan: [27:50-29:32] Yeah, we I mean, we're doing a lot of this at LinearB, engineering metrics, things that help every developer save time every day, get their work done faster. And here's what I've learned that I'll share with you and the audience. Usually, if you're talking to a non-technical type person, the thing that they care about is delivering projects on time. Project delivery; that's the output that they can see from an engineering organization when they're not in the details, features, bugs, happier customers, I mean, they-you can-they can even understand, okay, production is more stable, I can get that and you know, features are being delivered. And there's a lot of metrics out there that we talk about on the show. Predictability, are you doing what you say you're gonna do from a delivery standpoint, cycle time, bugs found in production, we can get all the way down to how long are our PR cycles taking, making them faster. And I have found that you can use this type of data to then do two things. One, you can justify, okay? But two it's really about gaining trust, because you can say, “Here, I'm going to visually-okay, I'm asking for a bunch of training and cost money in time. But I'm going to be accountable. We're going to meet every week, I'm going to talk to you about our project predictability, I'm going to talk to you about our engineering health metrics, how this is impacting it, that's where I've seen buy income from. So just a little tip for the audience of what has worked for me. Are you ever afraid of investing in people and having them leave? Does it matter to you if you make like kind of this large investment and people are gonna like leave or something like that?
Bob: [29:33-31:25] Not really. So, it's kind of a cool it. I hate to say that everything is so foundationally rooted in the Team of Teams model. The teams when I say there's a long-standing team, most teams that I've ever experienced in my career stick together whether people leave the company or not. And like so I'll give an example when I left SAIC full time to go part time and work in Capital One. I still was a very daily active member of my former team’s, you know, their own private Slack workspace called a happy place, right like that, hey, we want to get in there and, and we want to still collaborate and talk about ideas. And so the Team of Teams model, whether they leave the company, and then they still stay connected to that team, and what I've seen, at least at our marketplace with the federal government, there is such a demand and a need for growing these high performing continual learning teams, that for the federal government to meet its objectives, and especially in the DOD and IC I see this, we need to create a broader defense industrial base that adopts this model. So, I still feel like SAIC has done its part, if we've trained up a bunch of really great engineers, and they've got these great new opportunities outside of the company, they'll take that model and evangelize it wherever they go. Now, we're, we're still fulfilling and tied to our purpose as a company, which is to deliver exclusive solutions that, you know, power federal government forward, so I don't have too much risk of a fear of that. And then I'll say, because of the Team of Teams model and that connective tissue, we get a lot of boomerangs like myself, that when new opportunities come up there, so you know, I'm still connected to my team, I'll come right back. Because I stayed in contact, I'll pick up right where I left off, we already share a common set of principles and values, it makes it really easy to come back. So that's how I at least communicate that to my leadership, that there's no risk in training someone in leaving, it betters everyone.
Dan: [31:26-32:18] You know, what I've been thinking about a lot lately? Hiring is so difficult right now, everybody's talking about it, right? That's like a global thing that's happening. And so, what that means is, sometimes, or maybe a lot of the time, you cannot find the perfect person for the position right now. But what I've been thinking about is, maybe I can find the perfect person, plus some training, plus their ability to improve, they'll be the perfect person in six months, or a year or a quarter. So, I've been starting to think a little-a little bit differently. See if this resonates, let me kind of like measure, like how I evaluate the team is around ability to improve, as opposed to like-can you take the learning and do something with it, as opposed to where you are right now? Do you ever think about that with your team?
Bob: [32:18-33:59] Yeah, absolutely. Absolutely. So, I'll even expand upon like, maybe instead of finding the perfect person, I can find someone who with the right training and the right environment could become the perfect person. And yeah, that with the team model that maybe it's not the perfect person but it's a perfect fit on this team because of personalities, and principles and values, that you know, even if they don't even become that perfect person that I was looking for, there's still going to be a valuable contributor to that team. So, there's-Gary Vaynerchuk says, what the- “hire fast, fire faster, promote fastest.” and I'm not a huge advocate of the latter two, but definitely the team model open-widens the aperture to find the right fit for a team as opposed to looking for the right fit on this particular project or this particular role. And like I said, then the equation ends up being your team has this growth mindset, all your teams have this growth mindset, they're continually sourcing and growing good fits for their team, in context of knowing that shared vision of the CEO because they're so-they're not so far removed. They can keep growing. And then when the opportunity pops up, it comes into a Kanban board and we say hey teams, who's got somebody or who-which team has a couple of T shaped skills that would fit this unicorn that's being asked for. And maybe instead of one body, we have three people that charge down to the equivalent of a full-time engineer, because there's not one unicorn that's got five years Kubernetes, ten years AWS, TS/SCI clearance, right? Like, we have, on the team, there's a TS/SCI cleared systems-software systems engineer, someone in an AWS SRE expert, and CKID, who's, you know, got a lot of hands on experience with Kubernetes, the team can-can fill that role of a unicorn a lot better than an individual can.
Dan: [34:00-35:15] Since we have a little sports theme going in this particular pod, what I see great sports organizations do is, in you know, in sports, there's a draft, so you're like usually drafting let's say, college players, or you know, someone from the minor leagues, you only get one first round pick. And that's where you can find someone usually with all these talents. But that's not all the talents that you need. Like you were saying they have all three of them, they know everything. But the most of your picks are people that do not have everything at once. So, the organizations that I see are doing really well is they're finding people that have the ability to improve the fastest. Do they have a growth mindset? They can take training, they can be twice as good next year as they were the year before. So, let's just one thing for everyone to think about when hiring’s really tough, you know, look-look for up and comers that can improve that's actually probably the most important thing. One of our last time topics here, so a lot of like our guests that come on the show they have a background in startups. In some aspects you do, too. So if I said that the work you do for the government was kinda like building a startup for three-hundred and fifty-million people, how would you respond to that?
Bob: [35:16-36:55] Yeah. So, it's-it's the model that I think we need for the federal government to succeed and to start being as agile and nimble as the current challenges that face government and us as citizens and kind of consumers of the government's product, for lack of a better term, demand and require us to have that kind of nimble startup mindset. Where I see the organization within SAIC and SAIC and others like us that are starting to embrace this mentality. There's been a historical challenge of connecting commercial results out of Silicon Valley with the federal government, because just by nature of, you know, we'll say the laws and regulations of the way the federal government does its budgeting and funding, eighteen-month funding cycles don't really jive with, you know, a series A funding revenue raise. And in Silicon Valley, you'd be like, “well, I'll get money eighteen months from now, I promise.” right? like, and so there's always been this really challenging disconnect. And there's been a lot of cool effort in the federal government to engage better with Silicon Valley. But I think, a more pragmatic bridge to close that gap is for the federal system integrators, who have always supported federal government to start behaving and shaping more likely startup would, you know, to the Team of Teams model being directly tied to a mission and purpose, being able to pivot and persevere with pivot and try a new business model if something's not working. So that that's where I see kind of my responsibility within SAIC, in my-the part I play in helping the federal government act and feel more like a startup is really pushing federal system integrators to look and feel more like a software startup.
Dan: [36:46-37:15] I may have an outdated view on this. So hopefully, I don't say something wrong. But usually when I think about the government-federal government it’s like, I think of that-their style being outdated or slow or like not where the-I don’t know, like the coolest, newest practices are happening. Do you agree or disagree with that?
Bob: [37:16-38:01] So I’d say, especially in the last, we'll say, five to ten years, and really, pockets of Department of Homeland Security and then really broadly across the DOD and IC, I've seen them really embrace and adopt a more of a product mindset, which is starting to challenge and upset the status quo, even at the top level. So, you have folks like Paul Puckett at the AECMO for the US Army, Jay Bazzi and Lauren Knausenberger at US Air Force, who are really pushing, you know, changes and updates and policy to start to enable that on their side. There are certainly, you know, muscle movements we can do on our side to help enable that and accelerate that but yeah, you're absolutely right. A lot of that change does have to originate from the government itself.
Dan: [38:02-38:28] But then I guess like on the flip side, what I'm saying is, I know-like I read some things from your website, some of the most interesting projects, I think, are happening in the government at the same time, like this is like super interesting stuff. I don't even know what it fully means. But coordinating all these planes or battle tactics in real time and whatever that's like. So, the project space is-seems like really cool to me.
Bob: [38:29-39:51] Yeah. And then the kind of technology exposure there and the opportunity. And again, it's a natural kind of draw from opportunity and engagement for folks who are really trying to be on the cutting edge from a technology standpoint, especially IT and OT convergence. So where, where does software, meet wearables, meet data connectivity in austere locations, like how do you handle those. Like IOT, you know, having a smart thermostat is one thing, if I'm going to try and do Internet of Battlefield things, how am I going to equip a soldier? Or how am I going to, you know, in a clandestine way, right? Because we can't turn them all into homing beacons for enemy threats. But there's a lot of taking commercial problems, transposing that over the historical battlespace that, say the DoD or the IC or the federal government and reimagining getting back to first principles design thinking. So, you're spot on, a lot of it might seem like it is a very historically jargon driven world, in the federal government, but the technology and landscape the best analogy you could give is the financial and FinTech world, right? The-the types of technologies that are pushing FinTech forward is exactly what the federal government is investing in. And because it's the same problem with the added layer of having to do with afloat or in space, or, you know, in a mountain range somewhere in in Asia.
Dan: [39:52-40:03] Yeah, a lot of innovation going on in that space. So, we're coming kind of towards the end here. What's the most interesting, I guess, project that you're working on at SAIC, that you could talk about, what are the cool stuff you're doing?
Bob: [40:04-41:28] Well, so the work we're doing, I guess, with the Air Force, the Department of Defense in the cloud and DevSecOps space. I have the privilege of being the community practice leader for Air Force Cloud One program, which is the given my kind of values and principles on continual learning and really growing and democratizing knowledge across the entire defense industrial base, it's been an incredible privilege to be a part of the Cloud One program, because we engage with hundreds of vendors, larges and smalls in this defense space, that are all trying to solve a wide variety. Some are mission systems, some are business systems, some are trying to do research and development on new, like some of the new kind of exclusive problem sets of downrange and more-I guess, what's the best way I can put it? Multi-layered security, multi-level security of data interoperability, so the ability to not only function better as a business, you know, the military being still- right, the military has HR, military has budgets, and finance, they have all those same business systems they need to maintain. So, there's that aspect. But the difference is those dimensions; HR, training, and learning and finance, directly impact our ability to defend and prevent and fight war if necessary. And so, it's kind of an exclusive problem set. And it's just a really cool space to be in right now. Given some of the thought leaders in DOD.
Dan: [41:29-41:39] Awesome. Thanks for sharing a bit about what's going on. Last question was more of a fun question. Would you rather be a teacher or an entertainer?
Bob: [41:40-42:22] So-so for me, that's a kind of an easy answer. My mom's a teacher after-after Marine Corp, my wife's a teacher. I always tell people; I would be a teacher if it paid better. I know that sounds like a shallow response. But my real joy is learning a bunch of new things, and then teaching people a bunch of new things. And so that's where I kind of am drawn to that Team of Team's model still is the opportunity to continually learn myself, share my learnings with my teams, they do the same there share their learnings with me. So yeah, teacher hands down. My dream job would be to be a teacher. If I ever can overcome my own personal woes and mismanagement of my own personal finances and get to an independent wealth point, then I will definitely retire and become a teacher.
Dan: [41:23-43:00] Yeah, it's, it's hard to say that you don't want to be a teacher after listening to this pod, as we've been talking about, you can kind of level up so many people, you can be a teacher, both, you know, in the traditional education aspect, but also for your team make everybody better. So, I'd have to say as of right now, I'd want to be a teacher and too-too introverted to be an entertainer, let's-let's go help everybody improve. Bob, I know that you are doing some hiring. If people that are listening want to checkout a job opportunity to work for you or work on one of your Team of Teams. How can they do that?
Bob: [43:01-43:38] Yeah, definitely. So, if you check out the career and job opportunities at saic.com. Anything that strikes your fancy there, feel free to reach out to me on LinkedIn, I pretty actively check in on LinkedIn or, you know, if there's a Slack group that you want to invite me to on LinkedIn, I also like to collaborate in a lot of different Slack workspaces, just to try and stay in touch with the community. So, love to connect any-any and all avenues there. But yeah, we're constantly looking to grow our team model. I can guarantee you if it's not Silence of the Lambdas or Insane Cloud Posse, there's a team we have here for you that's the right fit.
[Music fades in]
Dan: [43:39-44:20] Cool. So yeah, check out Bob Ritchie on LinkedIn. We'll post the links in the career pages and, and all of that. Also, a quick reminder for our listeners if you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple podcasts, please do so. Reviews are a crucial way that our show gets discovered. Also, be sure to join the Dev Interrupted Discord community. That's where we keep this type of conversation going all week long and also our first look at the Interact 2.0 conference on April 7th 2022. Again, we have all the links in the description below and catch you all next week. And Bob, thank you again for coming on.
Bob: [44:21-44:22] Thanks so much Dan. Take care.
[Music fades out]