This commit is contained in:
Adam Mohammed
2023-07-24 11:12:46 -04:00
parent 5f13efe08e
commit 82dcab9f9d
8 changed files with 210 additions and 0 deletions

View File

@@ -4,3 +4,32 @@
** TODO Try to deploy
** TODO Put together POC for micro-caching RAILS
** TODO Create a ticket to deal with 403s for provisioning failures
** TODO Express concern around engineering quality
I raised concerns that this result is doesn't meet the bar to achieve success on the problem we set out to solve.
I also do believe it doesn't help solve the problem
When I express that the immediate response was defense. That's the wrong response itself.
I can be clearer -- There are two points I want here,
1. I don't think this solves the problem we were targeting.
2. We have finite time, deciding if we want to iterate or redesign based on learning is a decision to make.
3. Option 3 which I didn't think was possible is to completely ignore the point.
Here's what's worse though. We're trying to transform the team to be enablers for other teams, so we need to set the bar.
We have people on this team that are trying to raise / set the bar, and when they raise concerns they are dismissed without
consideration.
My main concern is our ability to field feedback on this team. I don't
think I have many occurrences of differing opinions being given the required space.
At best it leads to apathy, at worst it leads to mediocrity. Either way it leads to a dysfunctional team by design.
Those people trying to raise the bar aren't doing so selfishly.
We don't get immediate gain out of performing better or working harder, we still get paid the same.
So why would we be striving to raise the bar? This is a fundamental question to see if a leader understands
what high performers need to thrive.