Everybody’s doing year in review posts, and I feel like I should do one too. Career-wise, though, it doesn’t make much sense unless I also review the last seven years or so. So buckle up, because that’s a thing you have to do when reading a lot of words.
Part 1: Who did you work for?
I spent the last 7 years working for the US Coast Guard. Not directly, though, because I was a contractor. Astute readers might point out that I live in West Virginia, a land locked state, and be wondering why there’s a Coast Guard presence there. One might guess: “rivers, duh!”, but I also don’t live near any very navigable waterways. You can kayak in the Potomac, but it’s probably too shallow for a cutter. The real answer is that the late Senator Robert C. Byrd brought a lot of government IT projects to West Virginia, one of which is the US Coast Guard Operations Systems Center, or OSC.
Technically, the OSC is a military base, but it’s not what you think of when you think of a military base. It’s more like a set of office buildings (that the government actually rents instead of owning) that happen to contain military personnel. In Coast Guard terms, it’s a “command”, headed by a CO, who is literally a Captain. The function of the OSC, in broad strokes, is hosting and maintaining (and sometimes developing or enhancing) IT services for use by other commands, and sometimes other government entities. The business term for what OSC does is ITSM.
There are two command structures at OSC: the government personnel, who report to the Captain through a hierarchy (some of them are active duty, some of them civilian government employees); and the contractors, who report, through a hierarchy, to the head contractor on their particular contract (I forget the title they use for this), who ultimately reports to someone at the contractors’ company’s corporate headquarters. We used the word “contractor”, but really it’s our respective employers who were contractors. The freelancing term for what we were, I gather, is “permatemps”. The “temp” part of that word is a little misleading, though. We had benefits and probably about the same amount of job security as one would have working for your average large corporation, in a real sense. But that job security didn’t exist in a technical sense, due to “recompetes”.
I don’t know what’s typical for government contracting, but the way it worked at this command is that a contract would be for a set period of time, often with option periods and bridge contracts that could extend it. All told, the contract would last about five years. The kind of company that could compete for this contract is called an 8(a), usually a relatively small company at the time the contract is awarded. That company could subcontract to other companies, and these tended to be bigger ones you may have heard of. My impression was that this was done to mitigate risk, or allow it to staff up quickly if necessary. If subs were used (which they were up until about a year ago), a given employee had about an equal chance of being employed by the primary or one of the subs. At the end of this contract period, the contract was up for a recompete, which means another 8(a) would take it over. By this point, the primary has usually grown beyond 8(a) status, but sometimes will get back on as a sub.
When the contract period ends, technically all contractors are laid off. However, most of them will typically be laid off on Friday (with months of advance warning) and work for the new primary or sub on Monday, doing the same job for the same boss (who is in the same non-literal boat). They’ll have had the opportunity to apply for their new old job, but mostly everyone gets re-hired if they’re in good standing as an employee. There are, of course, no guarantees that the new company will do things this way, but, in the one recompete I went through, folks who had been there through several didn’t seem worried.
Up until the reorg a couple years ago, a leaf-level team in the contractor hierarchy was called a business unit, or business system (though the latter also referred to the set of software applications that the team was responsible for). In my case, this was a cross-functional team consisting of 2-5 developers, 2 sysadmins, 2-3 DBAs, sometimes an intern, an admin/secretarial person (Functional Analyst was the job title), a tester we shared with one other team, and the project manager who was also our line manager. In our environment, things seemed to go best when we followed a spiral model of software development, as it lined up with how the customer liked to plan, approve, and evaluate projects, and how people like to have long-but-not-too-long term goals they can be working toward. Scrum, on the other hand, seemed to work pretty disastrously, but that’s just my subjective opinion (*sips tea*).
Several project managers reported to a portfolio manager (in the contractor hierarchy), but each was also the main person responsible for interfacing with a Project Officer (later called an Application Line Manager), who was a leaf node in the government hierarchy, responsible for making sure the contractor met the requirements of the business system’s “program” (a program being an ongoing, funded initiative spanning multiple commands, that reports to a program office at Headquarters). For example, the business system I worked on was called NAIS, which was part of the NAIS program, and I would have said to other OSC folks that I was on the “NAIS team” or “NAIS system”. But other commands (located in other states) also had “NAIS teams” that were part of the NAIS program. So, to these NAIS folks at other commands, my team was OSC, and their team was $NAME_OF_COMMAND. And there were other teams at OSC (a couple being LRIT and Amver), which were similarly part of programs spanning multiple commands.
I don’t know how long the reorganization was in the works, but for the leaf-node contractors it started to take effect a couple years ago. It wasn’t part of a recompete; instead it was entirely within the tenure of one primary contractor. From what I can tell, the end goal of the reorg was to transition the contractor staff and processes into “Service Lines” according to the ITIL methodology. ITIL ya what! (sorry), it wasn’t very popular with leaf-node contractor staff, but for all I know it may have met (or been on track to meet) its business goals, which according to the all-hands meetings had something to do with responsiveness to customer requests.
These service lines were things like Engineering, Sustainment Operations, Project Management, Quality Control, Business Analysis, and Application Security, and were subdivided into Delivery Groups. For example, the Engineering Service Line (ESL) was divided into the Architecture and Design (A&D), Microsoft, and Non-Microsoft delivery groups, each headed by a delivery manager (DM), whom the leaf-node employees would then report to. (A couple opportunities for D&D puns there, which usually went to waste.) I was in the Non-Microsoft DG, which meant that I was mostly supposed to do Java, and didn’t need Microsoft tools on my workstation; but, due to the requirements of the NAIS system, I had Visual Studio anyway, and worked in an alphabet soup of languages (Python when I could get away with it). I reported to the Non-Microsoft delivery manager, but because the requirements of the business systems didn’t just go away, I mostly still had to go to meetings with and do the bidding of the NAIS project manager, much more often than the DM. I gather that it’s common to have different people be your engineering/line manager and project manager. At my previous (non-government) job, there were separate engineering (there called R&D) and product managers, the latter being whose bidding we mostly had to do. At OSC, though, this was a fairly new thing. But that structure was disrupted around the beginning of this year.
See, the Coast Guard straddles the line between the Department of Homeland Security and the Department of Defense. As a result of getting new security requirements imposed by the DoD, a major initiative was undertaken that amounted to not only a temporary reorg, but also temporarily changed job responsibilities for a lot of people. We still reported to our DMs, but our regular business system related work was halted, and we were put on new “Cross Feature Teams”, spanning multiple business systems. These were headed by project managers, and followed the Scrum methodology, which worked okay for the lot-of-little-things non-development work we were doing. There was some interesting stuff (I got to do some stuff that would ordinarily fall to sysadmins, and poke around in a system other than NAIS some of the time), but again this was not very popular with the leaf node employees. Around August-September this security initiative work was winding down, but Scrum had gained a foothold and would be the new order of things moving forward. For unrelated reasons to be covered later, I left at the end of September.
All of which is to say that my resume line item for 2009-2016 is a little complicated.
I’ve decided it’s good to write blog posts in a single sitting, so I’ll wrap it up there for now. Tune in next time for Part 2: What Did You Work On?
Edit: I realized I didn’t mention the contracting companies’ names, which is one common interpretation of the question “Who did you work for?”. In that sense, the companies were Stanley Associates (for about a year and a half) and DMI (for about six years). A truer answer would probably be OSC, as it’s a quasi-organization in itself, and the organizational structure and norms belong more to OSC than any individual company running it. That phenomenon is probably worth a blog post in itself.