My personal experience with this from the manager's perspective: I aim to promote someone as soon as they are ready, but no sooner. If I promote someone who will not succeed against the expectations of the higher leveled title, I'm just setting them up to get fired or "managed out" when they were otherwise perfectly competent in the level they're at. That's ignoring the natural fuzziness and storytelling element of defining and measuring competence, of course, but that's the general idea of where I put the threshold.
"Readiness" means that I believe that after their promotion they will be able to execute at the higher level at least most of the time. That doesn't necessarily mean they need to be already doing the higher leveled job, but in practice they do need to show that they can sustain some approximation of it.
I think the only possible flaw with this idea is you might not know.
I find that my organizational and leadership skills demonstrated in my role suffer when I am working on individual contributor work that requires deep focus and perhaps even isolation.
At the same time, I’ve handled other roles at other companies that required more leadership and team mentorship, where you’d look at my actions and feel more like I was management material. But in my current role with my current responsibilities it’s hard for myself let alone someone else to imagine that I would make an effective leader, since my job basically dictates that I don’t do that on a daily basis.
The day to day needs and responsibilities of the business often get in the way of the person actually demonstrating that they will excel when they do something else.
I don’t have any kind of direct solution for this specific dilemma. I think in my situation my manager should make more opportunities available but hasn’t been doing so due to the daily routine of putting out fires.
I’ve had great success “leading” in one business and difficulties in another. I learned what kind of orgs I can be effective at. They’re wildly different imo.
Being promoted into obsolescence or into under performing is a death sentence. Some people are perfectly suited for their work and would find their bosses work to be numbing, too complex or too simple for them. Not getting a promotion is not a bad thing (do not mistake raises for a promotion). If the company cannot or will not allocate more to your position then that is a problem as a business, not something you can control. The best case scenario is to find another company who can pay your worth for the skill set presented.
This is cool. It feels a lot like business school cases where you get a packet of context and need to think about how to navigate the many factors at play, though with more direct practice, much less of the social dynamics of a class discussion, and less of a main character storytelling vibe, which are all good things IMO.
If there was a way to combine this with coaching sessions, I think this could be a very effective way to train IC's that are stepping into leadership roles (managers, staff/principal IC's, PM's, etc.). It could also be interesting to have a variant of the exercise where you ask the student/user to write their own message.
That 'MBA case study' feeling is exactly what I was aiming for—moving away from passive video consumption to active decision-making.
You hit the nail on the head regarding coaching. I actually view this tool not as a replacement for coaching, but as the 'Lab Work' that happens between sessions.
If a new manager can play the 'Firing' scenario 5 times at home and fail safely, they come to their coaching session with specific, high-quality questions rather than generic anxieties. It allows the human coach to focus on the nuance rather than the basics.
ConcernedApe's next game is also built on MonoGame, so he has self-interested reasons to want MonoGame to continue to be maintained. But just because ConcernedApe has self-interested reasons to donate doesn't necessarily mean that it doesn't also come from a charitable place.
MonoGame is basically getting a sponsor. The ecosystem benefits. I'm personally happy to leave it there rather than asking for moral purity.
In practice, it's like how having Adobe Reader used to be. You mostly don't need it, but occasionally you need it for interoperability with other people, such as lawyers.
Otherwise, I keep it around for the desktop Excel app. Still my preferred spreadsheet app, even though Google Sheets does pretty much all of what I need.
> Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues.
There's a small but substantial number of engineers out there who haven't operated at the kinds of scales where hyperscalers' limits become normal architectural problems and don't have the humility to imagine that it could be the case. (e.g. blob stores do in fact have limits you can hit, and when you operate at petabyte scales you have to anticipate in the architecture that you can hit them for even trivial operations.) I also work on petabyte datastores and have encountered a bunch of those engineers over time.
To be fair though, that's the small minority of engineers I've encountered, and if it wasn't arguing about the types of scale problems unique to petabyte scales, it'd be about some other nuanced subject matter. It's a humility problem.
As a data engineer in big tech, the two hardest problems I deal with are:
* Conway's law causing multiple different data science toolchains, different philosophies on model training, data handling, schema and protocol, data retention policies, etc.
* Coming up with tech solutions to try to mitigate the impact of multiple silos insisting on doing things their own way while also insisting that other silos do it their way because they need to access other silos' data.
And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs. As someone who gets to see all of those approaches - most of their approaches are both valid and flawed and often not in the way their leaders think. A few are "it's not going to work" levels of flawed as a result of an architect or leadership lacking operating experience.
So yeah, it might look like technical problems on the surface, but it's really people problems.
- Requirements are rarely clear from the beginning;
- We (DE) are not enabling self-service and automation so we are drowned in small requests (add this column for example;
- Upstream rarely notify us about the changes so we only know when downstream alerts us. We end up building expensive pipelines to scan and send alerts. Sometimes the cost of alerts > cost of pipeline itself;
- We have so many ad-hoc requests that sprint is meaningless. If I were the manager I'd abolish sprint completely;
- Shadow knowledge that no one bothered to write down. I tried to write down as much as possible, but there are always more unknowns than knowns;
Working in DE definitely gives me enough motivation to teach myself about lower level CS.
That's the mother of all people-space problems in IT, right there.
To solve this, one can be an instrument for change. Network, band people together, evangelize better ways forward, all while not angering management by operating transparently.
Sometimes, that can work... up to a point. To broadcast real change, quickly, you really need anyone managing all the stakeholders to lead the charge and/or delegate a person or people to get it done. So the behavior of directors and VPs counts a lot for both the problem and the solution. It's not impossible to manage up into that state with a lot of talking and lobbying, but it's also not easy.
I'll add that technological transformation of the workplace is so hard to do, Amazon published a guide on how to do this for AWS. As a blueprint for doing this insanely hard task, I think it holds up as a way to implement just about any level of tech change. It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow. https://docs.aws.amazon.com/prescriptive-guidance/latest/clo...
> It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow.
Yup, this is the key issue and what makes it primarily a people problem. Technical solutions don't work if the main problem is getting buy-in to spec/build/adopt one, unless you're willing to build a lot of things you end up throwing out. So instead the bulk of the high risk work is actually negotiation between people.
> And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs
I work in implementation of large enterprise wide systems. When I do projects that span departments/divisions/agencies what you’re describing is the biggest hurdle. The project always starts with “we’re bringing everyone together into one solution” but as time goes on it starts to diverge. It’s so easy to end up with a project per department vs one project for all. You have to have someone with the authority to force/threaten/manipulate all the players onto the same page. It’s so easy to give in to one groups specific requirements and then you’ve opened Pandora’s box as word spreads. It’s very hard to pull off.
I think public sector (governments) is the hardest because the agencies seem to sincerely hate each other. I’ve been in requirements gathering meetings where people refused to join because someone they didn’t like was on the invite. At least in a for profit company the common denominator for everyone is keeping their job.
Some fairly simple examples where accommodations make the test more fair:
* You have a disability that hinders your ability to type on a keyboard, so you need extra time to type the essay based exam through vocal transcription.
* You broke your dominant hand (accidents happen) so even though you know all of the material, you just can't write fast enough within normal "reasonable" time limits.
* You are blind, you need some way to be able to read the questions in the test. People who can see normally shouldn't need those accommodations.
I don't think those are cases where you are lowering the bar. Not by more than you are allowing the test taker a fairer chance, anyway.
The problem is when you get into the gray area where it's not clear than an accommodation should be given.
Those are all great examples where I agree that an accommodation seems uncontroversial.
But to quote the article linked in the parent comment:
> The increase is driven by more young people getting diagnosed with conditions such as ADHD, anxiety, and depression, and by universities making the process of getting accommodations easier.
These disabilities are more complex for multiple reasons.
One is the classification criteria. A broken hand or blindness is fairly discrete, anxiety is not. All people experience some anxiety; some experience very little, some people a great deal, and everything in between. The line between regular anxiety and clinical anxiety is inherently fuzzy. Further, a clinical anxiety diagnosis is usually made on the basis of patient questionnaires and interviews where a patient self-reports their symptoms. This is fine in the context of medicine, but if patients have an incentive to game these interviews (like more test time), it is pretty trvial to game a GAD-7 questionnaire for the desired outcome. There are no objective biomarkers we can use to make a clinical anxiety diagnosis.
Another is the scope of accommodation. The above examples have an accommodation narrowly tailored to the disability in a way that maintains fairness. Blind users get a braille test that is of no use to other students anyway. A student with a broken hand might get more time on an eassy test, but presumably would receive no extra time on a multiple choice test and their accommodation is for a period of months, not indefinite.
You do need to expose your team to some of the shit that's getting flung or else your team gets used to operating under clean conditions and loses its tolerance.
For better or for worse, politics and randomization is just a thing in our jobs, and for at least some people in your team that means part of career growth is learning to handle it. If you, the manager, are the sole person capable of being the "shit umbrella" for the team, that's another way that your team gets a bus number of 1. (I learned this the hard way.)
In an ideal world you have some senior engineers who are more of the "don't bother me and let me cook" persuasion, and then you have at least one who is probably on track to become a manager, and they are your backup when you can't be in two places at once.
"Readiness" means that I believe that after their promotion they will be able to execute at the higher level at least most of the time. That doesn't necessarily mean they need to be already doing the higher leveled job, but in practice they do need to show that they can sustain some approximation of it.