Taro Logo
1

How to answer when I don't have justification about something that I have written based on what others told?

Profile picture
Anonymous User at Taro Communitya year ago

I am in a new team. I was given a task to provide estimations on a project that involves various components. 2 components were owned by a different team and they were transferred to my team. I have no idea about those components. My senior engineer told me to contact a person to get estimation from someone in a sister team who previously worked on that component. This person gave me estimates as 8 and 10 weeks and didn't get response when I asked if he could share some details. I didn't try to deep dive as these components are again getting transferred to a different team. Nobody in my team has knowledge about these two components.

In the meeting where all teams in the org were present, reviewing the estimates. My senior director asked justification for the estimates, the person who gave me the estimates told I have written the estimates. So I told I don't have details and written the estimates as per this person.

I often get stuck in these type of awkward situations. This is clearly not an onboarding task. How can I deal with these situations and how I could have communicated better?

57
2

Discussion

(2 comments)
  • 1
    Profile picture
    Robinhood, Meta, Course Hero, PayPal
    a year ago

    A lot of "awkwardness" comes from your own self-perception. This means that a lot of it goes away when you project confidence. When you don't think you are in control of a situation, other people will think you aren't in control of a situation when they see you communicate. Similarly, if you feel self-empowered and believe that you are in control of the situation (even if there's unknowns), that energy will flow into how you talk and behave, making it much more likely for your teammates to believe that you've got things locked down. Here's my advice on how to act more assertively in the workplace.

    Your situation is a common one that I've seen with a lot of junior/mid-level engineers (with some seniors as well): You don't have all the information you think you should have. The process to fix this is pretty much this:

    1. Figure out what information you need to confidently show people that you know what you're doing
    2. Get that information and follow up accordingly

    This person gave me estimates as 8 and 10 weeks and didn't get response when I asked if he could share some details.

    This was the first mistake IMHO. Estimates are useless if they aren't justified - Since this person already spent some time producing the estimates, might as well follow up to get the explanations. Be polite but firm, and if they keep ghosting you, rope in your manager to grease the communication line "wheels". Explain the context behind your request as well - Clearly this estimation task was pretty important if a Senior Director asked about it!

    I didn't try to deep dive as these components are again getting transferred to a different team.

    This will happen a lot in bigger tech companies, and the best software engineers will make sure that these hand-offs are clean instead of just letting them happen and float out of their mental space. I would have followed up with this new team and let them know that estimates are needed for these components. From there, I would have connected them with the original owner of these components and let them follow up on procuring the estimates.

    Lastly, this is largely an exercise in communication, so I highly recommend going through my entire series on Effective Communication here.

  • 0
    Profile picture
    Meta, Pinterest, Kosei
    a year ago

    This is an example of "prevention is the best cure" -- any estimation should come with at least some level of justification.

    It feels odd that the engineer who said 8-10 weeks offered that without explanation, and you probably should have asked for that detail immediately.

    For this immediate problem, you could spend a bit of time going through the team wiki to see if there is something defensible there. Many teams will publish a roadmap of their projects, and that can be helpful to justify within your team about the dependencies you have.