Skip to main content

I would not concentrate too much about the decisions that were taken. The important information here is: they took upon themselves to have a meeting without you about things that were you responsabilityresponsibility. It shows a lostloss of confidence in you.

You need to understand where does that comecame from in the first place. You look like to be technically adequate withconsidering what was asked offrom you: you convinced them as such. But they didn't hired you because you are technically good, they hired you to fix a problem they had and thought you could do that.

I can see multiple issues that could happen with this dissonance (the fact you think they hired you for one thing, comparecompared with the real reason):

  1. Lack of goals:
  • Did they tell you what they expected of you?
  • Did you askedask what they wanted?
  • Did you miss something when they told you?
  • Maybe you heard: "We want quality software!" when they meant "We want a software that people use!".
  1. lack of transparency: You arrive at this new job and you apply all the best practice known in your fields.
  • How did you communicate about it?
  • Did you go too fast?
  • Was everybody aware of the consequences because there is always a trade off?
  • Did you explain the learning curve will hurt productivity?
  1. Support from below: Your methodology impacted the lifeslives of your team, they need to be convinced they are going into the right direction.

I can only speculate at this point but I can see why, in the space of few months, the devs freaked out because they don't see the added value (yet) of the changes and your bosses freaked out because the features are not coming as fast as they thought you would deliver and the devs are coming togetting back at them, unhappy.

You have to learn from this experience for the next time as things are pretty advanced in your case.

But if there is anything to save, it is through trust and patience. If anything,

  • go alongGo with the flow by acknowledging the problems they brought up.
  • Accept most of their changes and add your most valuable points (only on thatthe condition you would see a future here)
  • Make a planningschedule to reintroduce the best practices slowly but surely, explaining what problems thosesthose methods are fixing (no need offor parachutes in cars, but a sitseat belt can help ;)

Convince people to be on your side, whatever the cost, because if you cannot do that, your battle is lost.

I would not concentrate too much about the decisions that were taken. The important information here is: they took upon themselves to have a meeting without you about things that were you responsability. It shows a lost of confidence in you.

You need to understand where does that come from in the first place. You look like to be technically adequate with what was asked of you: you convinced them as such. But they didn't hired you because you are technically good, they hired you to fix a problem they had and thought you could that.

I can see multiple issues that could happen with this dissonance (the fact you think they hired you for one thing, compare with the real reason):

  1. Lack of goals:
  • Did they tell you what they expected of you?
  • Did you asked what they wanted?
  • Did you miss something when they told you?
  • Maybe you heard: "We want quality software!" when they meant "We want a software that people use!".
  1. lack of transparency: You arrive at this new job and you apply all the best practice known in your fields.
  • How did you communicate about it?
  • Did you go too fast?
  • Was everybody aware of the consequences because there is always trade off?
  • Did you explain the learning curve will hurt productivity?
  1. Support from below: Your methodology impacted the lifes of your team, they need to be convinced they are going into the right direction.

I can only speculate at this point but I can see why, in the space of few months, the devs freaked out because they don't see the added value (yet) of the changes and your bosses freaked out because the features are not coming as fast as they thought you would deliver and the devs are coming to them, unhappy.

You have to learn from this experience for the next time as things are pretty advanced in your case.

But if there is anything to save, it is through trust and patience. If anything,

  • go along the flow by acknowledging the problems they brought up.
  • Accept most of their changes and add your most valuable points (only on that condition you would see a future here)
  • Make a planning to reintroduce the best practices slowly but surely, explaining what problems thoses methods are fixing (no need of parachutes in cars, but a sit belt can help ;)

Convince people to be on your side, whatever the cost, because if you cannot do that, your battle is lost.

I would not concentrate too much about the decisions that were taken. The important information here is: they took upon themselves to have a meeting without you about things that were you responsibility. It shows a loss of confidence in you.

You need to understand where that came from in the first place. You look technically adequate considering what was asked from you: you convinced them as such. But they didn't hired you because you are technically good, they hired you to fix a problem they had and thought you could do that.

I can see multiple issues that could happen with this dissonance (the fact you think they hired you for one thing, compared with the real reason):

  1. Lack of goals:
  • Did they tell you what they expected of you?
  • Did you ask what they wanted?
  • Did you miss something they told you?
  • Maybe you heard: "We want quality software!" when they meant "We want a software that people use!".
  1. lack of transparency: You arrive at this new job and you apply all the best practice known in your fields.
  • How did you communicate about it?
  • Did you go too fast?
  • Was everybody aware of the consequences because there is always a trade off?
  • Did you explain the learning curve will hurt productivity?
  1. Support from below: Your methodology impacted the lives of your team, they need to be convinced they are going into the right direction.

I can only speculate at this point but I can see why, in the space of few months, the devs freaked out because they don't see the added value (yet) of the changes and your bosses freaked out because the features are not coming as fast as they thought you would deliver and the devs are getting back at them, unhappy.

You have to learn from this experience for the next time as things are pretty advanced in your case.

But if there is anything to save, it is through trust and patience. If anything,

  • Go with the flow by acknowledging the problems they brought up.
  • Accept most of their changes and add your most valuable points (only on the condition you would see a future here)
  • Make a schedule to reintroduce the best practices slowly but surely, explaining what problems those methods are fixing (no need for parachutes in cars, but a seat belt can help ;)

Convince people to be on your side, whatever the cost, because if you cannot do that, your battle is lost.

Source Link

I would not concentrate too much about the decisions that were taken. The important information here is: they took upon themselves to have a meeting without you about things that were you responsability. It shows a lost of confidence in you.

You need to understand where does that come from in the first place. You look like to be technically adequate with what was asked of you: you convinced them as such. But they didn't hired you because you are technically good, they hired you to fix a problem they had and thought you could that.

I can see multiple issues that could happen with this dissonance (the fact you think they hired you for one thing, compare with the real reason):

  1. Lack of goals:
  • Did they tell you what they expected of you?
  • Did you asked what they wanted?
  • Did you miss something when they told you?
  • Maybe you heard: "We want quality software!" when they meant "We want a software that people use!".
  1. lack of transparency: You arrive at this new job and you apply all the best practice known in your fields.
  • How did you communicate about it?
  • Did you go too fast?
  • Was everybody aware of the consequences because there is always trade off?
  • Did you explain the learning curve will hurt productivity?
  1. Support from below: Your methodology impacted the lifes of your team, they need to be convinced they are going into the right direction.

I can only speculate at this point but I can see why, in the space of few months, the devs freaked out because they don't see the added value (yet) of the changes and your bosses freaked out because the features are not coming as fast as they thought you would deliver and the devs are coming to them, unhappy.

You have to learn from this experience for the next time as things are pretty advanced in your case.

But if there is anything to save, it is through trust and patience. If anything,

  • go along the flow by acknowledging the problems they brought up.
  • Accept most of their changes and add your most valuable points (only on that condition you would see a future here)
  • Make a planning to reintroduce the best practices slowly but surely, explaining what problems thoses methods are fixing (no need of parachutes in cars, but a sit belt can help ;)

Convince people to be on your side, whatever the cost, because if you cannot do that, your battle is lost.