Titles evolve as we go, and I've seen both folks doing the same job while having different titles, and folks with the same title doing very different jobs. If you are looking into acquiring skills in these areas, I would look at job descriptions with similar titles from a few companies that you would like to work for, and develop my learning plan based on the common denominators of these job descriptions.

1. My calendar. As you get away from the development work and into PM work, you get involved in a lot of meetings, and effective time management becomes crucial.

2. OneNote. I use OneNote as my "external memory", having notes and resource links for all major projects. It magically syncs across all of my devices, so I can access my notes anywhere, any time.

3. Project management tools. It's important to be able to visualize work-in-progress, so you can have a view of team capacity and project progress.

4. Communication tools. I talk to a lot of folks inside and outside the company, so I have every possible communication app in existence installed on all of my devices :)

Engineering transition:

In my career, I transitioned through first doing other customer-facing roles, like consulting and technical sales. Look into gaining skills at communicating with customers, and communicating across teams in your organization.

Books:

1. I really like the book "Platform Revolution". It is not about product management in a traditional sense, but it gives insight into why some products are becoming highly successful in this new connected era.
2. "The Customer-Driven Playbook" is a book about the hypothesis progression framework and converting customer feedback into product success. It emphasizes the importance of collecting customer feedback, instead of just trusting your own assumptions.

Also, please consider my answer to Marcus Hicks, as I think the Maker vs Manager framework is very helpful in understanding this transition.

I am biased here, but I would check GitHub Actions and Azure Pipelines / App Center for mobile development. All of these platforms offer cloud-hosted Mac OS build agents (as well as Windows and Linux agents), which removes the need to buy and manage Mac machines for iOS development.

I have seen many teams having reservations about hiring remote PMs because they worry about their ability to be effective.

1. Apply to companies that are fully remote. You are at a disadvantage if the development team is co-located, and you are remote and/or in a different time zone. It is a lot easier to be successful if the rest of the team is distributed.

2. Show experience in managing remote projects. For instance, many of the open-source project teams are highly distributed, and if you can show success in that space, the company is more likely to trust you.

This is a tough question as DevOps may mean different things to different people. I will use the acronym DevOps CALMS, which comprises - Culture, Automation, Lean, Measurement, and Sharing. Technically, you are learning DevOps if you are advancing your knowledge in any of these areas, but developers often tend to focus on the automation part.

On the automation side, I would start with the fundamental Continuous Delivery book. It has just turned 10 years old, but it still has the most relevant fundamental advice on how to approach implementing Continuous Integration and Continuous Delivery (CI/CD). Once you understand the concepts, you can start learning any of the CI/CD tools on the market. The tool choice is usually driven by your company, but I will, of course, suggest GitHub Actions :)

My best advice is to get the right people on the team. At DevOpsDays Chicago we have a great team, and I know from working on some other community projects that this is hard to find. Having a "core" team of 2-3 people who have the time and energy to contribute, and get along well is crucial. Then, you can add more folks who may have less time, but will help you move the project forward. The biggest challenge I had with other community projects is that people sign up for more than they have time to deliver, and then go dark. This one is not easy to solve. Communicate your contribution expectations clearly from the beginning, and hone and reiterate them as you go. And expect that 30-40% of folks that seemed enthusiastic in the beginning will drop off the project.

This is very helpful, thank you. Sasha Rosenbaum

I have seen a lot of folks publish advice on working from home (WFH), so I don't think I need to add to that. The important thing for companies right now is to realize that this isn't a regular WFH situation. People suddenly have multiple family members working from home, kids being home schooled, pets and other family members sharing the same space, and little to no home office setup. I think that the most important thing that GitHub leadership has communicated is that we are essentially lowering our expectations of engineering productivity, because we realize that the crisis is impacting most of us. I believe that communicating that clearly increases the psychological safety on the team.

Thank you Sasha Rosenbaum