Skip to content

Man up! (A developer’s responsibility to their team)

Dear Reader,

Regular readers know that if I have to answer a question more than once, I usually blog the answer so that I don’t have to answer it anymore. This is one of those posts. Also, I do apologize in advance to my female coder friends, the title wasn’t meant to be sexist.

Twice in the past 3 months I’ve had the same conversation with two different people.

Other: Well, they did it, they chose <solution X> over <solution Y>. They are so wrong. This is gonna be totally fubar. I’m not sure I can support this decision knowing how stupid it is.
Me: Were you involved in the discussion?
Other: Yes.
Me: Then, now that the decision is made, you have two and only two options. Either get behind the decision and do your job, or leave.

Look, it’s easy. As developers, we see people we don’t respect making decisions we don’t agree with. I know how difficult this position is because like every other developer in the world, I’ve been in this position. However, unlike a lot of developers I’ve talked to in recent years, I don’t see “digging my heals in” or whining as alternatives. If your company, or your leadership has made a decision you don’t agree with, you do only have two options.

  1. Man up, suck it up, grow a pair, put your big girl panties on, however you want to phrase it, you not only go along with the decision, you get behind it. You find a way to get your head back in the game and play. Why? because it’s your job. You are a member of a team. When the team decides to move, you move with it. You don’t decide to mope, you don’t decide that maybe if you are passive aggressive enough things will get better. You owe it to your team to get on board or move on to option number 2.
  2. Leave. Yes, get the hell out of Dodge. If you can’t get behind the decision, don’t try to bring the house down from within. Do the honorable thing and leave. If you can’t leave immediately then circle back around to option 1 until you can.

Yes, your job will suck for a while until you can relocate, nobody promised you happiness, just the pursuit of happiness.

I talk to a lot of people about how to build teams and the cornerstone of any good team is respect. Management has to respect developers and I firmly believe that. However, you as a developers, have to respect management as well. It is a two way street. It is your job to respect them and as soon as you find yourself in a position where you don’t or can’t, leave. Until then, man up and do your job.

Until next time,
I <3 |<

