Welcome to our third installment in this blog series discussing Crunchy Postgres via Automation(CPA). This week, we’re going to talk about the team that I work with, it’s membership, its structure, the responsibilities, etc.
Let’s start with the team membership:
The eagle-eyed among you might have noticed I didn’t list a team lead or team manager. We’re currently self-governing/self-directing with Greg and myself acting as co-manager as needed and escalating as needed to Craig K. It’s probably not ideal, but it works for now, so why mess with it? 😉
You might be thinking, “that’s not bad.. a tightly knit team of four developers can get a lot done”. And you’re not wrong, we do get a lot done, IMHO; especially when you look closer and realize that only two of those four are allocated 100% of the time to CPA. I’m actually quite proud of what this team accomplishes with the constraints we have.
In addition to developing CPA, this team is also responsible for providing internal support to our Solutions Architect (SA) team as they craft and deploy highly-available solutions for/with our customers. At any point, any member of the SA team can hop on Slack and ask for assistance in deploying or troubleshooting CPA at a customer’s site and get help from my team. As any developer will tell you, interrupting flow is a bad thing, but we can’t leave our guys and gals in the field hanging, right? And so, one of the first things I did after accepting the Lead Architect role was to split the team into two sub-teams. 😱
Sub-teams?! Yes, that’s right. It became pretty apparent that forward momentum was being halted constantly due to interruptions. An SA would show up in our help channel asking for assistance and one or several of us would stop our work and attempt to help them. If several of us were trying to help, it would sometimes be confusing for the SA to know who to answer first, which suggestions to try first, etc. And my team would often spawn a side-conversion about who was going to help and who could go back to coding, or ask our own questions about why a suggestion was made, or why not suggest $x instead. Additionally, it was kind of a ‘free for all’ when it came to who was working on bugfixes and who was working on $cool_new_feature, which led to a lot of feature work and begrudging bug fixing. 🪳
So I quickly borrowed a page from my time at VA Software(RIP) and split the team into two groups. I called these groups our ‘sustaining engineering’ and our ‘development engineering’.
The sustaining team would be ‘interrupt driven’ and deal with our internal help duties. They would be responsible for responding to the SA inquiries, joining calls, debugging logs, and whatever else to get the SA over their hurdle. They were empowered to @ people for help as needed, with the understanding that they’d done all the needful to bring people up to speed on what the issue was thought to be, what had been tried, etc. When not delivering help to the SA team, they would be responsible for maintaining currently released product lines of CPA. It was their job to review PRs against the development branch, examine and back-port bugfixes as needed, and coordinating point releases (2.1.1, 2.1.2, etc).
The development team would, obviously, work on development to drive the product forward. They worked primarily on features, large refactors, and paying down debt. New releases of CPA (2.1.0, 2.2.0, etc) are born of the fruits of this team’s efforts. They were not expected to respond to the internal help channel but would be available for ’escalations’ from the sustaining team. Finally, they were expected to help mentor and train members of the sustaining team for eventual promotion onto the development team.
I drafted up a team contract describing this division of labor and setting some loose SLAs for internal help issues and shopped the contract around a bit. With some tweaking, the team adopted the contract and we shared it with our SA and Support teams, and we’ve been following this model ever since.
We still do issue triage and sprint planning together as a group (for lots of reasons), but generally Keith and I focus on driving CPA forward and cutting new releases about every 12 weeks while Jim and Yorvi focus on delivering back-ports and bugfixes in point releases. It’s worked out really well for us so far and everyone on the team is much happier. Jim has stepped up to be the unofficial lead for the sustaining team, and is the Release Manager for point releases, which freed up a significant amount of my time.
Along the way, we decided to have the Sustaining team ’take the lead’ on bugfixes against the development branch as well, both as a mentored learning experience and because they usually end up having to back-port the fix to release branches anyway. This has also helped us to increase development velocity. 🏁
Is there more tweaking to be done? Probably. Could we use another body or two? Of course. Does this structure work for us, make everyone happier, and increase our productivity? Absolutely.
In my next post, I’ll go more into how we’ve adopted agile (little ‘a’), and some of the tooling we use. See you then!
:wq