Mixing
![I want to ask my boss about my career status [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
How to help with technical planning for a project I am not familiar with?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
For context, I am one engineer in a group of engineers and we have an engineering manager and a project manager.
My team works on a product and for a few months one of our team members has been working on a different architecture that should solve a lot of issues we have in our current product.
There are a lot of new things, not only in some features, but also in how it is architected and the technical stack. Because Features requests have not stopped coming in from clients for the current product, we have had him working on the project while the rest of the team has worked on features.
We've hit the point where we are starting to make deadlines for this new project and so recently there have been a bunch of planning meetings to figure out "what is left" and "what exactly we need to do" where the team gets together to talk about what we need to do.
The issue I feel is that many members of the team, including myself, are not familiar with the project from a technical standpoint (we know about it but not in enough technical detail to comment what is left and what we can break out into different tasks for ourselves) other than the main engineer working on it and the engineering manager. We were given a technical overview of the current status of the project but I feel that's not truly enough to actually breakdown the project. It's hard for the other members of the team to comment when we have not worked on it.
So I have a few questions
Is it the job of the other engineers to help break down all the tasks? I feel like we can comment on implementation but it's hard for any of us to comment what is left -- to me it seems like this is something the PM and the main engineer need to do? I could be wrong though.
What can I do exactly to help with this? Should I try to sit one-on-one with someone to see where I fit in?
One last thing: I also have my day-to-day stuff as an engineer to do (there are still features that need to be implemented and timelines I have to follow) and I don't think it makes sense for me to be doing this if it's not my responsibility (Maybe it IS my responsibility as an engineer to help out with this planning)
management communication project-management planning
edited Jul 14 '16 at 12:22
Raoul Mensink
1,267317
asked Jul 13 '16 at 18:34
Kevin Xu
2,01731124
suggest improvements |Â
up vote
3
down vote
favorite
For context, I am one engineer in a group of engineers and we have an engineering manager and a project manager.
My team works on a product and for a few months one of our team members has been working on a different architecture that should solve a lot of issues we have in our current product.
There are a lot of new things, not only in some features, but also in how it is architected and the technical stack. Because Features requests have not stopped coming in from clients for the current product, we have had him working on the project while the rest of the team has worked on features.
We've hit the point where we are starting to make deadlines for this new project and so recently there have been a bunch of planning meetings to figure out "what is left" and "what exactly we need to do" where the team gets together to talk about what we need to do.
The issue I feel is that many members of the team, including myself, are not familiar with the project from a technical standpoint (we know about it but not in enough technical detail to comment what is left and what we can break out into different tasks for ourselves) other than the main engineer working on it and the engineering manager. We were given a technical overview of the current status of the project but I feel that's not truly enough to actually breakdown the project. It's hard for the other members of the team to comment when we have not worked on it.
So I have a few questions
Is it the job of the other engineers to help break down all the tasks? I feel like we can comment on implementation but it's hard for any of us to comment what is left -- to me it seems like this is something the PM and the main engineer need to do? I could be wrong though.
What can I do exactly to help with this? Should I try to sit one-on-one with someone to see where I fit in?
One last thing: I also have my day-to-day stuff as an engineer to do (there are still features that need to be implemented and timelines I have to follow) and I don't think it makes sense for me to be doing this if it's not my responsibility (Maybe it IS my responsibility as an engineer to help out with this planning)
management communication project-management planning
edited Jul 14 '16 at 12:22
Raoul Mensink
1,267317
asked Jul 13 '16 at 18:34
Kevin Xu
2,01731124
I would organise a hacking day or something before talking a lot. Work on some issues together. The working developer on new should not work but help the others. That gives room for discussion and introduction. Only when you do something like that you get a real feeling on it. The other steps may go easier after that. What might happen is a lot of discussion. That may be good, a single developer can miss things. But it can also be bad, broader insights show huge weaknesses to the new project. Question: is there a spec and potentially even some user stories?
– Luc Franken
Jul 13 '16 at 20:13
@LucFranken That's the thing -- I don't think there really is a spec (a lot of it was figure as you go) and I don't think there are any user stories yet either. I do think the hacking day sounds like a good idea to get us all onboarded though
– Kevin Xu
Jul 13 '16 at 20:35
1
And working on the requirements will also be priority and a good thing to work on together. It will both enable a deeper customer understanding and a basis for creating tasks. Because: how would you ever be able to write tasks if the requirements are unclear?
– Luc Franken
Jul 13 '16 at 20:38
suggest improvements |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
For context, I am one engineer in a group of engineers and we have an engineering manager and a project manager.
My team works on a product and for a few months one of our team members has been working on a different architecture that should solve a lot of issues we have in our current product.
There are a lot of new things, not only in some features, but also in how it is architected and the technical stack. Because Features requests have not stopped coming in from clients for the current product, we have had him working on the project while the rest of the team has worked on features.
We've hit the point where we are starting to make deadlines for this new project and so recently there have been a bunch of planning meetings to figure out "what is left" and "what exactly we need to do" where the team gets together to talk about what we need to do.
The issue I feel is that many members of the team, including myself, are not familiar with the project from a technical standpoint (we know about it but not in enough technical detail to comment what is left and what we can break out into different tasks for ourselves) other than the main engineer working on it and the engineering manager. We were given a technical overview of the current status of the project but I feel that's not truly enough to actually breakdown the project. It's hard for the other members of the team to comment when we have not worked on it.
So I have a few questions
Is it the job of the other engineers to help break down all the tasks? I feel like we can comment on implementation but it's hard for any of us to comment what is left -- to me it seems like this is something the PM and the main engineer need to do? I could be wrong though.
What can I do exactly to help with this? Should I try to sit one-on-one with someone to see where I fit in?
One last thing: I also have my day-to-day stuff as an engineer to do (there are still features that need to be implemented and timelines I have to follow) and I don't think it makes sense for me to be doing this if it's not my responsibility (Maybe it IS my responsibility as an engineer to help out with this planning)
management communication project-management planning
edited Jul 14 '16 at 12:22
Raoul Mensink
1,267317
asked Jul 13 '16 at 18:34
Kevin Xu
2,01731124
For context, I am one engineer in a group of engineers and we have an engineering manager and a project manager.
My team works on a product and for a few months one of our team members has been working on a different architecture that should solve a lot of issues we have in our current product.
There are a lot of new things, not only in some features, but also in how it is architected and the technical stack. Because Features requests have not stopped coming in from clients for the current product, we have had him working on the project while the rest of the team has worked on features.
We've hit the point where we are starting to make deadlines for this new project and so recently there have been a bunch of planning meetings to figure out "what is left" and "what exactly we need to do" where the team gets together to talk about what we need to do.
The issue I feel is that many members of the team, including myself, are not familiar with the project from a technical standpoint (we know about it but not in enough technical detail to comment what is left and what we can break out into different tasks for ourselves) other than the main engineer working on it and the engineering manager. We were given a technical overview of the current status of the project but I feel that's not truly enough to actually breakdown the project. It's hard for the other members of the team to comment when we have not worked on it.
So I have a few questions
Is it the job of the other engineers to help break down all the tasks? I feel like we can comment on implementation but it's hard for any of us to comment what is left -- to me it seems like this is something the PM and the main engineer need to do? I could be wrong though.
What can I do exactly to help with this? Should I try to sit one-on-one with someone to see where I fit in?
One last thing: I also have my day-to-day stuff as an engineer to do (there are still features that need to be implemented and timelines I have to follow) and I don't think it makes sense for me to be doing this if it's not my responsibility (Maybe it IS my responsibility as an engineer to help out with this planning)
management communication project-management planning
edited Jul 14 '16 at 12:22
Raoul Mensink
1,267317
asked Jul 13 '16 at 18:34
Kevin Xu
2,01731124
edited Jul 14 '16 at 12:22
Raoul Mensink
1,267317
edited Jul 14 '16 at 12:22
Raoul Mensink
1,267317
edited Jul 14 '16 at 12:22
Raoul Mensink
1,267317
1,267317
asked Jul 13 '16 at 18:34
Kevin Xu
2,01731124
asked Jul 13 '16 at 18:34
Kevin Xu
2,01731124
asked Jul 13 '16 at 18:34
Kevin Xu
2,01731124
2,01731124
I would organise a hacking day or something before talking a lot. Work on some issues together. The working developer on new should not work but help the others. That gives room for discussion and introduction. Only when you do something like that you get a real feeling on it. The other steps may go easier after that. What might happen is a lot of discussion. That may be good, a single developer can miss things. But it can also be bad, broader insights show huge weaknesses to the new project. Question: is there a spec and potentially even some user stories?
– Luc Franken
Jul 13 '16 at 20:13
@LucFranken That's the thing -- I don't think there really is a spec (a lot of it was figure as you go) and I don't think there are any user stories yet either. I do think the hacking day sounds like a good idea to get us all onboarded though
– Kevin Xu
Jul 13 '16 at 20:35
1
And working on the requirements will also be priority and a good thing to work on together. It will both enable a deeper customer understanding and a basis for creating tasks. Because: how would you ever be able to write tasks if the requirements are unclear?
– Luc Franken
Jul 13 '16 at 20:38
suggest improvements |Â
I would organise a hacking day or something before talking a lot. Work on some issues together. The working developer on new should not work but help the others. That gives room for discussion and introduction. Only when you do something like that you get a real feeling on it. The other steps may go easier after that. What might happen is a lot of discussion. That may be good, a single developer can miss things. But it can also be bad, broader insights show huge weaknesses to the new project. Question: is there a spec and potentially even some user stories?
– Luc Franken
Jul 13 '16 at 20:13
@LucFranken That's the thing -- I don't think there really is a spec (a lot of it was figure as you go) and I don't think there are any user stories yet either. I do think the hacking day sounds like a good idea to get us all onboarded though
– Kevin Xu
Jul 13 '16 at 20:35
1
And working on the requirements will also be priority and a good thing to work on together. It will both enable a deeper customer understanding and a basis for creating tasks. Because: how would you ever be able to write tasks if the requirements are unclear?
– Luc Franken
Jul 13 '16 at 20:38
I would organise a hacking day or something before talking a lot. Work on some issues together. The working developer on new should not work but help the others. That gives room for discussion and introduction. Only when you do something like that you get a real feeling on it. The other steps may go easier after that. What might happen is a lot of discussion. That may be good, a single developer can miss things. But it can also be bad, broader insights show huge weaknesses to the new project. Question: is there a spec and potentially even some user stories?
– Luc Franken
Jul 13 '16 at 20:13
I would organise a hacking day or something before talking a lot. Work on some issues together. The working developer on new should not work but help the others. That gives room for discussion and introduction. Only when you do something like that you get a real feeling on it. The other steps may go easier after that. What might happen is a lot of discussion. That may be good, a single developer can miss things. But it can also be bad, broader insights show huge weaknesses to the new project. Question: is there a spec and potentially even some user stories?
– Luc Franken
Jul 13 '16 at 20:13
@LucFranken That's the thing -- I don't think there really is a spec (a lot of it was figure as you go) and I don't think there are any user stories yet either. I do think the hacking day sounds like a good idea to get us all onboarded though
– Kevin Xu
Jul 13 '16 at 20:35
@LucFranken That's the thing -- I don't think there really is a spec (a lot of it was figure as you go) and I don't think there are any user stories yet either. I do think the hacking day sounds like a good idea to get us all onboarded though
– Kevin Xu
Jul 13 '16 at 20:35
1
1
And working on the requirements will also be priority and a good thing to work on together. It will both enable a deeper customer understanding and a basis for creating tasks. Because: how would you ever be able to write tasks if the requirements are unclear?
– Luc Franken
Jul 13 '16 at 20:38
And working on the requirements will also be priority and a good thing to work on together. It will both enable a deeper customer understanding and a basis for creating tasks. Because: how would you ever be able to write tasks if the requirements are unclear?
– Luc Franken
Jul 13 '16 at 20:38
suggest improvements |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
I am not sure that it would be all that efficient to have all of the engineers involved in the planning, but certainly having multiple voices involved can help make a better plan.
As to it not being your responsibility. If your team is going to be responsible for building and supporting that system in the future, then it is your responsibility to learn the new architecture and tech stack. You shouldn't wait to the the day before you start working on it to get the details, as some parts of it may need time for consideration to get comfortable.
answered Jul 13 '16 at 19:59
cdkMoose
9,29822042
No that makes sense. Yeah I don't want it to seem like "Oh this isn't my responsibility" but it just seems like there are a lot of missing pieces that the engineers are expected to figure out from a planning standpoint when we should be more focused on the technical implementation and costing out how long it will take us.
– Kevin Xu
Jul 13 '16 at 20:37
@user14287117 suggest a "code Review" not for its normal purpose, but to get Person x to tell everyone in a single Meeting what is done and what not by running through the code he has done, while at the same time giveing him the possibilities to explain what changed
– Raoul Mensink
Jul 14 '16 at 12:25
suggest improvements |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
I am not sure that it would be all that efficient to have all of the engineers involved in the planning, but certainly having multiple voices involved can help make a better plan.
As to it not being your responsibility. If your team is going to be responsible for building and supporting that system in the future, then it is your responsibility to learn the new architecture and tech stack. You shouldn't wait to the the day before you start working on it to get the details, as some parts of it may need time for consideration to get comfortable.
answered Jul 13 '16 at 19:59
cdkMoose
9,29822042
No that makes sense. Yeah I don't want it to seem like "Oh this isn't my responsibility" but it just seems like there are a lot of missing pieces that the engineers are expected to figure out from a planning standpoint when we should be more focused on the technical implementation and costing out how long it will take us.
– Kevin Xu
Jul 13 '16 at 20:37
@user14287117 suggest a "code Review" not for its normal purpose, but to get Person x to tell everyone in a single Meeting what is done and what not by running through the code he has done, while at the same time giveing him the possibilities to explain what changed
– Raoul Mensink
Jul 14 '16 at 12:25
suggest improvements |Â
up vote
2
down vote
accepted
I am not sure that it would be all that efficient to have all of the engineers involved in the planning, but certainly having multiple voices involved can help make a better plan.
As to it not being your responsibility. If your team is going to be responsible for building and supporting that system in the future, then it is your responsibility to learn the new architecture and tech stack. You shouldn't wait to the the day before you start working on it to get the details, as some parts of it may need time for consideration to get comfortable.
answered Jul 13 '16 at 19:59
cdkMoose
9,29822042
No that makes sense. Yeah I don't want it to seem like "Oh this isn't my responsibility" but it just seems like there are a lot of missing pieces that the engineers are expected to figure out from a planning standpoint when we should be more focused on the technical implementation and costing out how long it will take us.
– Kevin Xu
Jul 13 '16 at 20:37
@user14287117 suggest a "code Review" not for its normal purpose, but to get Person x to tell everyone in a single Meeting what is done and what not by running through the code he has done, while at the same time giveing him the possibilities to explain what changed
– Raoul Mensink
Jul 14 '16 at 12:25
suggest improvements |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
I am not sure that it would be all that efficient to have all of the engineers involved in the planning, but certainly having multiple voices involved can help make a better plan.
As to it not being your responsibility. If your team is going to be responsible for building and supporting that system in the future, then it is your responsibility to learn the new architecture and tech stack. You shouldn't wait to the the day before you start working on it to get the details, as some parts of it may need time for consideration to get comfortable.
answered Jul 13 '16 at 19:59
cdkMoose
9,29822042
I am not sure that it would be all that efficient to have all of the engineers involved in the planning, but certainly having multiple voices involved can help make a better plan.
As to it not being your responsibility. If your team is going to be responsible for building and supporting that system in the future, then it is your responsibility to learn the new architecture and tech stack. You shouldn't wait to the the day before you start working on it to get the details, as some parts of it may need time for consideration to get comfortable.
answered Jul 13 '16 at 19:59
cdkMoose
9,29822042
answered Jul 13 '16 at 19:59
cdkMoose
9,29822042
answered Jul 13 '16 at 19:59
cdkMoose
9,29822042
answered Jul 13 '16 at 19:59
cdkMoose
9,29822042
9,29822042
No that makes sense. Yeah I don't want it to seem like "Oh this isn't my responsibility" but it just seems like there are a lot of missing pieces that the engineers are expected to figure out from a planning standpoint when we should be more focused on the technical implementation and costing out how long it will take us.
– Kevin Xu
Jul 13 '16 at 20:37
@user14287117 suggest a "code Review" not for its normal purpose, but to get Person x to tell everyone in a single Meeting what is done and what not by running through the code he has done, while at the same time giveing him the possibilities to explain what changed
– Raoul Mensink
Jul 14 '16 at 12:25
suggest improvements |Â
No that makes sense. Yeah I don't want it to seem like "Oh this isn't my responsibility" but it just seems like there are a lot of missing pieces that the engineers are expected to figure out from a planning standpoint when we should be more focused on the technical implementation and costing out how long it will take us.
– Kevin Xu
Jul 13 '16 at 20:37
@user14287117 suggest a "code Review" not for its normal purpose, but to get Person x to tell everyone in a single Meeting what is done and what not by running through the code he has done, while at the same time giveing him the possibilities to explain what changed
– Raoul Mensink
Jul 14 '16 at 12:25
No that makes sense. Yeah I don't want it to seem like "Oh this isn't my responsibility" but it just seems like there are a lot of missing pieces that the engineers are expected to figure out from a planning standpoint when we should be more focused on the technical implementation and costing out how long it will take us.
– Kevin Xu
Jul 13 '16 at 20:37
No that makes sense. Yeah I don't want it to seem like "Oh this isn't my responsibility" but it just seems like there are a lot of missing pieces that the engineers are expected to figure out from a planning standpoint when we should be more focused on the technical implementation and costing out how long it will take us.
– Kevin Xu
Jul 13 '16 at 20:37
@user14287117 suggest a "code Review" not for its normal purpose, but to get Person x to tell everyone in a single Meeting what is done and what not by running through the code he has done, while at the same time giveing him the possibilities to explain what changed
– Raoul Mensink
Jul 14 '16 at 12:25
@user14287117 suggest a "code Review" not for its normal purpose, but to get Person x to tell everyone in a single Meeting what is done and what not by running through the code he has done, while at the same time giveing him the possibilities to explain what changed
– Raoul Mensink
Jul 14 '16 at 12:25
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f71293%2fhow-to-help-with-technical-planning-for-a-project-i-am-not-familiar-with%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I would organise a hacking day or something before talking a lot. Work on some issues together. The working developer on new should not work but help the others. That gives room for discussion and introduction. Only when you do something like that you get a real feeling on it. The other steps may go easier after that. What might happen is a lot of discussion. That may be good, a single developer can miss things. But it can also be bad, broader insights show huge weaknesses to the new project. Question: is there a spec and potentially even some user stories?
– Luc Franken
Jul 13 '16 at 20:13
@LucFranken That's the thing -- I don't think there really is a spec (a lot of it was figure as you go) and I don't think there are any user stories yet either. I do think the hacking day sounds like a good idea to get us all onboarded though
– Kevin Xu
Jul 13 '16 at 20:35
1
And working on the requirements will also be priority and a good thing to work on together. It will both enable a deeper customer understanding and a basis for creating tasks. Because: how would you ever be able to write tasks if the requirements are unclear?
– Luc Franken
Jul 13 '16 at 20:38