3

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)

Improve this question
3
  • 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
    Commented Jul 13, 2016 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
    Commented Jul 13, 2016 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
    Commented Jul 13, 2016 at 20:38

1 Answer 1

Reset to default
2

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.

Improve this answer
2
  • 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
    Commented Jul 13, 2016 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
    Commented Jul 14, 2016 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .