Process is a process: growing our engineering team from 0 to 5 employees

Recently, I was talking to my friend Tal who previously worked at Pivotal Labs. He’s now the CTO at Josephine and we were discussing our team’s respective product & engineering workflows. Five minutes into the conversation, he mentioned the cognitive dissonance he initially felt around his experiences working at Pivotal and then later building a small engineering team:

At Pivotal, every Monday we had a planning meeting that was exactly 30 minutes long. At the end, everyone knew exactly what they were doing and we’d close the meeting with a synchronized clap. For the rest of the week, every team member was at their computer working heads down on their engineering or design work from 9–5. The following Monday, we’d rinse and repeat.

When I started building a small engineering team, we used Pivotal Tracker, met Monday mornings with a clap, and did Ro-Sham-Bo Estimation, yet things were a total mess. I was genuinely surprised that our team didn’t just magically run as well as the one I’d worked on at Pivotal.

Gradually, we’ve moved away from pattern matching those specific tools and focused on building practices that worked well for us. The big realization was that the specific tools and techniques a company uses are only the outer layer of all of the work that’s involved in building good engineering processes. If you just pattern match the way some other team works, none of the important thought work about how your team should work gets done and the result is unsurprisingly…bad.

I’ve never worked at a company like Pivotal, but I knew the feeling they described well: as a first time manager, I’ve read countless blog posts and books on how to build software, then wasted many hours implementing tools and processes that missed the mark.

At Clef, I finally feel like we’re starting to build processes that work for us and I wanted to share the stages that we went through to get here.

2 Engineers (May 2013)

For the first 1.5 years of Clef’s existence, we were a team of three: Mark (CTO), B (CEO), and me(CPO). With B running the business side of things, Mark and I were tasked with building the Clef experience. Between, the two of us, we maintained our iOS & Android apps, API servers, website, and the plugins and libraries used to integrate Clef into platforms like WordPress and Bitfinex.

We briefly experimented with using Pivotal, then Trello, but eventually we settled on managing all of our engineering process through in-person communication. We could literally look over each other’s shoulders to keep up to date and have a conversation anytime we needed new direction.

We used Github to manage our code and did pull requests with reviews for code changes. We didn’t have massive usage or a big backlog of features, so every time a customer reported a bug, we’d make a fix and push. Continuous integration would take over and the code would be live.

Things were simple. With only two people on a team, I think there’s only so much you can gain from engineering process.

3 Engineers (January 2015)

We made our first engineering hire a little over a year and a half after we started working on Clef full time. Over the next 6 months, the three of us would work together to put together our first real set of engineering processes.

Things that didn’t work

We tried to use Trello to document the work that we were doing. We had a Current Development board, which tracked the work that was going on in a given week and then Product, Bugs, and individual feature specific boards that we used to plan work. Due to either our inexperience or our limited throughput, our boards and cards went stale pretty quickly, the extra work felt like a chore, and the visibility wasn’t valuable.

We scheduled a weekly Friday product meeting and Monday engineering meeting. The intent of these two meetings was to reflect on the work we’d done and plan the following week, but neither was particularly effective. I was in the very early stages of learning how to be a product manager, and felt it was my responsibility to come into the Friday meeting with a plan for the following week, rather than work with my team to build one. This led to confusion, misaligned expectations, and last minute changes. The Monday meeting just felt like a duplicate — more planning work for little return.

We started doing a morning meeting (standup) every day. There was nothing particularly problematic about our morning meeting, but it also didn’t really help us. I think being able to turn around and chat about something eliminated a lot of the friction something like this might otherwise overcome.

Things that did work

We started using technical design docs. The goal of these was to clarify what the actual scope of work for a feature or change was before diving into the implementation layer. They did a great job of helping us catch miscommunication before work was invested and continue to be a staple of our process.

During this period, our process felt forced and got in the way more than it helped. That said, I think there’s really only so much damage bad process can do on a small team: it likely wasted time and hurt creativity at times, but we could always fall back to in-person communication and were always able to work through the issues.

4 Engineers (October 2015 )

As our engineering team grew to two non-founders, we began to re-evaluate our process. To help with that evaluation, I reached out to one of my mentors, who’s had 20+ years of software engineering management experience.

In response to my concerns about Trello not working, I got a wall of questions — and a urge to dig deeper—which would help us build the groundwork for processes that could solve our real problems.

• What are you doing to promote visibility of work in progress?
• Does moving Trello cards put a message into Slack or something?
• Do you have a set of cards you talk over at the beginning of the week and wrap up about at the end of the week?
• Do people do any sort of regular checkin about work in progress (standups, snippets, other)?
• If you were working as a non-founder at Clef, how would you perceive the work to be done — a stream of cards that is fairly unbounded, or a discrete set of tasks or goals (iteration, release, epic, whatever)?
• What prompts people to keep going on something: app store releases? external events? other?

And the closing note:

Often engineers reach for tools or create tools when problems like this come up. I encourage you not to. Trello and/or GH are perfectly fine. The main problem here is social within the company, and the tooling really doesn’t matter at some level.

With this set of questions as the backdrop, we started outlining the core issues with the way we worked and our goals for any new changes we made. After we all had a chance to air our concerns, we sat down and came up with 5 key goals for our engineering process:

1. Build high quality software

2. Release code regularly

3. Accurately scope & estimate

4. Reflect on our work

5. Be more connected & less blocking

With our goals well defined, we then made a set of changes to help align the way we worked day to day.

Things that didn’t work

We hooked more automated reporting into our Bugs board and committed to keeping it up to date. The primary motivation was to do a better job of getting bugs into the board (through automation) and then fixing them (through our commitment). What we saw happen was that bugs would bifurcate: critical bugs would be triaged immediately and solved, while lower priority ones would stagnate without could test cases. Since the automation mostly included non-critical bugs, this meant that it added little value.

We changed the format of morning meeting (standup) to be more casual. With this change, we tried to move away from the standard “did, doing, blocked” format to something that was more about just getting face time with each other. After a few weeks experimenting with the change; however, it was unclear why we were doing it: it sucked up time, restricted people’s schedules, and wasn’t the best way to get social interaction.

Things that worked

We switched from continuous integration to a weekly release cycle. While some might balk at this change, shipping constantly or moving fast weren’t the values we deemed most important. By moving to a more deliberate release process, we forced ourselves to think about what we were shipping every week (Accurately scope & estimate work), gave an opportunity to feel and celebrate our constant process (Release code regularly & Reflect on our work), and made space for a more involved QA process (Build high quality software). We took a step back and realized that moving away from the latest craze could actually make us both happier and more efficient.

We better integrated our tools. We enabled Trello Powerups, which let us start linking the work we were doing across Google Docs and Github with Trello. This meant we could see design docs, PRs, build statuses and more in every card: making the Current Development board a hub for everything going on day-to-day on the engineering team at Clef.

We consolidated our chat notifications and reduced noise. Previously, we had two Slack channels: #dev-notifications and #dev. All of our notifications (Trello comments, Github comments, new PRs & commits, etc), went to #dev-notifications and all our conversation happened in #dev. We moved the highest touch notifications from #dev-notifications to #dev: comments on Trello cards and Github pull requests. This meant that as team members made progress or needed help, we all saw it in the space we hung out in: letting us feel more connected and unblock each other faster.

We switched to a two week sprint. We still do a release every week, but for planning purposes we meet once every two weeks and figure out as a group what we’ll be building and fixing in the next two releases. Having a two week timeframe to think on let’s us look at the bigger picture, and our weekly releases give us a nice cadence to both feel accomplished and gut check that the amount of work we’ve done halfway through the sprint is reasonable.

5 Engineers (January 2016)

At this point, a lot in our process is working well:

• The Current Development board on Trello gives any team member a really good sense of who’s working on what at any given moment.
• Our #dev channel is lively and easily jumps between longer form discussions on Trello cards & Github issues and chat messages to flesh out issues.
• We’ve now done 10 weekly releases, automated big chunks of the process, fleshed out what makes a given release good, and started optimizing our processes for that environment.
• Design docs continue being a powerful way for us to catch miscommunication and make implementation decisions before we’ve poured a lot of engineering work into a project.

From here, we’re starting to consider how we can do even better — and even the idea of adding new tools is on the table. While before we felt like we might be trying to solve our problems with tools, now we feel like we have the opportunity to improve on our good communication habits.

Things we are exploring

Switching away from Trello to a more full-featured product management tool. While Trello has served us well thus far, it’s starting to show its weaknesses in certain places. For bug tracking, we think the user experience is less than ideal. For high level product thinking, we think it’s restriction of having only one size of work item limits the ability to start with high level user stories and break them down into smaller engineering items.

Moving morning meeting to entirely online and reallocating our face time. As I mention above, we have felt that our new form of morning meeting was kind of pointless. Right now, we’re experimenting with sharing our did, doing, done report in a Slack channel every morning, then reallocating the time we would have spent on morning meeting to a weekly engineering team brunch on Tuesday mornings.

The primary lesson we’ve learned is that there’s no such thing as One Size Fits All when it comes to engineering and product process. Trying to follow what someone else recommends—at least at the implementation level—is almost always bound to fail.

Instead, the best thing to do is start from the bottom: what are the core goals of our team, then how can we incrementally use the current tools we have to build processes that help us reach those goals. Then, as those human processes get built, how can we find the cracks in our tools where things break down and patch or replace them.

Good luck!