10 thoughts on “Man up! (A developer’s responsibility to their team)

  1. I agree, but it’s not as easy as this I think. Well, depending on how your mind works, I guess.

    While I was employed for web agencies, I’ve seen a lot of bad decisions happen. As an employee, when doing projects for customers, most of these decisions were taken without any customer input on the decision (either because they wouldn’t know what is good anyway, or because it would be “too much hassle to involve the customer”). With my aim for the highest quality in every situation, this would be problematic for me. I wanted to deliver the best to the customer and the customer didn’t conciously make a decision to get “slightly lower quality” software. I would usually debate the decision (or whine, etc) until I was sure there was nothing I could do to change it.

    Now that I’m freelancer, things are different. Why? Because the decisions are the client’s decisions. I will advice them, give them my opinion, make sure they know about all the pro’s and con’s, and when now a bad decision is made, I suck it up and go with the decision. I’ve still fought for what I thought best, but since it’s the customer that pays, I don’t mind anymore.

    It’s funny how that works, but I really think it depends on the situation.

  2. Good post! However the question you asked about “Were you involved in the discussion?” should really be “Were you involved in the decision making process?”.
    I agree with you that as a team member you should get behind any decision or leave. However if you and probably other members of the team were not considered whilst making a decision then you will end up disagreeing (openly and loudly).
    And leaving in this case might not be an option if you still believe in the team but not its lead.
    In that case mutany is an option. Not an easy one nor a likely to be successful one but an option.
    This is of course only the case when the respect you mentioned is not present.

  3. I’ve been in that situation so many times, it’s like hell when you have to follow a bad decision, overall when some person does it instead of the team. However most of the time I stay in the team and try to adjust and obtain the best output from it.

    Good article!

  4. This can be taken from a lot of different perspectives.

    Option #1 sounds like you just lower your standards just because your team doesn’t understand, value, or possibly listen to your input. If this is not the case, then yes, you better work your balls off and help your team.

    Option #2 you make sound like it’s a bad thing. Let’s say you have a team that keeps making bad decisions that puts you in bad places. This is not a team that thinks the same as you, leave and find a team that you can gel with and that lives up to your standards. I promise it will make you enjoy developing again.

  5. There is a third option which can be used, sparingly, but appropriately. If early on in the process, other requirements come to light that were not known during the original discussions or decision making processes which would otherwise have caused a different decision, imo that’s a valid reason to revisit the original decision. You need to be sure when you use this approach that it’s really worth pursuing – pick your battles appropriately – but I’ve used it on occasion.

    I recently used it as a justification for a rewrite. As somewhat crazy as it is, I was brought in to do ‘fixes’ to an existing Rails app. There were about 70 items (some big, some small). The initial estimate to upgrade to Rails 2 (yes, it was still being ‘updated’ in Rails 1 in 2010) was about 15 hours. We blew past that estimate early on, and weren’t anywhere near. On top of that, a second set of discussions brought up about 5 more items of functionality which the client thought were *in* the current system, just not working properly. These items were not even *in* the original codebase (fundamental stuff like security, permissioning, inventory tracking, etc) So, ime, the original information used to justify the first decision was no longer valid.

    Carrying on with an original decision made under knowingly false/bad data doesn’t make sense for anyone involved, solely for the sake of not rocking the boat.

    If you can’t reasonably convince people that new evidence demands a new trial/decision/review *ever* (I agree it can’t be done on every single new idea someone has), then that’s not a team I’d want to be a part of, and would leave (and have left).

    I do think there’s something missing in the post above about the chemistry and history of the team, and a degree of respect from fellow team members. If you’re outvoted solely on principal that a decision was made, we stick to it, regardless of your contributions, history, previous value brought to projects/company/team/etc, that speaks to a larger issue with the team or management in general. If you’ve got a history of making good decisions and contributing positively, I’d think you’d have a good shot and helping rethink a previous decision.

    I’ve recently been involved in a couple projects where a team was struggling to make code fit to previous design decisions that were made without their input. Someone outside that team made an architectural decision about X, and the team was left to implement it. For various reasons, team members in both projects were having troubles, but neither felt comfortable expressing their problems in terms of the process, and were internalizing things on themselves – they didn’t understand enough, needed more training, needed to be better coders, maybe needed outside help, more staff, etc. In both cases, the primary issues were external to the team, but the team didn’t feel they could speak up (in one case, I’m not even sure they recognized that they were *not* at fault). In this case, had some of these team members just quit because the going got rough, it would not have solved anything, only made matters worse for them and the rest of their team down the road.

    Good post and food for thought!

  6. I totally agree with your post. I used to be (am..) very stubborn so when decisions were made in spite of my objections I used to take it personal and mope about it.

    However I now believe that my job is to assist the management in picking a direction and then to go there. It is up to me to give them the best possible advice. It is up to them to value all the advice and the pro’s and con’s and then pick the direction we all will be heading in.

    If you are in a team where everyone respects eachother, this approach works. We all make mistakes and time will show the value of all the advice. Maybe they will heed mine next time. The point is, everyone learns this way.

    If you are in a team where there is no respect, just leave… personal ego should never trump empiricism and rational argument. Some 50% of your personal uptime is spent on the job; don’t spend it with people you can never respect.

  7. I totally agree with this post. Everyone lives the life of their choosing. Not just what they chose, but what they’re choosing. I have written a (similar motivational) blog post about this in 2008 and still stand by it on a daily basis.

    And like Cal says if you are an employee, you still have an option to go and search for your dream job while doing option 1. Once you are out of that situation, your eyes will open and you will see it was you who was holding yourself back. A good example is Stefan. He took control and see how his point of view changed…

  8. The best part of this post was your mention that until you can really settle on Option 2 circle back around to Option 1. Now that is great advice.

Comments are closed.