• Please take a moment and update your account profile. If you have an updated account profile with basic information on why you are on Air Warriors it will help other people respond to your posts. How do you update your profile you ask?

    Go here:

    Edit Account Details and Profile

Vet hiring and the civ/mil divide: in which nittany03 threadjacks a threadjack

nittany03

Recovering NFO. Herder of Programmers.
pilot
None
Super Moderator
Contributor
What @nittany03 said +1 about military background, scrum/agile, and everything. I ran the early career recruiting and programs team for an enterprise cloud software company. We actually did hire some junior developers and software engineers out of bootcamps. What set them apart from the pack and allowed them to compete with the CS majors from Michigan, Harvey Mudd, and Berkeley was that they had real-world project experience on teams and they could show their work (or parts of it) on platforms like GitHub.
I also have seen bootcampers get hired up against CS grads when they are the personality type who is humble and can ask for help, and assertive enough to do it (think CRM). Meanwhile, the fresh-faced CS grad is asked about strengths and weaknesses and says something like "it's tough for me to ask for help; I just press on." Yeah, props for honesty, but when it's a day from the end of the iteration, and we can't QA approve your work item because you should have asked for help three days ago, well . . . caw caw.
 

AllAmerican75

FUBIJAR
None
Contributor
What do you want to use it for? I was a PM of a 50+ person, $12M cyber program.

BT BT

I am an 1835 reservist with only a couple hundred days on actual paid duty, and I still get the civilian colleagues telling me “Well you’re military so just do it like the military way” for whatever task or project is at hand. Ok boss. I’ll do it the military way like you said... which is just me drawing on experiences of me and a couple dozen other civilians (with normal but impressive day jobs) who pretend to be in the Navy one weekend a month, two weeks a year.
Yeah, having the gold standard in what the private sector refers to as Agile, which is the primary way software teams deliver value. Mil aviation and combat arms types are well familiar with the whole plan-brief-execute-debrief cycle that Scrum is essentially based on, and Scrum is the most common way of implementing an Agile mindset. Go figure, one of the people who developed Scrum was an Air Force F-4 pilot. My personal view is if you're a competent fleet aviator and you're willing to get your geek on and learn software, you can crush it as a Scrum Master and then decide where in the industry you want to go.

That said, bootcampers are generally at a disadvantage applying to straight-stick developer roles behind folks with a 4-year CS or CompEng degree. It's not impossible to overcome, but you're just not going to be able to get the same level of immersion in 4 months as 4 years. It's not just being about to write "Hello, world" or a basic script; it's being able to write (relatively) bug-free code that does the job and does it efficiently. Scalability is a thing; what happens when that code you wrote gets run tens, hundreds, thousands, hell, maybe tens of thousands of times in rapid succession? That's where the CS math geekery comes in.

Plus, depending on the shop, you may be responsible for the test automation of your own code, too; some shops don't have dedicated developers in test anymore. So now you need to understand how continuous integration/continuous delivery pipelines work, what test coverage is, and what needs to be hit in unit, regression, and integration tests. And make intelligent decisions about what gets tested when.

It's a whole nother industry, and in less than three years I've learned a shit-ton. Smart aviators with enough CS chops can thrive here. But I would highly recommend figuring out what your planned entry point is. Scrum Master? Product Owner? Junior developer? Then take the classes that will get you there. If you don't have a CS background, a tech bootcamp will at a minimum get you enough CS stink on you to be able to look at developer-adjacent roles, junior dev roles, or possibly junior QA/software tester roles at places that still make that distinction.

Manifesto for Agile Software Development
The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game
Spotify Engineering Culture - Part 1
Spotify Engineering Culture - Part 2
What @nittany03 said +1 about military background, scrum/agile, and everything. I ran the early career recruiting and programs team for an enterprise cloud software company. We actually did hire some junior developers and software engineers out of bootcamps. What set them apart from the pack and allowed them to compete with the CS majors from Michigan, Harvey Mudd, and Berkeley was that they had real-world project experience on teams and they could show their work (or parts of it) on platforms like GitHub. They had built stuff like grocery delivery time optimization programs or free games that people actually played and generated ad revenue. It can be done, but you gotta “speak the language” so you can make it through multiple rounds of technical interviews (now virtual) and also come across as someone the interviewer wants to spend time with (see the “McKinsey airport test”).

