3 ms·

There seem to be multiple issues here. This seems like you were basically in the wrong role. As the only full-time engineer, you're more than just an engineer,

There seem to be multiple issues here. This seems like you were basically in the wrong role. As the only full-time engineer, you're more than just an engineer, you're basically the IT department. So when the other departments were represented at meetings and disputes were being raised, IT wasn't represented. You failed at basic office politics. Office politics gets a bad rep because lots of people play it to further themselves, but being able to play basic politics is required to make sure other departments don't give your department all the blame. Also, because you weren't at the meetings you weren't able to understand what the business really needed. If you understood what the business really needed you would have been delivering that and people would have noticed. Instead, I suspect you focused on the technical tasks and created a very good technical product that fit the basic idea of what was needed but didn't deliver what is needed. In the future I would suggest looking into something like BDD, it basically follows the premise that business people don't even know what to ask for, so you have to work with them in meetings to discover what the true need is. And because you weren't really delivering what was needed as far as the other teams were concerned it most likely came across as they had no idea what you were doing therefore doing nothing at all. Basically, meetings, they're important. I hate to put it this way but I feel it's the truth, it's the difference between a software developer and software engineer. And the difference between a senior and a lead. It seems to me you would be much better suited for a role in a team where the management track stuff was dealt with by other people. I personally dislike the management track work but I understand the importance and I avoided management track roles for years to focus on writing code and solving problems.

rossdavidh 6y ago
On point, but I'd like to add that business people also tend not to know what is hard (for you to do) and what is easy, so they will NOT ask you to do things which would be useful for them and easy for you, and instead ask for things which are the opposite of that. This means you have a harder time creating value for them. The better you understand their work, the more likely you can say "I could automate that, it would be pretty easy", when they have no idea that it is the case.
- that_guy_iain 6y ago
  I can also echo this point. One of my favourite bits is telling business how much work each thing they need is and then letting them pick what they want next. I've been surprised when they picked things that didn't seem important but they could get it by the end of the week.
  - gitowiec 6y ago
    Exactly this is the way my colleague lead dev asks our business guys. "This takes 3 days of work and that is like a week, you know what is more important so you choose"
- numpad0 6y ago
  My dark take on that is it’s business people’s fault that they focus on party activities and asking me to mainly play those, while pretending with useless tasks as a side, especially if what engineers view as barbecue activities actually bring home the bacon using acidic-narconian logics from Gamma quadrant. If you think you have better understanding for the challenges and know better than the party people at materializing it or cash it out for a larger sum, just downright steal that idea and start your own company. They’ll get mad if it works, that’s hypothetical. If you don’t, just start gliding from day one and don’t feel guilty for it. Your responsibility extends absolutely no further than your paycheck goes, not a thousandths inch more. Don’t care where the money came from. There could be micro-guilts on you for micro-not being able to meet micro-expectations, but in return you’re not paid or given equities that your achievements would be worth in the term anyway, so it’s a fair game, a fair and stupid game.
jrochkind1 6y ago
Nicely said. The really important point here is that it's quite possible OP is right and did exactly the right stuff well but didn't communicate it well enough to stakeholders. It's also possible that OP was not doing what the business needed -- or was not doing what the stakeholders/leadership thought the business needed. People can disagree on this, but in the end it's leadership's opinion that you'll get evaluated on. You can try to convince leadership only if you are in dialog with them. So, how would you even tell the difference between whether you were doing what stakeholders prioritized but not communicating your successes well enough, or mistakenly not actually doing what was prioritized by stakeholders/leadership? the solution to this is going to be related to the solution to communicating successes effectively. And to be clear, this is actually a hard problem, you are not alone OP, I've been there. In the best case, as an engineer, my manager takes care of this for me, translating business priorities to my work and advertising my successes at implementing those priorities back out. But we seldom get a best-case manager.

rossdavidh 6y ago

On point, but I'd like to add that business people also tend not to know what is hard (for you to do) and what is easy, so they will NOT ask you to do things which would be useful for them and easy for you, and instead ask for things which are the opposite of that. This means you have a harder time creating value for them. The better you understand their work, the more likely you can say "I could automate that, it would be pretty easy", when they have no idea that it is the case.

that_guy_iain 6y ago
I can also echo this point. One of my favourite bits is telling business how much work each thing they need is and then letting them pick what they want next. I've been surprised when they picked things that didn't seem important but they could get it by the end of the week.
- gitowiec 6y ago
  Exactly this is the way my colleague lead dev asks our business guys. "This takes 3 days of work and that is like a week, you know what is more important so you choose"
numpad0 6y ago
My dark take on that is it’s business people’s fault that they focus on party activities and asking me to mainly play those, while pretending with useless tasks as a side, especially if what engineers view as barbecue activities actually bring home the bacon using acidic-narconian logics from Gamma quadrant. If you think you have better understanding for the challenges and know better than the party people at materializing it or cash it out for a larger sum, just downright steal that idea and start your own company. They’ll get mad if it works, that’s hypothetical. If you don’t, just start gliding from day one and don’t feel guilty for it. Your responsibility extends absolutely no further than your paycheck goes, not a thousandths inch more. Don’t care where the money came from. There could be micro-guilts on you for micro-not being able to meet micro-expectations, but in return you’re not paid or given equities that your achievements would be worth in the term anyway, so it’s a fair game, a fair and stupid game.

jrochkind1 6y ago

Nicely said. The really important point here is that it's quite possible OP is right and did exactly the right stuff well but didn't communicate it well enough to stakeholders. It's also possible that OP was not doing what the business needed -- or was not doing what the stakeholders/leadership thought the business needed. People can disagree on this, but in the end it's leadership's opinion that you'll get evaluated on. You can try to convince leadership only if you are in dialog with them. So, how would you even tell the difference between whether you were doing what stakeholders prioritized but not communicating your successes well enough, or mistakenly not actually doing what was prioritized by stakeholders/leadership? the solution to this is going to be related to the solution to communicating successes effectively. And to be clear, this is actually a hard problem, you are not alone OP, I've been there. In the best case, as an engineer, my manager takes care of this for me, translating business priorities to my work and advertising my successes at implementing those priorities back out. But we seldom get a best-case manager.