Return to Answer

It's funny how you say that you feel unchallanged on a technical position - those require a lot of efforts to learn while management is mostly about simply being smart and empathic :) Anyway, I think these are the most important things you need when it comes to the processes:

1. Critical mindset. There are a lot of coaches and managers who like to tell you how you should or shouldn't do things. But in reality it's very likely that they don't know themselves. A lot of popular practices in management are ineffective, outdated, made-up. So don't forget to think.
2. I'd advise reading The Goal and The Goal II about applying Theory of Constraints. Even though they are not about project management per se (more about manufacturing), they open eyes on what it's like for business/teams to be effective. And these ideas can (and should) be used in PM.
3. You'll often hear about Lean, Just-in-time and Kanban in IT management circles. But it's usually hard to figure out what they are and how they came to life w/o reading the original work The Machine That Changed the World. It talks about history of car manufacturing so to me personally it was super boring. But it's better than reading 10 derivative books.
4. One of the derivative books on Just-in-time is Kanban, by David Anderson. This is the original book about applying Just-in-time in software projects and many people would reference it. So it's worth reading. Just-in-time is very similar to Theory of Constraints especially in IT, so it's better to read it after you grasped ToC. BTW, don't trust that JIT is only for maintenance projects.
5. And finally the most technical book in the list is Continuous Delivery. Very repetitive hence the most boring book ever, but you can't skip it (though maybe there are alternatives). Talks about how to branch, set up your pipelines and build servers, how to build, deploy and develop features, etc.
6. Can't say it's super useful but it's super interesting for sure: The Phoenix Project. Talks about what DevOps is (many people think it's a role in the team), shows a good example of transformation from typical projects to Continuous Delivery. Of how bad things are when you work only on critical tasks and don't spend time improving the process itself. Many ideas are also based on ToC.