Since I'm about to go manage IT types doing development, what do you guys consider to be the keys to success for managing civilians coders and developers? It'll be my first time leading civilians which I'm sure is going to be very different from leading Sailors.
 

nittany03

Recovering NFO. Herder of Programmers.
pilot
None
Super Moderator
Contributor
Since I'm about to go manage IT types doing development, what do you guys consider to be the keys to success for managing civilians coders and developers? It'll be my first time leading civilians which I'm sure is going to be very different from leading Sailors.
As in being their line manager? Project manager? Scrum Master? All very different things . . . and the last two arguably aren't "management" roles in the sense of supervisory authority. Especially not a Scrum Master/Agile Coach.
 

PhrogLoop

Adulting is hard
pilot
Since I'm about to go manage IT types doing development, what do you guys consider to be the keys to success for managing civilians coders and developers? It'll be my first time leading civilians which I'm sure is going to be very different from leading Sailors.
Think of them as engineers. They’re direct and literal when talking business. They’re super efficient with their time and want to know exactly what’s expected of them and when. Which is not to suggest micromanagement. It’s more that they need to know your priorities, deliverables, and timeline so they can manage their workload and deliver.
 

AllAmerican75

FUBIJAR
None
Contributor
As in being their line manager? Project manager? Scrum Master? All very different things . . . and the last two arguably aren't "management" roles in the sense of supervisory authority. Especially not a Scrum Master/Agile Coach.

Most likely I'll be in a project or program management role.
 

Hair Warrior

Well-Known Member
Contributor
Since I'm about to go manage IT types doing development, what do you guys consider to be the keys to success for managing civilians coders and developers? It'll be my first time leading civilians which I'm sure is going to be very different from leading Sailors.
Most likely I'll be in a project or program management role.
The variety of "IT project/program management" that exists in the private sector is like saying "I am aircrew" and applying it to an F/A-18E, C-5, MH-60 AIRR, 727, Cessna, a hang glider, or a flight attendant for a commercial airline.

That said, keys to success are similar to the Navy: cover & move (communicate), keep things simple, prioritize & execute, decentralized command

Agile-Scrum (I am a CSM) actually uses all four of those concepts, although people would stare blankly if you told them in that terminology. At its core, Agile-Scrum enables a team to self-organize around a shared view of the problem set, which is displayed as a kanban board and communicated through daily standups, self-prioritize the work activities, and execute independently.

Personal note: I actually find many civilians (non prior service) who are short-tempered, "do it my way because I said so" micromanagers, unwilling to cover & move, back-stabby in their intent, or otherwise not team players.
 

mmx1

Woof!
pilot
Contributor
Nittany how was the tech boot camp experience? Strongly considering getting out and was considering going to a coding boot camp. Any benefits coming from a military / aviation background?

Experience counts. Boot camp is a helpful introduction to the basic tools that you can leverage to figure out next steps, whether that's building something more complex as a developer, or slotting into an enabler role like Scrum Master. But it's still just 4/6/however many months. A CS 4-year major maybe has 2 years equivalent of in-depth development from classes alone; and I think their advantage is mostly from that. Side projects introduce a lot more variance. There are a lot of quality online tutorials, so if you have the time and gumption, building something as a side project is another way to build experience and resume fodder.

I got out, used GI Bill to fund 18 months of a MS in CS where I took all classes and coded as much as I could. Hired from school into an engineering role at a FAANG.

Having been here for a few years, I'd say that Engineering Program Managers have a lot of overlap with good staff work. They manage programs and projects, not people, pulling together inputs from multiple teams to ship products on time. Role and titles vary from company to company in what is a PM / EPM. I work with a fantastic EPM who was an enlisted Marine; I know of another great one who was a Navy Intel O.
 

