Sharing 2 Uncommon PM Approaches I Experienced in a Web3 Startup

Engineers Rotation as PMs, and the Separation of PM and PO (Project Owner) Roles

Camille Pissarro — La Récolte des Foins, Éragny

Outline

0. TL:DR
1. Intro
2. Engineers Rotation as PMs
   - How
   - PM Responsibilities
   - Feedback
3. PM and PO Separation
   - How
   - Feedback
4. Extra
5. Conclusion

0. TL;DR

• After engineers temporarily took on PM roles, there was a noticeable increase in our willingness to assist with PM tasks. While a few enjoyed the rotation and could continue, most preferred to stay in their full-time engineering roles.
• Separating PM and PO roles allowed POs (engineers) to handle technical decisions, like feature requests and task estimation, without worrying about PMs overstepping. PMs, in turn, focused on people management without the pressure to learn coding.

1. Intro

When hanging out with software engineer friends, certain topics always come up: coding style, development methodology… and PMs.

PM can stand for both project management and project manager. While most engineers don’t mind different project management styles, since each project management method has its own pros and cons, it’s the project manager role that often sparks controversy, at least in my experience.

The common complaint is that PMs, not being engineers, oftentimes struggle with practical feature requests and accurate time estimates. While this isn’t entirely fair — PM and engineer are different roles — some PMs learn to code or companies hire ex-engineers to fill the gap.

In this article, I’ll share two alternatives to traditional PM I’ve experienced: rotating engineers into PM roles and separating technical tasks entirely from PMs to POs (engineers).

A bit of context: I’m a web3/crypto engineer who worked at a 10–40 person startup for 3 years. Since this industry is filled with people aged 20–40, if this perspective seems naive and immature, I’d love to hear your more experienced insights. 🫡🙏

2. Engineers Rotation as PMs

One benefit of working in a startup is the flexibility to try out different roles. My previous team experimented with rotating engineers into PM roles every 2 months when our engineer manager burnt out.

How

We adopted a loose biweekly scrum. Thus, with engineers rotating as the PM on a bi-monthly basis, each rotation would cover 4 sprints.

PM Responsibilities

Here’s a list of PM’s duties from my (vague) memory:

1. Hosting 5 types of meetings: daily standups, weekly team syncs, weekly project syncs with project owners, biweekly sprint plannings, and biweekly sprint retros.
2. During weekly meetings, the PM reviewed tasks, discussed progress, addressed issues, adjusted goals, updated Asana, and sent summaries to keep everyone informed.
3. Before sprint planning, the PM collected and estimated tasks with engineers, calculated sprint capacity (4 hours per engineer per day), prioritised tasks, and finalised the sprint plan with engineers and maganers.
4. Sprint retros(retrospectives) were my favourite, as we shared feedback and always had random but interesting discussions! The PM used Asana to organise retro boards with categories like Continue, Start, Stop, and Discussion, as shown in the image below. We also added our own categories: words of appreciation and a fun question for each retro, e.g., “What’s your favourite film?”. During retros, ticket creators would first share their thoughts without interruption, followed by open discussion. Afterward, the PM summarised action items for the next sprint.

Image Source: https://easyretro.io/

Feedback

1. Some engineers, if not most, simply didn’t enjoy PMing. The coordination, communication, and task management drained their energy. 🥲
2. Two engineers, including myself, were open to continuing the rotation. We enjoyed the mix of coding and project management but still valued our coding work too much to consider full-time PM roles.
3. Despite mixed feelings, everyone appreciated experiencing the PM role once. I noticed that we engineers became more proactive in helping PMs, like anticipating needs and offering reminders! 🥳
4. Passion for PMing varied in everyone’s one-month trial. Some engineers experimented with the least interrupting messaging timing, explored different software development methodologies, or added creative elements to retros, while others mostly viewed it as an one-time experience, or a task to complete.

Overall, this experiment helped us not only empathise with PMs, but also explore the engineer-PM path, which is something less likely to happen in larger, more structured companies!

3. PM & PO Separation

During the PM rotation, one thing I didn’t point out earlier was that engineers could act as both PM and PO (project owner), leading to an overwhelming workload. This wasn’t always managed carefully, and might have contributed to the frustration with PMing.

How

After the rotation experiment and the burnout of our engineer manager, the team hired a full-time PM but made a key distinction: the PM wasn’t responsible for technical decisions like feature requests or task estimations.

Instead, project owners would handle these duties. If a task’s timeline needed clarification or a feature needed review, the PM simply contacted the PO and trusted their judgment. The PM focused on administrative issues — arranging meetings, updating statuses, coordinating tasks, and keeping everyone aligned.

What’s more, as the PM’s role became less technical and thus lighter, they could also assist with operations or marketing when needed!

Feedback

1. This structure made responsibilities clearer: POs handled engineering decisions, and the PM managed administrative and people-related tasks.
2. Engineers, especially those with traditional PM experience, appreciated that the PM didn’t interfere with technical decisions, making collaboration smoother. 😍
3. Compared to the previous rotation experiment, this approach was far less stressful for POs. They could focus on coding and project-related tasks without constant interruptions, which was a major pain point in the previous setup.

4. Extra

On the topic of our one fun question each retro, I came across a kindred spirit in Basecamp’s approach to internal communication and would love to share it with you!

Automatic occasionally: “Social questions”

Every few weeks, or once a month, Basecamp will automatically ask everyone a social-style question. “What books are you reading?” Or “Try anything new lately?” Or “Anything inspire you lately?” Or “Seen any great design recently?” Or “What did you do this weekend?” These entirely optional questions are meant to shake loose some stuff that you’d love to share with everyone else, but you hadn’t had an opportunity to do so. This kind of internal communication helps grease the social gears. This is especially useful for remote teams, like ours. When we know each other a little better, we work a little better together.

Source: The 37signals Guide to Internal Communication

5. Conclusion

I’m extremely grateful for the unique experiences from my previous job. Both approaches — rotating engineers as PMs and separating PM from PO roles —gave me valuable insights into project management and collaboration!

Although I’m still an engineer at heart, needing coding to stay energised and challenged, I’m open to stepping into a PM role occasionally to explore the non-engineering side of software development!

Have you ever tried these PM alternatives, or even different ones? Feel free to leave a comment down below to share with me! 🤗

Thank you for reading to the end, and until next time!

Thanks to ChatGPT for reviewing!