Introducing Feature Coordinators

Our company bootstrapped from one developer (me) into a team of 12 developers. The transition was not always easy: More people means more dev power, but also more communication and alignment needs.

When we reached a team size of 10 in July, we decided to split them team into 3 fairly independent subteams. Last month was the time to get a more serious about managing those teams’ deliverables. We introduced a rotating role called “Feature Coordinator”. In short it’s a rotating form of project management – but it’s also a bit more than that!


A feature coordinator is responsible for managing the progress and launch of a feature. It’s a combination of project management and some technical oversight. It’s not a people-management position like the Team Lead, and it’s not a tech lead role either. The FC ensures that a feature gets built and shipped in an efficient and transparent way. But it’s a bit more than pure project management too: The FC loves product and feature development, and wants a feature to be successful, therefore the FC works closely with PM and helps out with many of the smaller decisions.



Here’s a list of responsibilities. A successful FC needs to be proactive about things though, not just be available on request.



  • will be there for kick-off, planning sessions, ensures meeting notes are written.
  • is responsible for user experience and customer success
  • solicits feedback at spec-, prototype- and beta-level from across the company (specifically from the CS team)
  • maintains a close relationship with the CS representative, keeps CS in the loop about plans and changes
  • presents status of features every one or two weeks to Per, solicits his feedback
  • doesn’t need to decide on technical level, but needs to understand technical implications at all technical levels
  • pragmatic and pro-actively looks for simplifications, especially when reducing scope a bit might result in significant time savings
  • will ensure beta and user testing happens in time, and that feedback is considered



  • keeps team focused, prevents feature creep, but can see and grab opportunities as well. Balancing act.
  • ensures a constant and sustainable rhythm of progress
  • gives space to breathe, refactor and learn, but also expects progress and launches
  • listens to feedback from team and CS rep, raises awareness if problems (for instance code debt, bugs or feature inconsistencies) are mounting


  • keeps trello board up to date
  • conducts regular presentations and gives updates, both online and face-to-face. For instance every couple of weeks after the dev meeting
  • celebrates wins and launches/improvements,
  • considers rollout options (gradual vs bigbang)
  • will launch feature, ensure blog and tweet are taken care of. Doesn’t have to write them, can delegate the work
  • represents at dev meeting, writes meeting notes



Of course feature development remains a team effort: Nobody can check their brain at the office doors, everyone’s input is needed just as before.



The FC role can rotate. This comes with advantages but also with challenges.

At least 3 months committment: It usually takes a few weeks to get on top of things. To make sure we also see the benefits, the minimum rotation should be 3 months.

Clear handover: While it’s fine to “shadow” the current FC, or the “old” FC lending a hand once the role has been passed on, it needs to be clear that only one person is in charge at any given time. This needs to be clearly communicated, as long as no replacement is found the name at the top of this list is still the FC.