I had a similar experience, but I joined AWS support, in a pretty challenging role (big data profile).
My first 3 months were training (almost none of it on any big data technologies) taking cases and working with other support engineers.
The role itself was very demanding, very little prep with the transition to the actual role, and I felt lost most of the time. Learning how AWS puts their services together was most of the challenge and to be honest the and my manager (normal IT guy) didn't really understand the basics or complexity of the cases we were dealing with at all from several conversations I had with him. He oversimplified just about everything.
At some point in time 6 months into the role, he decides to move to a different area. My new manager was like "oh I see you are on a performance improvement program". This was the first I had ever heard of it. After explaining myself to the new manager and doing a few kickass cases for very large customers, I was actually sent on training at Amazon HQ and from there I never looked back, and ended up becoming a global big data SME in professional services. So from there point of view I was worth the investment (especially at ~2-3500 a day billable to customers!).
But I'll never forget that my manager wanted me out after only 6 months, working with some of the most difficult customers and most difficult support cases I think AWS support has to deal with..
Ive always held the belief that story points were specific to a team, and a result of the work that specific team does and/or services, products and customers they support, which was a why comparing cross teams is a huge no no!
But story points themselves are actually guesses, and are never a true reflection of the work undertaken post mortem - and rarely if ever get reevaluated with 'correct values' mainly because it's really difficult to do that - it's another guess really.
I think any attempts to measure the accuracy of guesses on imaginary relative units, specific to a team, with deliberately obfuscated and difficult to reconcile units is futility by definition.
Instead companies have started to see the light of measurement using standard units of time and tracking the start to finish time including the states of tickets - Flow metrics.
Which is all fine, however you still have the original problem - unless you strictly compare very similar tasks perhaps done by similar engineers in terms of tenure, skill level and maturity, and maybe other factors, you still can't directly compare tasks across teams.
There still needs to be consideration of the make up of a team to get an understanding of skill level and experience.
Ive personally witnessed teams with graduates in them and people with 20 years experience completing very similar tasks and the difference is astonishing.
Agree with all of your points. I had everything documented in a business case format for management to consume with references to more technical topics, in a wiki.
So, anyway, I think things have sort of settled on this stuff a bit now.
I'm been recently made the tech lead on this initiative that I did all the research on and my manager have me kudos for the idea.
In fact we're pivoting on alot of other things at work because of it, with top level leadership support.
Dude, I had a colleague, senior to me, do the opposite. I had an idea that I struggled internally to get off the ground for months and months. I pretty much did all the research, found the contacts, got the architecture direction, sought feedback and buy in from multiple stakeholders - including him. Practically I was ignored.
After about 6 months, he's presenting this identical idea to our team!
Guess what, it was approved by upper management!!
Except, the lack of details he had in his super high level stuff lacked any insights, so I called him out in the next meeting and basically said have you seen this document I've been socialising for the last 6 months!?
"Fall back on blaming the process when failure comes around and avoid ever pointing fingers or owning it."
Some organisations can do this, but I've see plenty that might outwardly try to avoid pointing fingers, but you can tell that despite warnings given, they do blame.
I told several leaders that one of their systems was literally on the brink and we were fighting fires on it every other day, and the processes in place were horribly broken.
12 months later shit hit the fan, my feedback was that I wasn't proactive enough, and they basically threw me and my team under the bus.
This despite budget under cutting, limits in hiring, enormous optimisation, education of other teams, research. Just getting 'No' or no real outcomes all the time on any escalation.
The leaders did this serially across the business, and lacked ownership on this aspect to even give people the resources and autonomy to do anything about it, yet would come looking when it came time, to throw other teams under the bus like this
My simple answer: Don't. You're always hovering somewhere between a sysadmin and a software engineer, but never quite get the cred for developing software but still cop all the crud that sysadmins do.
I joined a scale up in the BNPL space as head of data engineering.
It was one of the most poorly managed IT environments I'd ever seen.
There was so much technical debt, that basic systems where literally dead or dying (day 3, Tableau stopped working), and while I did my absolute best to address it, the constant overarching priorities were always more data, and faster data. Reliability, security, performance was my problem to deal with. (As well as literally anything technical, yes even configuration of mail clients).
The demands for solutions came thick and fast from the head of data science and where always clear as mud, yet I was pushed to the wall on immediate and unquestioning commitment for data projects and was held accountable for dates regardless of the resources, capacity, dependencies or technical debt we were fighting on daily basis.
Attempts to push back on any commitments or seeking clarification or coming back with a different solution were often met with my manager telling me, publicly in meetings, that I was going against company principles. At other times the head of data science would get extremely angry and storm out.
I ended up having to track our team's time, and I remember at one point in time in a quarterly planning session (that they had just transitioned to ) we could actually see how under resourced we where because based on our estimates (backed by data, tracked meticulously by time) of projects they expected in that quarter we could justify a 10x increase in our resources.
This apparently shocked them and us so much, they ( my manager and some other data representative) penned a pretty crazy letter to the CEO basically saying all the work the team had been doing for the last X years (since I joined) was wrong and bad and etc etc... completely unfounded. I only found out about it because the CTO raised some eyebrows on some of the claims. I ripped it to shreds pretty much questioned every claim with counter examples, and they had to throw it away.
My observations working in a large financial institution who have in the last couple of years adopted SaFE and therefore hired product owners and scrum masters is that the majority of scrum masters including the lead scrum masters come from project management backgrounds.
What they preach and what they practice don't always align (in major ways), and I'm constantly going back to the agile manifesto where I am like 'this ain't right'.
It reminds me of certain organised religions!
Could you replace them with chatgpt?
I'm sure it's possible!
Could you replace the minister of a church with chatgpt? Well I'm sure that's possible too!
One of the "questions" on their apply for job form is
TL;DR
Optional field is REQUIRED and only option is "Yes"
"At Thoughtworks, we are intentional about making technology a better place for all. We know that the more diverse our backgrounds are, the more impactful solutions we build for our clients. We foster an inclusive community and focus on creating a balanced workforce reflective of the society we live in.To help us achieve this balance, we encourage you to answer these demographic questions. We collect this data to understand who we are reaching (and who we’re not) so we can do better at connecting with a truly diverse group of potential Thoughtworkers. Our recruiting teams will only see the data collected here on an aggregated level, consistent with our Data Privacy Policy. Responding to the questions is completely voluntary and anonymous. Declining to respond will not impact your standing in the recruiting process."
The field is REQUIRED and the only option is "Yes"
I applied for a role at ThoughtWorks once and their form was an interesting one. They as all the usual details but they an an option in leui of uploading your CV and other details 'or enter manually'.
It's the most bizarro thing I've ever seen, a single line text field.
Feeling kinda leet at the time I decided to take the plunge and cut and paste cover letter, CV, LinkedIn profile etc into this small field and let it burn.
Unsurprisingly I never got contact or received any confirmation or anything....
Why the hell would they even have that as an option?