Files
org-notes/notes.org
Adam Mohammed 82dcab9f9d Big dump
2023-07-24 11:13:50 -04:00

1.7 KiB
Raw Blame History

Tasks

TODO Present Users through the ResourceOwnerShim

TODO Write ExternalSecretPush for DB creds and Secret key base

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.