For those who don't know: "18F is a digital services agency built on the lean startup model based within the United States federal government." (wikipedia)
I spent 15 minutes trying to figure this out the last time they popped up on HN. It's surprising to me how difficult this was to find out. I think it was buried in a FAQ somewhere.
The USDS is part of the White House. They are directly under the President.
18F is basically a contracting agency, run by and for the government. They basically take on work that's assigned to them by the USDS. The USDS does work as well, but typically more with a leadership and policy role.
Quick clarification. 18F is not assigned work by USDS. Federal agencies come to 18F with proposed projects and then 18F chooses which ones it works on based on staffing/scope/impact etc.
What is it like working for 18F? Office space, flexibility of hours, commute, workstation, work attire, etc? Would someone who prefers the startup atmosphere survive for long?
I love it. We have a distributed team so many people work from home and then we have offices inside GSA buildings in SF, Chicago, NYC, and DC. Hours are very flexible, we just try to have some overlap with teams in various time zones. In D.C., where I am, some people work 10-6, some noon-8, and some take breaks to pick up kids from school and then work at night. Attire is very relaxed. The kind of place where if someone wears a suit you ask what they have to do that day. We're a Mac shop, which is pretty rare in the government. No real software restrictions, and we provide most of our own IT/ops support. I'm working from the roof of the GSA building right now. View of the Washington and Jefferson monuments is hard to beat.
Morale is really high. Culture and work/life balance is super important to the team and to management. People feel compelled to tweet about how much they like their job. I haven't worked at a startup, but many have and are happy to be here. There are plenty of government frustrations, but the size of the impact of our mission greatly outweighs any day to day annoyances. For me, the best thing is that when there is a problem, whether it's management, bureaucracy, or technology, the attitude is to address it openly and head on. And 18F has a group of really smart people, so those problems rarely last very long.
I work from my home outside of Chapel Hill, NC so my commute is from my bedroom to my home office. I'm in a t-shirt and yoga pants right now.
It's the best job I've had - I have autonomy, flexibility, and the ability to make an impact on a daily basis. It's really nice to think about how many people you reach on a daily basis. The problems you get to work on are challenging and complex - I'm learning new things every day.
I came from the journalism world, not a startup - so I can't speak to whether it's similar. I will say this: We have a "Yes, how can I help you do that?" philosophy, which I find refreshing and really delightful.
For example, right now I'm working on an onboarding Slack bot (code: https://github.com/18F/dolores-landingham-bot) that will help acclimate new employees to 18F. Got the idea. Threw it around. Everyone liked it. We're building it. And then we plan to write up how we did it, so others can use it too.
That's the best feeling - sharing what you learn, and not being afraid to go public with every bit. Happy to say more.
As I understand it, 18F started off as part of USDS. But the Obama administration wanted the program to outlive his tenure as POTUS, so they tucked 18F into the GSA.
That's not correct. 18F predates USDS by about a year, and we are (and always have been) independent of each other, though there is a lot of cross-pollination in our work.
Was talking to a Presidential Innovation Fellow, and probably just misunderstood what they were saying, or perhaps the Fellow had incorrect information.
I wouldn't say it's a philosophical difference. We're definitely tackling the problem in two different ways, but that's not because either group thinks the other is wrong, it's because this is a big problem that requires attacking it from many angles.
I hope I'm not the only one who thought the headline was someone trying to be hip while saying 18 year old female. (Dr Evil: I'm hip, I'm cool. I'm with it!)
Interesting to see Cloud Foundry take off this year after many years of being more of a curiosity on its own island.
I personally didn't get it until I saw Docker a couple of years ago and wondered "how will we operate all of these apps, services or even the servers they run on without playing yet another shell game and resorting back to traditional shit IT?". And that brought me back to Cloud Foundry and BOSH, to the point where I quit my old job and joined Pivotal.
This is a huge validation of everything we've been saying and working on at Pivotal. In order to be successful at running software at scale you need your operations to get out of your way as a developer, and you need tools and architecture that make being an operator painless.
That's the goal with CF and Bosh, and it's clear that it pays off.
Pivotal Web Services - Run.pivotal.io - is the CF equivalent to Heroku. Documentation is at docs.run.pivotal.io. IBM has one at Bluemix.net as well.
CF is very good if you want to run a cloud native / 12 factor app. It's also rapidly evolving to run rich workloads (TCP router is coming, .NET is in beta).
I would say CF is more flexible at the kinds of apps and services it can run as the buildpacks tend to be more sophisticated forks of the Heroku buildpacks, or new from scratch buildpacks (like PHP, Or Java). Docker images should be hostable in the near future as well.
Whereas the service levels and instance sizing flexibility available from Heroku tends to be richer.
This is a function of where both companies make their money. Heroku only makes money from their public cloud, whereas Pivotal is focused on selling high end subscriptions for those who want to run their own private CF on Amazon or VMware or OpenStack.
As someone who worked in the Federal sphere, nothing's changed at all.
The same procurement rules and regulations remain in place with all the issues they cause. 18F is a nice experiment, and they do have some wins, but they are just a drop in the bucket.
The whole procurement and management process is so broken that it's a wonder any project gets completed. The same few bad actors keep winning contracts over and over again, fail, but then don't have any repercussions. In fact, their failures actually net them more money more often than not as contracts get extended now that the contractor has the government by the balls.
IMO the best thing the government could do is a massive in-housing of functions. So much infrastructure within the Federal sphere has contractors essentially acting as PMs, the rank and file builders, the maintenance staff, etc., all with many layers of prime contractors and subs stuffed with middlemen.
This doesn't go just for IT. Lots of simple functions are outsourced to little benefit. Some of it I think might be because it's hard to fire Federal workers and contractors aren't unionized, but it would be better to fix those issues than hire the same person for twice the salary (when accounting for middlemen, margins, etc.)
I'm inclined to agree, but I have two questions regarding that:
1. Aren't government positions notoriously underpaid compared to their private-sector counterparts?
2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?
Not that #2 isn't possible/likely/a fact under the current system depending on who you speak to.
> 1. Aren't government positions notoriously underpaid compared to their private-sector counterparts?
Yes.
> 2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?
Assuming that that is the case, the fact that government positions are notoriously underpaid compared to private-sector counterparts would also imply a significant skill deficit in those overseeing and managing government contracts for outsourced work compared to the people employed by the private contractors to exploit the contracting system for maximum profit.
So, if we assume that public sector pay deficits mean, on average, public sector skill deficits, then so long as you don't address the pay deficits, you're stuck with either :
(1) Government software being substandard quality because its made by people with substandard skill working in government, or
(2) Government software being substandard quality because of substandard controls and quality assessment being exercised in the process of contracting out the work to private firms seeking to profit from government contracting process.
> 1. Aren't government positions notoriously underpaid compared to their private-sector counterparts?
Direct Federal hires could be underpaid compared to the private sector, yes. The government uses the General Schedule (GS) scale, which tops out at ~$160K after adjusting for cost of living (there's a base salary and a CoL adjustment). There are rules over who can go in what grade and what step which would likely preclude most SE folks from being compensated appropriately. Those with PhDs and masters degrees would find it easier to get into the appropriate pay band.
Contractors can make good money, and, accounting for not having the middlemen, the Feds should be capable of paying higher salaries for technical fields and still save money. If we're already magically reforming the government by bringing stuff in house (taking an act of Congress in many places; lots of agencies have caps on the number of employees, forcing contractor usage), then we should be able to also reform the pay scale.
>2. Doesn't that mean that "government software" would end up being written by below-average developers and be significantly worse than private-sector software?
Sadly, that's exactly what's in place now. The developers in general are already worse than in the private sector. It's not because of money, it's because of incentives. The Feds aren't good at killing bad projects or disciplining companies they hire.
What you'll see on your typical Booz Allen, Leidos, SAIC, Lockheed, etc. team is a lot of highly educated and experienced people--the government highly incentivizes both education and experience in bidding processes--that are useless. The process beats them down. It's not that they're dumb; they're usually not.
It's difficult to get through the government processes, especially when getting into cleared work. The hiring processes tend to highly favor previous government work, so you end up with the same pool of people. You can't easily hire new people, so you stick with what you've got.
Actually, in my experience the private-sector developers doing government contracts are well paid but are sub par skill wise. The software you work with, the slow procedures and the negativity surrounding failing projects ensure only the mediocre stay, which in turn results in longer and more failing projects. The good developers leave for startups etc.
My (admittedly limited) understanding of why contractors are used instead of government employees is because it's notoriously hard for the government to fire people who aren't good. The premium cost of contractors is worth it when you're able to fire them if they don't meet expectations.
There are many reasons they use contractors. Here are some of the reasons:
1) The agency in question has a hard cap on the number of employees, but has more work than it can accomplish with just this allowed staff. Contractors are the only option.
2) The government is building something and doesn't need (or thinks it doesn't need) to keep the experts around afterwords. For instance, you're building a bridge and won't need all of the construction workers when it's finished.
3) To get around the broken hiring process
4) To get around the broken union rules
5) To theoretically save money vs. doing it in house
The video at the "byzantine regulatory framework" link[1] is worth a watch (at least the first 10 minutes to get a taste). One of the most valuable offerings of cloud.gov is (hopefully) the ease with which it can go through the ATO and FISMA processes because it was designed with them in mind.
I'm not sure how this will expedite the ATO process as it uses technology that has not been STIG'd yet and may not have a "by the book" way to sign off (Docker, for instance, can be painful to ATO).
EDIT: After viewing Noah's FISMA guidance vid (nice work) there is definitely possibility to expedite but to really grease things you'd want to create a certification arm within GSA that can sign off the risk or perform a "certified" risk assessment on behalf of the customer agency so you could do things your way while still allowing them to sleep at night. Once you get into sensitive data loads and non-public stuff people start to get even more risk averse. / End Edit
That said, I'm hopeful that it does pave the way for change because this kind of platform is critical to reducing the barriers to experimentation in government. Perhaps because 18F is committing to supporting / upgrading the platform it will allow Federal CIOs and CISOs to shift some of the risk to 18F and sign the paperwork more quickly.
Those teams definitely exist in agencies (GSA included), but we (18F) are managing ATOs internally for our projects, and are working on tooling to clarify, simplify, and automate the process. https://github.com/18F/control-masonry/ is our first project around this.
This is awesome work that is going to make it easier for a number of our digital service teams across government to deploy services.
[shameless plug to join public service for a year or two]
If you're interested in joining 18F or the U.S. Digital Service (which has an HQ office in the White House but also has teams across government), this application works for both teams: https://www.whitehouse.gov/usds/apply
There are upsides to big companies, and if they can keep the downsides (beuracracy, etc) under control... Once upon a time HP was supposedly a phenomenal place to work.
It is maddening trend, how a few seconds of video is often clipped out of a larger video and inserted, on infinite loop, in another document with no direct reference or explanation.
One of the strangest things I've run across on Reddit is a group of people with a kind of thalassophobia (fear of the sea) that is focused on man-made things under or partially submerged in water. They call it submechanophobia and share pictures of such things to spook each other out on their subreddit (https://www.reddit.com/r/submechanophobia).
I am really enthusiastic about the potential for building Eco-systems of small developer companies that focus on building the thousands and thousands of package that governments the world over need for their stutory obligations
The blueprint for USDS was the UK digital service, this is hitting some issues as they have started a ball rolling but now look like a bottleneck. Some of the "agile" restrictions and some of the centralised nature of development teams are likely to go - but the essence is a fantastic opportunity and landscape ahead
> The magic happens when an infrastructure team encapsulates their expertise, and then exposes that expertise as a service which can be used directly by developers.
I like this statement - how do you deal with educating team members on areas that require deep expertise? (e.g.., security, accessibility, localization).
Do you offer training, brown-bags, educational videos, or do you say "don't worry about it - if you do this in $x way, magic[1] will take care of you".
[1] Magic being defined as the compiler, automated tests, etc., feeding into a central feedback system (bugs, tickets, email, or whatever you use) telling you what you did wrong, and hopefully how to fix it.
Accessibility and L10N are app-level concerns, not something that cloud.gov is going to be able to help with. However, 18F works on other efforts aimed at helping people do those things better, eg https://18f.gsa.gov/2015/09/28/web-design-standards/
As for security and other devops concerns, which is what cloud.gov is about: This is why we're in a scaling/pilot phase now. A successful PaaS should reduce the depth of expertise needed to do those things right. That said, there are things like awareness of 12factor.net app design principles which are very unevenly distributed in government once you get outside of 18F. We will be concentrating on generating materials and documentation to make learning about those things in the context of cloud.gov as self-service as possible, and expand the pilot outward to those who need help even approaching the concept of a PaaS once we have more of those materials.
I wonder how many agencies will allow developers to jump into this; seems many of the agencies have a "must be built internally here" attitude about some of this stuff. Still, looks like a good step forward.
The more I am observing the government I wonder if it will ever be possible for the the 18F treatment to hit the more old traditional Federal Government agencies like CMS. Talk about byzantine regulations.
I saw several people from 18F present at Code for America Summit the other week, and my understanding is that the regulatory overhead involved in launching new government tech services (something like 4000 pages of relevant regulations to comply with) is so large that it's usually a boondoggle. Part of what they are doing is building services with that regulatory compliance built into it, so agencies don't have to slog through all of that for every little thing they want built.
Governance, Risk and Compliance. Even if the private sector does GRC better than the government, they (the gov't) at the very least have control. Not to mention their stack appears to be mostly open source (Docker, CF, etc). This makes total sense and is a "best of both worlds" approach.
The cloud.gov platform is built on top of existing tooling and platforms (Docker, Cloud Foundry, AWS). It's possible recommendations and documentation for quickly deploying sites and services using these platforms is lacking, or changes too often to be provided as a supported, recommended solution to a large set of small teams.
This is cool, but,...18F are consultants, who pop in, wave a magic wand, and pop out. Many of its employees are.bound by law to a max 2 or 4 year term. Will cloud.gov support its users for 5, 10, 15 years?
> This is cool, but,...18F are consultants, who pop in, wave a magic wand, and pop out.
My understanding is that some of what 18F does is short-term, project-based consulting for other government agencies, but that that isn't all of what 18F does.
The limited employment term things is a real concern for non-consulting, ongoing functions, but may have salutary effects, if it means that design for shared maintainability and succession planning aren't the kind of afterthoughts that they are many places in government.
