Several months back I wrote about how we do higher level, long term planning within the Heroku Postgres team. If you haven’t read the previous article please start there.

The exercise or rule of thirds is intended to be approximate prioritization and not a perfect science. Since that time I’m familiar with some teams both in and out of Heroku who have attempted this exercise with varying levels of success. We’ve now done this process 4 times within the team and after the most recent exercise attempted to take some time to internalize why its worked well, creating some more specifics about the process. Heres an attempt to provide even more clarity:

Just over two years ago, Heroku was acquired. I was around and peripheral to this just before the acquisition and came on board only barely after. While there is a large group of people that have been there longer than I have (several for 4+ years) I’m still commonly asked how things have changed, how things work, and other questions of that nature. I wrote about some of these processes over a year ago in the months after joining Heroku around our hiring, our teams, and how we work. Many of these things haven’t changed, and yet almost always at a conference I’m asked how are things different since being acquired.

Here’s my personal take (and while I don’t typically include this – to be safe, this is not an official Heroku view of what’s changed).

Over a year ago I blogged about Heroku’s approach to Teams and Tools. Since that time Heroku has grown from around 25 people to over 100, we’ve continued to iterate and find new tools that work for how we do things. For many of the product management and software engineering books I’ve read I’ve yet to find something that helps a team priorize in a fashion I that feels right.

One process emerged nearly a year ago from within the Heroku Postgres team and is now followed by many others. Within a team this process is now commonly conducted each 6 months. Lets take a look at how this process looks

Heroku’s latest Cedar stack supports running anything. Heroku’s officially supported languages actually have their buildpacks public via Heroku’s github, you can view several of them at:

• Python Build Pack
• Ruby Build Pack
• Scala Build Pack

There have even been some created as fun weekend hacks such as the NES Rom Buildpack.

Recently at Heroku my teams have started exploring new forms of collaborating and documenting. In particular editing a wiki for communication is contrary to our regular workflow. Much of our day is spent in code and git. To edit a wiki within a web browser and using some markup we’re less familiar with is an overhead we were aiming to reduce. As a result we’ve tried a few things, the first was simply using a github repo to edit markdown.

I alluded in earlier posts of How Heroku Works that we have talented engineers. In fact I would venture to say that there is not a weak link when it comes to our engineers at Heroku. Ensuring we have talented engineers makes it easier for us to find other talented engineers and maintains a level of quality in our product. This means we must be very careful about not diluting our pool of engineering talent, which is where our hiring process becomes especially key. By the time we hire a new employee, we know without a doubt they’re a fit within our organization.

Our goal in hiring is seldom to fill a role, but more commonly to find more talented people share our goal (changing the world for developers).

In my earlier post on Teams and Tools at Heroku, I mentioned how we value engineers’ time; their work has enabled us to build a great platform. As a result of what we’ve built, we’ve had great growth both of our platform and of our teams internally. With that growth inevitably comes different distractions on engineers’ time. Despite how a manager may plan things, engineering work needs long periods of uninterrupted time. To ensure that no matter what, an engineer has plenty of opportunity to do the work he or she was hired to do, Heroku has Maker’s Day.

Heroku is a largely agile company, we work in primarily small teams that talk via api and data contracts. Its also a company comprised primarily of engineers, even product managers often write code. Heroku as a platform drives many of the features not from top down, but from bottom up based on engineers desires or skunkworks projects. There’s many valuable insights into how Heroku runs efficiently for engineering.

I’ll be diving into many various practices that enable Heroku to put quality engineering above all else, but first let me highlight the team structure and tools that enable this.