nittany03

Recovering NFO. Herder of Programmers.
pilot
None
Super Moderator
Contributor
Most likely I'll be in a project or program management role.
Meant to give this more of a response, so here we go. @Hair Warrior hit it on the head in that "project management" and "program management" can mean many things depending on where you work. I am by title a "Project Manager," mainly because my company is in transition and title/role changes require CIO approval for whatever reason. If you ask me what I "do," I am a Scrum Master/Agile Coach by trade. The dichotomy here is between old-style "waterfall" and modern "Agile" ways of delivering software.

The old style is defined by the Project Management Institute's PMBOK or Project Management Body of Knowledge. It assumes that you can and should make software the same way engineers build a bridge or a power plant. First, collect requirements. Then, design it. Then, build it. Then, test what you built. Then, turn it over. These things come in phases, hence the "waterfall." This is the realm where detailed requirements document R leads to detailed instructions to the devs to build X, which lead to detailed instructions to the testers to ensure that when the devs built X, it complies with R. This worked fine when the end goal was to put a software application on a CD, shrink wrap it in a box, put it in a store, and have someone buy it. Then you move on to the next application that took three years to develop. Think Windows 3.11, 95, 98, XP, Vista, and so on. No one worth their credibility, except maybe the government, can afford to work this inefficiently now. Even very highly regulated industries like medical software are trying to move to Agile, or at least incorporate what makes sense.

Agile realizes a few things, and I'm going to assume you read what I linked above. First, the customer doesn't really know what they want until they see it demoed to them. Second, long-range plans will change once you show stuff to a customer for the first time. And the second time. And the third, fourth, and so on until it's done. It's a dialog. Customers learn, you learn, the market changes, and the world changes. Third, if you go back to the Toyota Production System, apply empirical process control theory from Lean, and trust your devs to estimate honestly, you can get a good handle on how much stuff your devs can deliver in a given amount of time. And by "deliver," I mean take a small subset of the business requirements that's most important at the time, understand what it means, code it, test it, and demo it to a rep of the customer who can tell you if you are or aren't on the right track. Then you just iterate over and over, demoing to the customer or their rep, until they say "enough, that's good enough for what we need."

So the old style is to have a project manager who gets given requirements and a team, writes a project charter and has it approved, and then creates a waterfall-style work breakdown structure to deliver a given scope to meet that three year deadline within the given budget (Google the Iron Triangle of project management: Scope, Schedule, Cost). Even though the world could change between now and then. When the world changes, the PM works with a change control bureaucracy to update the maze of documents to account for the new plan. It's considered a success by PMI if the project meets its LAST known constraints of scope/schedule/cost, even if those have ballooned to shit since kickoff, as long as the proper bureaucrats approved the changes to the Project Plan.

Scrum plans in one- to four-week iterations, and is the most common way of doing Agile in software (there are others, and the minutiae and pros/cons of each are prone to set off Internet religious wars among Agilists). The development team alone has final say on how much work they can get done in an iteration. The Product Owner (who represents the customer) has final say on what the most important work to be done next is. The Scrum Master is the referee and process guru, as well as the person who goes outside the team to resolve blocking issues that are keeping the dev team from being able to get done what they said they would in a given iteration. The Scrum Master keeps the dev team from sandbagging, the PO from crushing the dev team, and everyone involved in continuous improvement; we're kind of like the NATOPS model manager of the team.

So as a "project manager" you could be anywhere on a continuum between traditional PM or Scrum Master. God knows there's enough hosed-up Agile implementations out there that try to half-ass it. Program managers in their traditional role are managing groups of related projects, so they're basically the PM of some PMs. In more Agile environments, they could be a Scrum Master equivalent for multiple Scrum teams, which goes by various titles, but is again a process coach, mentor, sounding board, servant leader and remover of blockers, not someone with decision-making authority.

