A summary of conversations I've had with current, former and future Code for America fellows.

advice_for_cfa_fellows.md

• Who's your customer? The department or the citizen. What’s your product? The negotiated-design process or the actual outcome itself. These things are interrelated, but ensure the entire team is aligned and in agreement on what it is you’re doing and what the outcome is you want. What do you want to say you built at the end-of-year summit? The earlier you can figure this out, the better your year will go. Project uncertainty is the mind-killer.

• Don't negotiate with yourselves. My team would have achieved so much more if we had come to an agreement internally on how to proceed in our city design negotiations, and let CfA staff tell us if we were unreasonable. Instead, we watered down what we wanted, caved on major issues, and negotiated individually with our city partners rather than as a team.

• Invest your time in one thing for the entire year. Your understanding of the civic problem-space may change and evolve, but creating a commitment (individually, as a team, and in your city-partner relationship) will lead to better technology, product and customer fit. Also, scoping a full-year project (that you can begin building in March) is way more satisfying than a constantly changing set of pokey experiments from which one is selected and fuzzily narrativized for the end-of-year summit (in my experience). Many (most?) CFA projects end up as waterfall development. They don’t have to be. Don't bounce between small projects that you’re awaiting external validation on. Doing this means that you probably won’t invest in the negotiations and relationship-building necessary for them to be successful… let alone long-term design and engineering (like effective copywriting, documentation, analytics, automation, continuous integration, deployment and monitoring) that you will learn as you work, learn, and rework the project you are committed to.

• Have real users by May. People go on summer vacation and suddenly it’s September and you’re “launching" at or after the summit. Sigh. Teach the distinction between “having real users” and “launching”. Once you have agreement on the general scope of the project, all further negotations should be zeroing in on "what is the minimum necessary we have to do to get real users?"

• Learn to program by working on your product. If you’re trying to improve your tech skills, the best way to learn is my working on team committed to a product or approach. Make this work as a team: if your more experienced teammates want to “go fast” do not let them. Don’t fall into the trap of dicking around on a bunch of small projects that aren't fully-defined or you aren't fully invested in.

• The Mayors Office (and their Department of Tech/Innovation) cares primarily about Public Relations. Whereas the city departments are the ones who actually do the work and can give you the most productive design (“can/how it should work”) feedback. Practically, this means that the Mayor's Office is going to be very focused on "The Launch" whereas indvidual departments will be able to get you real users.

• Don’t rely on outside vendors or timelines. If your project relies on a 3rd-party delivery, either have a 2nd parallel project that you are equally invested in (if so, why not divest yourself of the 1st project entirely?), or be willing to own the failure (see “Don’t Negotiate With Yourself” above). I’m still waiting for the end-of-year summit story of "failure that is failure” not “failure that led to success”.

Other advice:

• Every project, team, problem, etc. is going to have its own challenges... don't let anything we say prescribe "what you have to do"
• Dream big. Deliver small. Get over your own ego and ambition about "solving the hardest or biggest problem" and instead promise to deliver the MVP that goes in that direction. You will want to solve the big problem. That is fine. But you will only be frustrated by the obstacles if you waterfall it.
• Once you come up with a small-ish project, think of ways to make it smaller.
• A small project is one that will look like you will finish it in two months, because you are a genius at what you do. BE OKAY WITH THIS. In reality it can take six months to develop, and three more to test and polish it with users. The reason why this happens isn't because the technical problems are hard; it's because the political process, and building social capital, takes a huge fucking time.
• If you are a new fellow reading this in January, the takeaway isn't "this is what I should do" or "how I should think." Without experience and context, this advice turns into dogma about how to behave. Instead, let this advice guide you as the problems and questions arise - and don't be afraid to reach out to previous fellows during the process.

What does this have to do with January orientation?

I think one of the hard parts of the Fellowship is that it's overwhelmingly an experience of starting, whereas most of the celebrated stories of the civic tech zeitgeist are descriptions of outcomes (or less charitably: outputs). Often imagining "what could be" has more in common with "what didn't happen" than "what did". So as you go through orientation, listen for and ask about things that didn't happen (or couldn't happen) and how those situations were resolved (or how people after the fact wished they had resolved them) or coped with and moved beyond.

Oh, and anyways, you'll do fine.

Ben writes that "every project, team, problem, etc. is going to have its own challenges." In that spirit, here's a contradiction:

• Don't invest all your time in one thing. Have multiple projects. Our team had three-ish: one internal to the city, that required significant buy-in, trust building, and maneuvering. One that was at least as external as it was internal (a local University partnership with the City) that could move independently. And we had a major event + ongoing organizing work around tech volunteering. That meant when one project was blocked or going slowly, we weren't sitting around bored and frustrated.

To contradict both Ben and Matt, it's not a one-size-fits-all solution. In some cases (committed partner, clear need, clear path to success), one big project may be the ideal solution. In others (conflicting priorities, uncertainty around buy-in, varying interest levels), multiple (smaller) projects may be better.

We went the @hampelm way in Las Vegas, and I can speak to the pros and cons of doing it that way, but I think @gangleton has the most succinct way of putting it: it really does depend on your city and the situation around it.

Real gems:

"The Mayors Office (and their Department of Tech/Innovation) cares primarily about Public Relations."

"Don’t rely on outside vendors or timelines."

"Dream big. Deliver small. Get over your own ego and ambition about "solving the hardest or biggest problem" and instead promise to deliver the MVP that goes in that direction."