Get my email lessons on how you can build a tech team you can depend on.

I guess Ananya’s situation looked familiar.

Last Saturday I sent out a situation and asked if it looked familiar, and what you might do about it.

I got quite a few responses, and summarize them here.

Original post: Does this sound familiar?

Here’s what you wrote:

Edith write:

  • After Ananya asks you “which class?”, you should have asked what she thought.
  • Just because you’re almost done with an approach, should reflect if it was the right approach. if not, then it’s ok to redo, after talking with the right folks, or maybe the feature needs to get pushed out to the next sprint.
  • Never assume, always ask for confirmation or clarification.

James wrote:

  • Why is she asking? When someone asks a question like that, it likely means they don’t, yet, know enough about how the system is engineered.
  • This should be used as a teachable moment to help her understand the system design and how to do the right thing.
  • And while discussing it, a little bit of ‘pair design’ would happen and Ananya might just end up getting it done in 2 hours instead of 2 weeks.

Durga wrote:

  • When she came to you with a question she has to come with most of the analysis done, if not before giving our opinion we should think about the existing system and ask questions like what are the other possible places we can add this.

Kat Lim wrote:

  • My reaction would be to tell him/her that she needs to question more the decisions I make regardless of my position, and if she had done that, the task would take much faster and already done.
  • That is what I always tell all developers and testers, do not assume. Always ask.

Raúl wrote:

  • It seems like the original method implementation is already married with an approach. Plus, a “you told me” argument.
  • Let’s have a brief talk with Anaya. Let’s not discard the effort she already put in. Tell her that she has agency over the codebase, it is ok to change the original approach.
  • For future occasions try to spot “I told you” or “You told me” arguments prematurely, see if we can change the sentence; “You told me” does not equal accountability.

Markus wrote:

  • I avoid this situation by putting a counter-question like “What do you suggest to do?” (really always, I start this approach with trainees from the first day on). I am trying to turn the situation into the developer describing different options and me giving opinions (and asking further questions).
  • Sometimes team members are surprised by this approach and feel uncomfortable to make a decision or suggestion. I tell them “Look, you are a very skilled developer. You have diligently looked at the different options for hours and weighed advantages and downsides. Now you expect me to make a better decision in 5 minutes than you could make in 2 hours. I feel honored that you think I can do this but you greatly overestimate my skills.”.

Sam wrote:

  • I see two people in a power dynamic. Marcus seems to be a senior dev/responsible person who is perceived as more powerful, knowledgeable or experienced than Ananya.
  • Ananya is facing a challenge and seeks assistance. She’s aware of the power dynamic and probably underestimates her own skill dramatically and overestimates the skill of her senior dev. Instead of asking for more context which would empower her to make a decision, she delegates the decision to the person she perceives as being “responsible”: Marcus.
  • Marcus, on the other hand, seems not to be aware of the power dynamic and reacts in a way that might have been familiar for him in the past: He makes a decision, implying that he has enough context to do so. It’s very likely that he is not aware of Ananya underestimating her skills, it’s also very likely he doesn’t notice the decision delegation.

Kevin wrote:

  • Marcus has disempowered Ananya from leveraging her critical thinking skills by providing the answer right away. Ananya feels unable or unwilling to raise the flag about the incorrect solution provided.
  • Ananya has assumed intent on Marcus’ part, partially because he provided no context to his previous answer.
  • Assumptions are killer. It’s hard to remember sometimes, but explaining the reasoning behind a design/business decision can save grief down the road.

Luisa wrote:

  • Micromanagement? 🙂 Maybe Ananya should have investigated better and not asked her manager? 🙂

Ferit wrote:

  • Missing Trust. Ananya seems to blindly do what Marcus is saying b/c of is role/position even when she already has an idea where to start working on it.
  • Her question is also too specific so it’s easy to just answer it with “put it into class X” w/o thinking a lot.

Cathy wrote:

  • This is probably a manager giving an answer to someone that probably could answer the question themselves.
  • It is a lack of communication when neither person engaged in a discussion. It should have been a two-way conversation, especially when the person identified the larger effort to use the chosen class.

There’s a lot to digest here. Power dynamics, assumptions, a “you told me to” argument, and two people not communicating very well.

What ideas might you decide to take back to your job?

Who would benefit if you shared this with them?

Take care,


About Marcus Blankenship

Where other technical coaches focus on process or tools, I focus on the human aspects of your Programmer to Manager transition. I help you hire the right people, create the right culture, and setup the right process which achieves your goals. Managing your team isn't something you learned in college. In fact, my clients often tell me "I never prepared for this role, I always focused on doing the work". If you're ready to improve your leadership, process and team, find out how I can help you.

Pin It on Pinterest

Share This