How to Labs

Chris Whong
NYC Planning Tech
Published in
8 min readMar 29, 2019

How we build is as important as what we build.” If you’ve ever seen our “About Us” presentation, this phrase has a slide of its own, and it’s a pretty broad statement about workflows, cadence, tools, software, etc. If you haven’t seen our “About Us” presentation, give us a yell, we’d love to share it with you. This post will highlight some of the tactical interventions our team has in place that help us work more effectively than your typical government development shop.

Use Laptops

In most government agencies, the desktop computer workstation is king. It’s probably issued to a cubicle, not to an actual human, which speaks volumes. It limits the ability to “do work” to a single physical space, which isn’t in keeping with the values of a modern digital organization.

Modern developers have an intimate relationship with their development machine, and that means it needs to go where they go, and be at the ready for taking notes, writing code, or managing deployments alike.

Have Screens Around

This goes hand in hand with the Laptop rule above. Having screens everywhere to connect those Laptops to means people can share ideas on a whim. You’ll often see Planning Labs people walking the halls of 120 Broadway carrying a coiled HDMI cable with a USB-C to HDMI dongle on their way to a conference room. What will they put on the screen? Probably just a web browser (see “Use Cloud Services” below).

But Chris, our conference rooms already have a dedicated desktop PC. Ok, see how long it takes to go from “Off” to “Web browser open and ready to navigate”. Go ahead, I’ll wait…

Our weekly skill share, where people can share useful concepts and techniques

Beyond the conference room, you should have flexible screens for pair programming or impromptu presentations scattered to and fro. We have one in our “quad”, and it’s not reservable. It’s like a park… public space, be a good neighbor, leave it better than you found it, etc. Desk space is scarce, but we dedicate a whole workstation’s worth of linear feet to the big screen. It’s that important. You’ll often find people hooking up to it to share something they’re really proud of, or where they learned something important. Other times you’ll see two or three people crowded around it, attacking a technical challenge together.

Hannah, Matt, Taylor, and Andy collaborate on a mapping issue on the “Big Screen” in our quad.

Have Standups

We have a daily standup at 10 am. The script is simple:

  1. What did you work on yesterday?
  2. What are you planning to work on today?
  3. Do you have any blockers?

With a team of 7, it takes about 10 minutes, and is a great time to quickly touch base, disseminate and collect information, and make sure everyone knows what everyone else is working on.

If you can’t be physically present at standup, a message answering the 3 questions above is expected, along with a follow-up to make sure you didn’t miss anything critical. This should be a rarity, being physically present reinforces the “we’re all in this together” mentality.

Have a Chat Service with Public Channels

Most government agencies use email as chat, as its usually the only official communications option from the desktop machine in your cubical. Email is exclusive by nature, as a sender must consciously choose who to include in the conversation.

At Planning Labs, we rely heavily on Slack for team communication. There is still a time and place for emails for more deliberate or less ephemeral communication or announcements, but for day to day development work, public Slack channels are where things happen.

We set up public channel for each project we support, and members of the organization can easily come and go. You’ll see chatter about design, color choices, people asking for help, people offering help, etc. We actually require our non-developer customers and subject matter experts to hang out on Slack and be generally available to answer questions and weigh in on our choices as we build. It’s super inclusive and reinforces the idea that it’s not just engineers and designers that build great products… it’s a team effort with the users and SMEs.

Hannah and Andy share github issues for discussion in Slack

Be on Social Media, Have a Blog, Have a Website

Our website is pretty simple. We actually cloned 18F’s website when we launched, but ended up re-building it in a different framework. It has photos and short bios for everyone on our team, a bit about how we work, what our mission is, etc. It has a simple, Airtable-powered showcase of our various projects, and shows the 4 most current blog posts (powered by medium.com, as you know). It’s a fun, geeky, and deeply symbolic tradition for new team members to submit a pull request to the website’s codebase adding their photo and bio. (It will be equally symbolic when I PR my departure next month. 😢)

The expectation at NYC Planning Labs is that everyone on the team writes one blog post per month. It’s how we stay in touch with the broader communities of open source developers, civic technologists, digital services, service design, etc outside of the walls of our agency. It’s also a way to “pay it forward”. Much of our success is built on others sharing their work, particularly via open source code, but also by sharing best practices and strategies via books, blogs, and social media.

The Blog and Social Media also become great vectors for promoting new product launches, job openings, and events.

Have Stickers

Just have stickers, and bring some with you everywhere you go.

Our V2 NYC Planning Labs Stickers

Have a Regular Cadence

We are an agile team, which means we bite off a reasonably-sized chunk of work and ship usable, working code (see below) at the end of each iteration, or sprint. What we do in a sprint depends on a combination of priorities and available resources. Thinking in these smaller cycles keeps everyone focused and prevents drowning in the enormous complexity of large, long-term projects. We work on a two-week sprint cycle, using the letters of the alphabet starting in January. We’re currently in Sprint G of 2019.

The Monday at the beginning of the sprint has large chunks of time set aside for sprint planning, clarifying issues, and getting everyone familiar with the goals of the sprint, and how we plan to meet those goals.

The Friday at the end of the sprint has large chunks of time set aside for product demos, internal team review, and retrospective (See below).

Mid-sprint Fridays have time set aside for skill-share, where team members and other colleagues can do short presentations on what they’re working on or techniques/tips/tricks others may be interested in.

Demo Working Software

Our demos happen on the Friday at the end of a sprint. We generally invite the entire agency, and see this is a first opportunity to solicit feedback on the new features and fixes we’ve put in place. Sometimes we’re showing off several minor things we worked on, and sometimes it’s a major demo of lots of improvements to a single product. The turnout varies, sometimes it’s just us, sometimes we get 15 or 20 planners from around the agency. It all depends, but it’s become a regular fixture every other Friday afternoon.

Be Retrospective

Usually right after our bi-weekly sprint demo, we hold a retrospective. This is where we talk openly about what went well, what didn’t, and how we can change our practices to be more effective. There is always time set aside for talking with the whole team about how things are going. It’s not a special thing to talk about things that are bugging you, it’s something we do constantly and collectively seek to improve.

Use Cloud Services

We use cloud services for just about everything we do. For communications, we use Slack. For email and calendars, our agency uses Outlook 365. For code publishing and issue tracking, we use GitHub. For shared secret management, we use 1Password. For automated testing we use CircleCI. For hosting our frontend web applications, we use Netlify and Heroku. For uptime monitoring, we use updown.io. For a major part of our web mapping infrastructure, we use Carto. For a lot of information management, we use Airtable and G-suite.

Using cloud services for just about everything means we are free to work from anywhere. All we need to be [extremely] productive is a good, open wifi connection and a laptop!

We still keep an on-network windows workstation in our quad so we can do things like print and access the internal payroll app.

Have Comfortable Spaces for People to Hide/Work alone

Sometimes you just want to go hide and knock out some work. This blog post is being written not from my cube, but from some very comfortable lounge chairs at the foot of the stairwell in our office. It’s more comfortable than my office chair, there aren’t as many people around, and I can put my headphones on and work.

Me writing this blog post not at my desk, but from the comfortable designer chairs in the hallway

Let’s get meta. Here’s where I asked someone in Slack to help me get the photo above, while writing this post:

So Meta

There are a few of these spaces scattered around the office, but nobody really uses them except the laptop users, and there aren’t many of us… yet.

Work Well!

These are just a few pointers for setting up the work environment that’s served us well over the past 2 years. Just like with the products we build, constant assessment of the user experience helps drive the decisions and priorities for crafting the best working environment for our team, both physical and virtual.

--

--

Chris Whong
NYC Planning Tech

Urbanist, Mapmaker, & Data Junkie. Outreach Engineer at Qri.io