Know vs Trust 🎭
Feb 05, 2021 8:49 pm
Hi there,
Hope you're doing well this Friday! I've been giving a lot of thought to some of the more extreme or stressful moments of my career. I wrote several articles this week to get my energy out.
One article is about my thoughts around the push and pull that comes with trusting a team but knowing the details. This can be a subtle balance that constantly needs attention.
The other two are looking a series of moments, one from the perspective of personal responsibility as a developer, and the other as a leader recognizing an issue results in stopping all work until it is resolved.
I was thinking back to how many jobs had these types of moments occur and the truth is these events happened in almost every single job or client I've had. I guess one way to look at it is that moments like these are part of the job.
In other news, I started yet another project. Rather, I'm looking for validation to start another project. I'm fond of finding new ways of saying that tech interviewing practices are broken. Up until now, I've worked on teaching people how to navigate those practices, but I want to go further.
I'm thinking of a site where people can identify the practices they experienced interviewing at a company. Other people who apply to work will know to expect those practices as they prepare. It's that simple. Fewer surprises about bad interviewing practices.
I'd love it if you spread the word! https://brokeninterviews.com
Here's my weekly update for February 5th, 2021...
🗒️ Knowing the Details and Trusting the Team
I often work with leaders who have a team or several teams of developers and want to trust them but wind up surprised and frustrated when news breaks.
This incongruence feels a little hopeless because, on the one hand, they trust the team to take care of things, but then things still go wrong.
What do you do about knowing the details and trusting the team?
There are a number of times in any given project or product development cycle where you might have to consider stopping work.
I want to explore some of those ideas and share a story.
There are times throughout my career where I’ve taken an extreme stance on my responsibility as a developer.
Ironically this approach was rarely met with accolades until well after the moments passed.
So here are some of those stories.
As you read them, I invite you to ask yourself what your responsibility is as a professional?
Enjoy,
Ryan Latta