Try to make long pauses (at least several months) between the books, it takes time for the information to settle. But note that w/o applying these on practice you won't know which advice from these books work and which don't (or when they work and when they don't). So don't believe them blindly - check them.

And no matter how good you're in PM if your team, stakeholders or product suck - it's hard to succeed.

As for the tools - the easier the better. Atlassian stack is complicated, expensive and its focus has shifted from "being awesome company" to "earning as much as possible". So personally I'm skeptical about it. But yes - it's the most powerful stack.

You may try playing with Trello (which now is also Atlassian so who knows for how long it's going to stay awesome) & GitHub projects. Though they don't integrate Test documentation which means you'll have to find tools elsewhere (like testpad).

But if your goal is to be attractive on the job market, then JIRA & Confluence are the tools of choice.

It's funny how you say that you feel unchallanged on a technical position - those require a lot of efforts to learn while management is mostly about simply being smart and empathic :) Anyway, I think these are the most important things you need when it comes to the processes:

1. Critical mindset. There are a lot of coaches and managers who like to tell you how you should or shouldn't do things. But in reality it's very likely that they don't know themselves. A lot of popular practices in management are ineffective, outdated, made-up. So don't forget to think.
2. I'd advise reading The Goal and The Goal II about applying Theory of Constraints. Even though they are not about project management per se (more about manufacturing), they open eyes on what it's like for business/teams to be effective. And these ideas can (and should) be used in PM.
3. You'll often hear about Lean, Just-in-time and Kanban in IT management circles. But it's usually hard to figure out what they are and how they came to life w/o reading the original work The Machine That Changed the World. It talks about history of car manufacturing so to me personally it was super boring. But it's better than reading 10 derivative books.
4. One of the derivative books on Just-in-time is Kanban, by David Anderson. This is the original book about applying Just-in-time in software projects and many people would reference it. So it's worth reading. Just-in-time is very similar to Theory of Constraints especially in IT, so it's better to read it after you grasped ToC. BTW, don't trust that JIT is only for maintenance projects.
5. And finally the most technical book in the list is Continuous Delivery. Very repetitive hence the most boring book ever, but you can't skip it (though maybe there are alternatives). Talks about how to branch, set up your pipelines and build servers, how to build, deploy and develop features, etc.
6. Can't say it's super useful but it's super interesting for sure: The Phoenix Project. Talks about what DevOps is (many people think it's a role in the team), shows a good example of transformation from typical projects to Continuous Delivery. Of how bad things are when you work only on critical tasks and don't spend time improving the process itself. Many ideas are also based on ToC.

Try to make long pauses (at least several months) between the books, it takes time for the information to settle. But note that w/o applying these on practice you won't know which advice from these books work and which don't (or when they work and when they don't). So don't believe them blindly - check them.

And no matter how good you're in PM if your team, stakeholders or product suck - it's hard to succeed.

As for the tools - the easier the better. Atlassian stack is complicated, expensive and its focus has shifted from "being awesome company" to "earning as much as possible". So personally I'm skeptical about it. But yes - it's the most powerful stack.

You may try playing with Trello (which now is also Atlassian so who knows for how long it's going to stay awesome) & GitHub projects. Though they don't integrate Test documentation which means you'll have to find tools elsewhere (like testpad).

But if your goal is to be attractive on the job market, then JIRA & Confluence are the tools of choice.

It's funny how you say that you feel unchallanged on a technical position - those require a lot of efforts to learn while management is mostly about simply being smart and empathic :) Anyway, I think these are the most important things you need when it comes to the processes:

1. Critical mindset. There are a lot of coaches and managers who like to tell you how you should or shouldn't do things. But in reality it's very likely that they don't know themselves. A lot of popular practices in management are ineffective, outdated, made-up. So don't forget to think.
2. I'd advise reading The Goal and The Goal II about applying Theory of Constraints. Even though they are not about project management per se (more about manufacturing), they open eyes on what it's like for business/teams to be effective. And these ideas can (and should) be used in PM.
3. You'll often hear about Lean, Just-in-time and Kanban in IT management circles. But it's usually hard to figure out what they are and how they came to life w/o reading the original work The Machine That Changed the World. It talks about history of car manufacturing so to me personally it was super boring. But it's better than reading 10 derivative books.
4. One of the derivative books on Just-in-time is Kanban, by David Anderson. This is the original book about applying Just-in-time in software projects and many people would reference it. So it's worth reading. Just-in-time is very similar to Theory of Constraints especially in IT, so it's better to be read it after you grasped ToC.
5. And finally the most technical book in the list is Continuous Delivery. Very repetitive hence the most boring book ever, but you can't skip it (though maybe there are alternatives). Talks about how to branch, set up your pipelines and build servers, how to build, deploy and develop features, etc.
6. Can't say it's super useful but it's super interesting for sure: The Phoenix Project. Talks about what DevOps is (many people think it's a role in the team), shows a good example of transformation from typical projects to Continuous Delivery. Of how bad things are when you work only on critical tasks and don't spend time improving the process itself. Many ideas are also based on ToC.

Try to make long pauses (at least several months) between the books, it takes time for the information to settle. But note that w/o applying these on practice you won't know which advice from these books work and which don't (or when they work and when they don't). So don't believe them blindly - check them.

And no matter how good you're in PM if your team, stakeholders or product suck - it's hard to succeed.

As for the tools - the easier the better. Atlassian stack is complicated, expensive and its focus has shifted from "being awesome company" to "earning as much as possible". So personally I'm skeptical about it. But yes - it's the most powerful stack.

You may try playing with Trello (which now is also Atlassian so who knows for how long it's going to stay awesome) & GitHub projects. Though they don't integrate Test documentation which means you'll have to find tools elsewhere (like testpad).

But if your goal to be attractive on the job market, then JIRA & Confluence are the tools of choice.

It's funny how you say that you feel unchallanged on a technical position - those require a lot of efforts to learn while management is mostly about simply being smart and empathic :) Anyway, I think these are the most important things you need when it comes to the processes:

1. Critical mindset. There are a lot of coaches and managers who like to tell you how you should or shouldn't do things. But in reality it's very likely that they don't know themselves. A lot of popular practices in management are ineffective, outdated, made-up. So don't forget to think.
2. I'd advise reading The Goal and The Goal II about applying Theory of Constraints. Even though they are not about project management per se (more about manufacturing), they open eyes on what it's like for business/teams to be effective. And these ideas can (and should) be used in PM.
3. You'll often hear about Lean, Just-in-time and Kanban in IT management circles. But it's usually hard to figure out what they are and how they came to life w/o reading the original work The Machine That Changed the World. It talks about history of car manufacturing so to me personally it was super boring. But it's better than reading 10 derivative books.
4. One of the derivative books on Just-in-time is Kanban, by David Anderson. This is the original book about applying Just-in-time in software projects and many people would reference it. So it's worth reading. Just-in-time is very similar to Theory of Constraints especially in IT, so it's better to read it after you grasped ToC. BTW, don't trust that JIT is only for maintenance projects.
5. And finally the most technical book in the list is Continuous Delivery. Very repetitive hence the most boring book ever, but you can't skip it (though maybe there are alternatives). Talks about how to branch, set up your pipelines and build servers, how to build, deploy and develop features, etc.
6. Can't say it's super useful but it's super interesting for sure: The Phoenix Project. Talks about what DevOps is (many people think it's a role in the team), shows a good example of transformation from typical projects to Continuous Delivery. Of how bad things are when you work only on critical tasks and don't spend time improving the process itself. Many ideas are also based on ToC.

Try to make long pauses (at least several months) between the books, it takes time for the information to settle. But note that w/o applying these on practice you won't know which advice from these books work and which don't (or when they work and when they don't). So don't believe them blindly - check them.

And no matter how good you're in PM if your team, stakeholders or product suck - it's hard to succeed.

As for the tools - the easier the better. Atlassian stack is complicated, expensive and its focus has shifted from "being awesome company" to "earning as much as possible". So personally I'm skeptical about it. But yes - it's the most powerful stack.

You may try playing with Trello (which now is also Atlassian so who knows for how long it's going to stay awesome) & GitHub projects. Though they don't integrate Test documentation which means you'll have to find tools elsewhere (like testpad).

But if your goal is to be attractive on the job market, then JIRA & Confluence are the tools of choice.

It's funny how you say that you feel unchallanged on a technical position - those require a lot of efforts to learn while management is mostly about simply being smart and empathic :) Anyway, I think these are the most important things you need:

1. Critical mindset. There are a lot of coaches and managers who like to tell you how you should or shouldn't do things. But in reality it's very likely that they don't know themselves. A lot of popular practices in management are ineffective, outdated, made-up. So don't forget to think.
2. I'd advise reading The Goal and The Goal II about applying Theory of Constraints. Even though they are not about project management per se (more about manufacturing), they open eyes on what it's like for business/teams to be effective. And these ideas can (and should) be used in PM.
3. You'll often hear about Lean, Just-in-time and Kanban in IT management circles. But it's usually hard to figure out what they are and how they came to life w/o reading the original work The Machine That Changed the World. It talks about history of car manufacturing so to me personally it was super boring. But it's better than reading 10 derivative books.
4. One of the derivative books on Just-in-time is Kanban, by David Anderson. This is the original book about applying Just-in-time in software projects and many people would reference it. So it's worth reading. Just-in-time is very similar to Theory of Constraints especially in IT, so it's better to be read it after you grasped ToC.
5. And finally the most technical book in the list is Continuous Delivery. Very repetitive hence the most boring book ever, but you can't skip it (though maybe there are alternatives). Talks about how to branch, set up your pipelines and build servers, how to build, deploy and develop features, etc.
6. Can't say it's super useful but it's super interesting for sure: The Phoenix Project. Talks about what DevOps is (many people think it's a role in the team), shows a good example of transformation from typical projects to Continuous Delivery. Of how bad things are when you work only on critical tasks and don't spend time improving the process itself. Many ideas are also based on ToC.

Try to make long pauses (at least several months) between the books, it takes time for the information to settle. But note that w/o applying these on practice you won't know which advice from these books work and which don't (or when they work and when they don't). So don't believe them blindly - check them.

And no matter how good you're in PM if your team, stakeholders or product suck - it's hard to succeed.

It's funny how you say that you feel unchallanged on a technical position - those require a lot of efforts to learn while management is mostly about simply being smart and empathic :) Anyway, I think these are the most important things you need when it comes to the processes:

1. Critical mindset. There are a lot of coaches and managers who like to tell you how you should or shouldn't do things. But in reality it's very likely that they don't know themselves. A lot of popular practices in management are ineffective, outdated, made-up. So don't forget to think.
2. I'd advise reading The Goal and The Goal II about applying Theory of Constraints. Even though they are not about project management per se (more about manufacturing), they open eyes on what it's like for business/teams to be effective. And these ideas can (and should) be used in PM.
3. You'll often hear about Lean, Just-in-time and Kanban in IT management circles. But it's usually hard to figure out what they are and how they came to life w/o reading the original work The Machine That Changed the World. It talks about history of car manufacturing so to me personally it was super boring. But it's better than reading 10 derivative books.
4. One of the derivative books on Just-in-time is Kanban, by David Anderson. This is the original book about applying Just-in-time in software projects and many people would reference it. So it's worth reading. Just-in-time is very similar to Theory of Constraints especially in IT, so it's better to be read it after you grasped ToC.
5. And finally the most technical book in the list is Continuous Delivery. Very repetitive hence the most boring book ever, but you can't skip it (though maybe there are alternatives). Talks about how to branch, set up your pipelines and build servers, how to build, deploy and develop features, etc.
6. Can't say it's super useful but it's super interesting for sure: The Phoenix Project. Talks about what DevOps is (many people think it's a role in the team), shows a good example of transformation from typical projects to Continuous Delivery. Of how bad things are when you work only on critical tasks and don't spend time improving the process itself. Many ideas are also based on ToC.

Try to make long pauses (at least several months) between the books, it takes time for the information to settle. But note that w/o applying these on practice you won't know which advice from these books work and which don't (or when they work and when they don't). So don't believe them blindly - check them.

And no matter how good you're in PM if your team, stakeholders or product suck - it's hard to succeed.

As for the tools - the easier the better. Atlassian stack is complicated, expensive and its focus has shifted from "being awesome company" to "earning as much as possible". So personally I'm skeptical about it. But yes - it's the most powerful stack.

You may try playing with Trello (which now is also Atlassian so who knows for how long it's going to stay awesome) & GitHub projects. Though they don't integrate Test documentation which means you'll have to find tools elsewhere (like testpad).

But if your goal to be attractive on the job market, then JIRA & Confluence are the tools of choice.