We were a Linux System Administration consultancy. The product wasn't the e-mails, but nearly everything we did for our clients was designed/planned, scheduled, organized, and documented in e-mail. Yes, sometimes we would work on things with the client on the phone, those were usually followed up with an e-mail about what was done.
These e-mails were copied to our internal mailing lists so that they could be peer reviewed and someone else could be cross-trained on it in case the primary wasn't available. Also, every task we did had a one sentence description written up that would be shared with the team, again as a kind of peer review.
Product/Software support. Above the Tier 1 level, at the stage where you're talking with the Dev team directly.
Developers don't want to talk to customers. So you need someone who can understand either the code or the developer's comments, but can then put it in layman's terms.
I didn’t, but I suspect people were hoping for something more substantive. What about it don’t you like? Is there something specific to this thread that relates to your role and reminds you why you hate it?
Your comment did nothing to further the conversation or take it in an interesting direction.
I asked for examples. I replied to that response stating that I'm already DevSecOps. Not sure what else they would be looking for. If they had additional info, maybe they should chime in.
In my team, Duty Managers / Service Delivery Managers / Operations Managers. Communication in every which direction is #1 skillset I look for in the team (as well as being organized, disciplined, eager to learn, sense of ownership).
A lot of the job is talking to technical teams, talking to functional teams, talking to business teams, talking to management and executives; translate, summarize, liaison, co-ordinate, plan and inform. Customize medium, format, length, message for each group to enhance understanding. Develop spidey sense of paranoia against assumptions, misunderstandings.
Well, that disqualifies me. The way most organizations tie your hands means one is given all the responsibility without real authority. I'm completely unmotivated because of that.
Downvoting on HN is fickle; sometimes it's the point that's being made, sometimes it's how it's being made. I think asking "have I meaningfully contributed to conversation" is part of it... but a lot of downvotes comes as emotional response or simple disagreement. You can choose whether to take it seriously and grow/change to satisfy it, or be yourself and take votes in passing.
That being said - sad to hear you are not eager to learn and don't have sense of ownership; you are correct that disqualifies you from some roles (most, in a way, but recruitment process is all sort of obscure and counter-logical).
For what little it may be worth: it mostly comes back to the old proverb of "courage to change things you can, accept things you cannot, wisdom to know the difference, and zen to make peace with it". I try to coach my team members very early on "these are things that are part of organizational machine; satisfy them so you are done with them. These are the things where you can make a difference and where most of your value will be concentrated. Focus on those once you've fed the machine".
I think part of disillusionment, at least it was mine, is the feeling that somebody somewhere, and ideally ourselves, should have all the necessary power. In reality, we all operate within constraints, more or less visible or scrutable.
Ultimately, life is imperfect, professional life included; it's a life's pursuit for most of us on how to grow our own acceptance and peace with it. Sometimes we make that change within ourselves, sometimes we are able to make an external change that aligns more with our priorities.
To add to your point of treating company's money as your own -- "Tracking Money" will help understand a lot of corporate priorities and explain a lot of decisions. --I-- may want to update something because "it's the right thing to do / makes for cleaner code / etc". But the management probably has a reason (good bad or ugly) for their own priorities. Advice I read mid-way through my career is "understand your manager's goals and reasons", and it was so simple and yet so... shocking to so many of us techies. We always expected manager to understand our recommendations and priorities. Hubris! :)
(in Public Sector, "Tracking Money", interestingly, did not work as well; but "Tracking Personal Status/Blame/Credit" worked well. The two should be equivalent but in my limited experience there's differences)
I once was a team lead for an team of outsourced software developers. It was the worst part of my career. The whole outsourced team was awful. Wholly incompetent.
I had the responsibility of delivering a product, but I didn't have the authority to fire these folks who were a net negative on the project. I would have been happier with implementing the whole project myself, which I mostly did.
I too was unmotivated, but the stress of being responsible was unbearable.
Perhaps some people disagree that "most organizations" give responsibility without authority, but I've seen it happen a several times in my career.
Another strain of this is forcing some COTS application to work via a million hacks and integrations (usually via consulting resources) when a fundamental architecture or application change is needed. Responsibility coupled with the resource and authority to execute is stressful in its own way but it at least allows one to more easily own their failures.
That's been my experience. I believe That's a universal truth when it comes to working in groups. You can't do what you think is best. You have to do what the group decides, or what the person in the leadership structure above you says. I'd be very curious to hear about company structures that don't have a top-down leadership/authority scheme.
Edit: Thanks! Looking at internal data analyst roles in my HR dept (weird that they aren't under a technical job code, so I wasn't seeing them before). Maybe I'll apply to one.
