Getting started at TTS: Your first 90 days
There’s a rule of thumb that says it takes at least three months to understand a new job, and that your first 90 days are crucial to understanding just what the heck you’re supposed to be doing.
That’s probably never more true than when you’re working for the federal government, where regulations and acronyms can quickly become overwhelming. Working here is a lot like learning a language via immersion: the first weeks are likely to be spent trying to thumb through your handbook quickly enough to communicate at all. This can be very frustrating, even for new employees who have worked at other federal agencies!
To help you get past that frustration and contributing as quickly as possible, we try to cover all the bases in your TTS Classes for Onboarding. But we also recognize those are a firehose of information and a lot of stuff won’t make much sense right now.
So, here’s a guide to help you focus your onboarding efforts and work through some technical tasks that set everyone at TTS up for success. You don’t need to know all of this stuff today. Skim it now, then refer back to it over your first 90 days or so as you’re ready to absorb more. Pretty soon you’ll be the veteran around here, helping someone else learn these things.
Within your first week or two you should be working through your onboarding checklist, TTS Classes for Onboarding and any OLU training that’s been assigned. If you’re not, go take a look at those first.
As you try to understand TTS and what it’s about, you may want to take a look at the TTS organizational chart. Org charts for each office are available in Google drive, too. Here’s the 18F org chart, and here’s one for Solutions.
You’ll probably spend quite a bit of time with the TTS Handbook — you’re reading it now! The TTS Handbook isn’t at all like most organizational handbooks. Where past experience might have you expecting a dry rehashing of PR policies and jargon-heavy mission statements, we’ve filled our Handbook with useful information that we update regularly — and you can help update it, too. Get in there, poke around, and search a little. It’s a treasure trove.
Here’s a tip: As you work through your onboarding checklist, search the handbook for the items in your list. You’ll find tons of extra information and context.
Don’t underestimate how helpful your teammates will be, either. Talk to them - in Slack, in Google Hangouts, or in person, if you are based in one of our offices. Set up coffees — just say “Coffee me” in a Slack channel and our CoffeeMate script will pair you up with someone. Don’t hesitate to reach out for coffee with someone outside of your area, either. Everyone here is positively brimming with useful information to share.
Remember, this is learning-by-immersion, so as you get invited to things, say “yes” a lot. Say yes to all the video meetings and guilds and working groups to which you are invited. Listen and ask questions. Tell us if you think we’re doing things wrong. Tell us about your pets. Just get in there and get actively involved. You can always say “no” later, but right now you can learn a lot by just saying yes.
You don’t need to have any specific expertise to join a guild or working group: just join their Slack channel and start attending their standing meetings. If you need an invite, post a message in the Slack channel or DM whoever organizes the group (who’s often listed in a pinned post in that Slack channel).
If you need support, can’t find it here in the Handbook, and don’t know where to start, #questions is a good Slack channel to drop into if you think multiple people could direct you. But you can absolutely turn to your supervisor and/or lead/functional lead. For 18F folks, there’s a bit more detail over here in Support, much of which may also apply to other parts of TTS.
TTS is a technical organization, so even if you’re not an engineer you will find yourself in technical environments. Here are the bits everyone will probably need to know:
GitHub and Version control
Version control is simply the act of keeping track of a file without having to name it “myfile-10-10-18-final-final-final-approved.” Instead of creating a new version of a file for each change, you use a system to keep track of revisions. This is especially important when you’re talking about a whole bunch of files working together, like code, or a large multi-page document. In that case, you really need a version control system. Here at TTS, our version control system of choice is GitHub.
Almost everyone at TTS spends some time working with GitHub, whether they’re an engineer or not. If this is new to you we suggest you start with our Intro to GitHub. When you’re ready to begin using GitHub, the Handbook repository is a great place to practice basics like creating a branch and a pull request. If you see anything in the Handbook that appears out of date or incorrect, you can practice your new pull request skills and help us improve it! You can also look through the Handbook issues and fix something.
When you make the changes you want to see and open a pull request, someone will review your code. Alternately, you may very well get pulled into a code review someday because of your expertise in a topic.
If pull requests and code reviews feel a bit foreign to you, it might be helpful to think of it as similar to suggesting changes in a shared Google Doc. In both cases, you’re collaboratively trying to reach a final version. The 18F Engineering Practices Guide has some great guidance on how to be a good code review partner, but the main thing to remember is simply to be kind. We’re all trying to improve things.
And remember: you can be fearless in your pull requests. If you ever manage to break something in Github it can easily be changed back to how it was — that’s the beauty of version control. If you get stuck, you can just wave in the #tts-handbook Slack channel and someone will quickly help you.
Setting up your Mac for success
For most people at TTS, sooner or later you’ll probably find yourself wanting to work with a project locally on your Mac. We recommend using our laptop script as a quick way to set your Mac up and use our technology stack properly.
If you’re not an engineer, it’s possible you may not need it, but when you do you’ll be glad to know where it is. Just follow the steps: everything will be set up correctly and you’ll minimize weird conflicts and problems later.
If you are an engineer, we understand that your preferences about optimal development environments may differ from the laptop script. In that case, please come talk to us first in the #dev channel before setting up your own environment. Maybe you’ve identified a good way to update the script!
If you are running a project locally, you may also find yourself needing to know some basics of the Mac OS X command line.
And remember, if you can’t figure out how to get it running, that’s probably not your fault — there is likely something that needs to be updated, and that can be accomplished by reaching out in the #dev channel. Also you can file an issue in the repository or contact one of the project owners or contributors and ask them to update their README and any other relevant documentation.
Markdown is probably the most commonly used way to style text at TTS. It’s used in GitHub, in Slack, and in many other systems. If you see things that mostly look like plain text but have some semi-random * and # littered through them, that’s probably Markdown. It was designed to mimic how one might write a text-only email.
There are quite a few online Markdown editors you can use, but after just a little practice you won’t need them. Pro tip: You can open a DM channel with yourself in Slack and use most Markdown in messages to yourself to try it out and see the results. Headers don’t work in Slack, but most other Markdown commands do. While you’re DM-ing with yourself, you can also click the plus button on the left side of the input box, click “Post”, and practice your Markdown in there. Slack’s posts support more markdown than messages do, and it renders live. Which is pretty neat.
Security, Compliance, and ATOs
Security and compliance are, unsurprisingly, important issues for TTS. They’re also complex topics, and you’ll find a lot of people working on them. For an easy introduction into these topics, we suggest you start with this lightweight primer, especially if you haven’t worked on information security before. Read the “Security incidents” page to learn how to respond if you spot suspicious activity or an incident. If you’re looking to go into greater detail, 18F’s Before You Ship guide is definitive and should answer any questions you have, but it can also be a little overwhelming. If you ever need a quick answer, clarification or just general Security and Compliance help, reach out to the TTS Tech Portfolio in #tts-tech-portfolio channel.
If you hear “ATO” or “Authority to Operate” and are wondering what that’s about, Before You Ship and the Security and Compliance leads can help you out there, too.
You may also be wondering about security clearances. It’s not something you need to worry about now. If you are in 18F and staffed to a project that needs clearance, your account manager and staffing rep should make sure that any clearance needs are taken into account. Still, it’s never a bad idea to ask if you’re wondering.
TTS Products and Platforms
TTS offers many products and platforms to federal agencies, and we are strong proponents of using those products and platforms ourselves, too. Here are three TTS offerings that you will likely interact with early on (and often) during your tenure here.
It won’t take long at TTS until you hear someone talking — usually emphatically and ecstatically — about Federalist, which is a really easy way to get a .gov site up and running. If you’re already familiar with static site generators, then Federalist will already be pretty clear to you. If you’re not, that’s okay. It takes care of the hardest bits, and each step you need to take is well-documented. There’s even a handy video to help you get started. If you ever get stuck, give a wave in #federalist or #federalist-support and they’ll get you back on track.
Just as Federalist makes creating .gov sites as easy as possible, Cloud.gov makes hosting them as easy as possible, too, by dealing with a bunch of security and compliance sticking points so you don’t have to. That convenience and trusted status means almost everything we build is hosted on cloud.gov, including Federalist, cloud.gov is extensively documented and heavily supported in #cg-support. Still not clear? They have a video, too.
USWDS — the United States Web Design System — is a frontend framework designed to make it easy to build accessible, mobile-friendly government websites. They’ve worked through hundreds of issues related to accessibility, usability, and the overall user experience. Your project can leverage that effort nearly instantly. To try out the USWDS on a test site, you can use the templates provided by Federalist.
Those are just three of the products TTS is working on, but there are many more.
Acquisitions and Procurement
18F alumni Sasha Magee memorably summed up the progression through government digital service like this: Year 1: “Why y’all talk about procurement so much? How boring.” Year 2: “Man, procurement’s a pain.” Year 3: “We should really consider doing something about procurement” Year 4: “Holy crap there’s nothing more important than solving procurement!”
You’re going to hear a lot about acquisitions and procurement. For a quick dive, start with this simple introductory presentation.You may also want to view these relevant decks presented during past 18F Team Coffees:
After that, dive into the relevant handbook pages — this is a good starting point – or ask any questions you may have in #acquisition. If you want to go really deep there are free courses available from the Federal Acquisition Institute.
Government budgets have a big impact on what TTS works on and when. You may hear terms like “one year money” or “no year money” or “the color of money” tossed around and wonder what people are talking about. Here’s a slide deck intro.
Most of TTS is funded from the Acquisition Services Fund (ASF). This fund does not receive annual appropriations from Congress, but instead collects fees from the government agencies the fund serves. 18F, PIF, and Centers of Excellence are “cost-recoverable,” meaning that we must replace the money we use from the ASF. So we take money from the fund to operate it, then replenish it by charging our clients for our time.
Since the ASF is not subject to annual appropriations and has a sizeable balance, 18F employees are typically allowed to continue to work and get paid in the event of a government shutdown, although project work may be severely limited.
OPP and 10x are the exceptions. They are funded from the Federal Citizen Services Fund (FCSF), which means they get an annual appropriation from Congress.
For more details on the federal budget process, government shutdowns, our funding sources, and types of funding in agreements we enter, read All Things Money.
You will hear about “billability” in TTS, and if you are in 18F, it will be a regular conversation. In order to recover costs, the ASF-funded offices need to bill their clients. Because 18F rotates projects frequently, billing is on-going and tracked through Tock. Your project commitments should be captured by the #18f-staffing team in the staffing GitHub repo.
Not everything 18F does is a billable project, and that’s okay. Most people are expected to bill a minimum of 32 hours a week, leaving up to 8 hours for things that aren’t related to a partner or a project. This “non-billable” work is often the glue that holds the organization together: guilds, working groups, internal tools and documentation.
You can learn more about billing expectations and time tracking in the Tock Handbook pages.
Almost all 18F projects are considered either a Path Analysis (PA) or an Experiment and Iterate (E&I) engagement. You can learn more about both in the 18F “How We Work” guide, which you’re going to want to read anyway.
The short version is that a PA is a short, exploratory engagement in which we help the partner define the problem and look at some potential solutions. For more information and resources, take a look in the Project Artifacts repo.
In a follow-up E&I engagement we, well, experiment and iterate on the findings from the PA. For both types of engagements we have refined an ever-larger set of reusable resources that you can learn more about in the #project-resources Slack channel and Project Resources drive.
The short version is that projects are staffed through the 18F Staffing repo, and you can always comment on an issue to express your interest.
Our approach to Agile
We are known for our Agile approach to both software development and procurement (sometimes called “modular procurement”). In fact, many of our partners come to us because they want to learn how to “be more Agile.” If you take away nothing else from this page, take this:
Agile is not something you do. Agile is something you are.
Of course there are many ways to “be Agile,” and everyone at 18F will have their own take. This is great, and we encourage healthy debate about Agile best practices. In order to ensure a consistent experience for our partners, we do ask everyone to adhere to these basic principles:
- Don’t worry too much about buzzwords like “SAFe” or “Lean” or “Scrum” or “Kanban.” It’s more important that we adhere to the spirit of Agile, meaning that we employ iterative and incremental development, we make small bets to decrease risk, we seek to learn as we go, and we pivot when necessary.
- A corollary to the above: Don’t confuse specific rituals or artifacts with being agile. Many of our projects adhere to a typical Scrum-like process or make use of Kanban boards, but it’s important that we don’t convey to our partners that adherence to these rituals or use of a particular tool is equivalent to “being Agile.”
- We want to model an Agile approach for our partners as much as possible, in all of our disciplines. This may mean helping them to build a devOps pipeline to allow for an Agile release schedule, creating rough prototypes and testing them with users before we’re “sure” of an approach, recommending a series of small procurements rather than a single large one, recommending a short experiment around a business process, or even suggesting a major pivot in our strategy. Again: Agile is a way of approaching problem-solving, not a methodology with inflexible boundaries.
- One caveat: though we believe employing Agile practices is an essential part of delivering high-quality user-centered services to the public, we also recognize that many of the projects we have the privilege of working on play a critical role in people’s daily lives. It may not always be appropriate to “experiment” when it comes to people’s access to critical government services. We always keep this in mind as we work to build our partner’s capacity for more Agile workflows.
Working with partners
Partners come to 18F because they want help with hard technical problems, often involving creaky legacy systems and processes. We’re not going to help them be successful by shoving them out of the way and implementing the “right” way. We will be successful by helping them be successful – by teaching them repeatable, useful modern development practices that help them fulfill the mission and serve the public.
Consulting and communicating effectively with partners is how 18F is successful, and it’s how we help our partners be successful, too. You’ll also want to read up on how we collaborate with partners, which includes how we make remote collaboration work, how we model agile practices, and a lot more.
Diversity, accessibility, ethics and culture at TTS
TTS strives to thoughtfully and intentionally represent the broad American populace we serve. We also believe in inclusive design — creating products and environments that are accessible to all people, regardless of age, disability, or other factors.
To that end, we strongly encourage reading over the Diversity, equity, and inclusion materials in the handbook, and consider joining the #diversity and #accessibility guilds.
We also strive to be intentional when interacting with one another and with partners. One useful tip to start with today is to be sure that your location, agency and pronouns are represented in your Slack profile.
Your teammates terming out is a reality at TTS, where many people are term-limited. Since you just started you may feel like that won’t affect you for a long time. That is, unfortunately, not the case.
Because roughly 25% of 18F staff term out each year, and PIFs are typically on one year appointments, it may be a very short time until you will be asked to be a subject matter expert, or join leadership. You’ll have to be comfortable trying new things. Jump in and pick something up, even if you’re not sure you have enough experience or context. Pull as much information as you can out of veterans before they leave, and if you see something that isn’t written down yet, write it down. Before you know it, you’ll be the veteran. Start preparing for that from day one.
That’s typical TTS operations and culture in a nutshell. At some point, surprisingly soon, you’ll have internalized most of these things. That’s a great time to come back and read this again for the bits you missed or forgot about. Not long after that, you’ll be helping a newcomer understand these things.
Welcome to TTS!