Old-style project managers will have authority to sign off on changes for scope, schedule, and cost, maybe with approval of a project sponsor who is a senior manager. Agile folks deliberately do not. Because their goal is to be a coach and process improver, not a decision maker. Neither of these people ever tend to be line managers who write peoples' performance evaluations, have hiring/firing authority, or salary authority.

More to follow on working with devs when I get to it. Spoiler alert: they're definitely not all socially-inept neckbeards who stink.
 
Last edited:

nittany03

Recovering NFO. Herder of Programmers.
pilot
None
Super Moderator
Contributor
Having been here for a few years, I'd say that Engineering Program Managers have a lot of overlap with good staff work. They manage programs and projects, not people, pulling together inputs from multiple teams to ship products on time. Role and titles vary from company to company in what is a PM / EPM. I work with a fantastic EPM who was an enlisted Marine; I know of another great one who was a Navy Intel O.
I saw the FAANG in your post as I was about to ask if you were a Microsoft type. Never mind. :) I know their PMs are really Product Owners to the rest of the world, and I know MS DevDiv rolled their own Agile implementation based on three-week iterations.

Just curious, what was your undergrad degree before you got the MS? Trying to figure out what my next play is, but the MS in CS route always made me worry I'd get laughed out of the room without a BS in CS to bring to the table . . .
 

Hair Warrior

Well-Known Member
Contributor
A lot of IT work in the government space requires PMBOK, Agile Scrum, and a healthy dose of MacGuyver tape. The PMBOK is used for the CDRLs, burn plans, etc. and the devs use Scrum. The program typically relies on both - but usually only a couple hinge level managers who have to work in both (I'm one of them) which can suck. There are of course workflow tools (e.g. Atlassian suite) for all this shit, and they carry their own learning curve.

I've seen times where, if the project is small enough, just put your best dev lead on it and he'll start and finish it over a weekend, without any of that management stuff. That was for a working MA system from zero to badass.
 
That's like the the old wives' tale of "you've got a security clearance and you're TACAIR; you shouldn't settle for less than six figures on the outside!" Uhh . . . guess what? That happens if you're a senior O-5 or O-6 whose transition plan is to parlay your metaphorical Rolodex into a lobbying job for the military-industrial complex. Or if your skillset just happens to translate directly into civilian terms, a la the so-called Show. Otherwise, you're just another dude or chick who's switching industries, which almost always means a step back in seniority to get your foot in the door. And it's on you to pitch your experience to a recruiter and hiring manager who in all likelihood know precisely dick about the military. Most civilians don't. Doesn't mean they're bad people.

I came off my MOB, took a 4-month tech bootcamp as a refresher, and applied to 33 jobs before I got the interview that led to the offer for the company I work at now. By the time the offer was formalized and I quit my job hunt, I'd applied to 81 jobs. Any winged aviator worth their salt has the skillset to crush it in the private sector, but if you think the private sector understands that, I've got a bridge in Brooklyn to sell you. The hard part is the initial hop to get the civilian stink on you, so next time you can condense all those "US Navy" resume bullets to like four vague lines, and punch up your civilian experience. Hard truth after fighting and sacrificing for gold wings few civilians could ever so much as smell, but it is what it is . . .

There is a “read and heed” detail in here and this a super awesome point. I’m lucky enough now to have hired a lot of people on CIV side, which means interviewing hundreds.

It just stands out so clearly that some approach the process as “I present you... ME” and others focus on the company, how they plan to add value, what appeals to them about it, etc. The ones hired are the ones who present themselves with the humility of a JG in their first fleet squadron. NOT necessarily the ones with this or that skill... it’s majority OJT everywhere you go.

The applying you describe, standard fare. It makes some cynical and they even mention it during interviews. No don’t do that. The system is what it is... employers have all these millennials quitting, they are growing in spurts and the financial models change on a dime. It’s in their best interest to have a pool of people.

1,000%: getting foot in the door is a real thing. Companies hate hiring. So much. It’s the worst part of every managers job for many reasons (people can fool you, they’re always at dynamic place in their lives, you always feel like a perfect fit is right around the corner, you’re worried about losing the headcount, it’s a massive, massive commitment every time in training, etc). But when you’re in—- promotions are not like the military. The company actually wants you to move up rapidly if you’re willing to make those trade offs. Faster the better. #1 talent pool is 0-2 years with the company: who are the horses? If the manager says there is a path with the role (ie it’s not “front desk”) you never ever turn that down at a great company.

My 2 cents only.
 
There is a “read and heed” detail in here and this a super awesome point. I’m lucky enough now to have hired a lot of people on CIV side, which means interviewing hundreds.

It just stands out so clearly that some approach the process as “I present you... ME” and others focus on the company, how they plan to add value, what appeals to them about it, etc. The ones hired are the ones who present themselves with the humility of a JG in their first fleet squadron. NOT necessarily the ones with this or that skill... it’s majority OJT everywhere you go.

The applying you describe, standard fare. It makes some cynical and they even mention it during interviews. No don’t do that. The system is what it is... employers have all these millennials quitting, they are growing in spurts and the financial models change on a dime. It’s in their best interest to have a pool of people.

1,000%: getting foot in the door is a real thing. Companies hate hiring. So much. It’s the worst part of every managers job for many reasons (people can fool you, they’re always at dynamic place in their lives, you always feel like a perfect fit is right around the corner, you’re worried about losing the headcount, it’s a massive, massive commitment every time in training, etc). But when you’re in—- promotions are not like the military. The company actually wants you to move up rapidly if you’re willing to make those trade offs. Faster the better. #1 talent pool is 0-2 years with the company: who are the horses? If the manager says there is a path with the role (ie it’s not “front desk”) you never ever turn that down at a great company.

My 2 cents only.

Two additional points I meant to make (there may be better threads for this but I logged in by accident due to a new password aggregator service and saw this at the top of the feed).

1- The way they evaluate hiring managers is In your first civilian job is based on how they hire. You and your hiring is a big part of your manager’s career: career defining actually. Managing is less care-and-feeding as in MIL and more based on how you evaluate talent. If taking a chance on someone in their first civilian job, if they read that wrong, it’s #1 indicator they don’t have what it takes to be executive. Like: a diversity candidate that rapidly promotes can truly make a career. So worth realizing that the person interviewing you has a ton at stake. They want the upside you can bring if you can position it that way.

2- Mid Managers at the company w some tenure literally have the same pride as we do about wings, relative to their little designations. So being a member of RLT regional leadership team or the equivalent is like the same pride as you have in actc L5, or whatever. Just like wearing the patch. Play that up, pretend to care and learn that lingo.
 

Hair Warrior

Well-Known Member
Contributor
1- The way they evaluate hiring managers is In your first civilian job is based on how they hire. You and your hiring is a big part of your manager’s career: career defining actually. Managing is less care-and-feeding as in MIL and more based on how you evaluate talent. If taking a chance on someone in their first civilian job, if they read that wrong, it’s #1 indicator they don’t have what it takes to be executive. Like: a diversity candidate that rapidly promotes can truly make a career. So worth realizing that the person interviewing you has a ton at stake. They want the upside you can bring if you can position it that way.
This is totally dependent on the company culture and situation you are joining.

My company has rapid growth, tons of vacancies, and a self-starter attitude. Most teams (except my previous one) in this company throw you in the fire along with half a dozen others also getting thrown in the fire. Your job is to play nice, help others, and do expert level work with minimal oversight.

The company knows that a few people will wash out, and if you wash out, they will assume it's you and not your boss (bc your boss has 30+ other people he or she has hired in the past year, and >90% seem to be doing just fine). I find that military vets generally do well in this big, fast-growing environment. If you join a much smaller, more stagnant team, you could get caught up in some minutiae and bullshit of small-office politics.
 
Top