Software Lead Weekly
Issue #222, 24th February 2017
This Week's Favorite
Reflecting on One Very, Very Strange Year at Uber
12 minutes read.
Susan J. Fowler shares terrible situations that happened to her during her time at Uber, and it caught a lot of attention this week. I agree with what Peter Kazanjy said: Every CEO should grab this URL, send it to all@ saying "this is never ok. If it ever happens, come directly to me." -- No one deserves to feel like this at work. We should feel safe. Build and retain a high level of trust with your team, show them that you won't tolerate such behavior regardless of who did that or what is their "performance score".
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
12 minutes read.
Susan J. Fowler shares terrible situations that happened to her during her time at Uber, and it caught a lot of attention this week. I agree with what Peter Kazanjy said: Every CEO should grab this URL, send it to all@ saying "this is never ok. If it ever happens, come directly to me." -- No one deserves to feel like this at work. We should feel safe. Build and retain a high level of trust with your team, show them that you won't tolerate such behavior regardless of who did that or what is their "performance score".
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
Culture
All Internet Arguments Ever
1 minutes read.
My humble effort to help you start the weekend with a smile on your face.
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
1 minutes read.
My humble effort to help you start the weekend with a smile on your face.
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
Culture Is the Spec; Process Is the Code
7 minutes read.
Rich Armstrong's post is so good, there is nothing I can add to it other than drop everything you do and go read it! My favorite: "If your team resists all process for fear of becoming corporate, that’s like resisting writing any code because it inevitably leads to technical debt."
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
7 minutes read.
Rich Armstrong's post is so good, there is nothing I can add to it other than drop everything you do and go read it! My favorite: "If your team resists all process for fear of becoming corporate, that’s like resisting writing any code because it inevitably leads to technical debt."
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
Parallel Engineering Efforts
5 minutes read.
Running parallel engineering efforts can be a great practice as you get to product-market fit, and you can risk throwing away some effort just to learn faster what would be the right solution -- "We’re not sure where this will fall out, but our focus isn’t on the success of a particular artifact of software, it’s on getting features to our users and acting on what we learn... Writing code isn’t the hardest part about building software, it’s building the right code that you can live with for years." -- This will buy you time to do it right, while reducing customers' pressure. Great stories and examples from MongoDB experiments from Eliot Horowitz.
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
5 minutes read.
Running parallel engineering efforts can be a great practice as you get to product-market fit, and you can risk throwing away some effort just to learn faster what would be the right solution -- "We’re not sure where this will fall out, but our focus isn’t on the success of a particular artifact of software, it’s on getting features to our users and acting on what we learn... Writing code isn’t the hardest part about building software, it’s building the right code that you can live with for years." -- This will buy you time to do it right, while reducing customers' pressure. Great stories and examples from MongoDB experiments from Eliot Horowitz.
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
Your Culture Is Rotting
5 minutes read.
It's worrisome how we often think that there is one tean that is responsible for having a good culture, for our people's happiness, for creating a safe environment etc. We usually call it HR or "People department". We should stop outsourcing our responsbility and start taking ownership on the culture we promote: "... it is equally likely there are humans at every level of leadership who exhibit this (ppor) behavior, and all are allowed to behave in this way because of the values of the company."
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
5 minutes read.
It's worrisome how we often think that there is one tean that is responsible for having a good culture, for our people's happiness, for creating a safe environment etc. We usually call it HR or "People department". We should stop outsourcing our responsbility and start taking ownership on the culture we promote: "... it is equally likely there are humans at every level of leadership who exhibit this (ppor) behavior, and all are allowed to behave in this way because of the values of the company."
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
Peopleware
What Does a Director of Engineering Do?
5 minutes read.
What I liked about this post by Dan DeMeyere is that it feels authentic. His role is very specific to the company's needs and given context. It's a great attempt to explain a role that is really hard to explain, even to yourself. It's helpful because it helps us to reflect on our role, and I'm sure that Dan will reflect on his perspectives using this post in the future. Can you try to explain what your role is? Can you write it down and share it with someone?
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
5 minutes read.
What I liked about this post by Dan DeMeyere is that it feels authentic. His role is very specific to the company's needs and given context. It's a great attempt to explain a role that is really hard to explain, even to yourself. It's helpful because it helps us to reflect on our role, and I'm sure that Dan will reflect on his perspectives using this post in the future. Can you try to explain what your role is? Can you write it down and share it with someone?
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
Ship Small Diffs
5 minutes read.
I'm a huge fan of everything that goes in Dan McKinley's "Taking Small Diffs Seriously". It can often feel very hard to do, specifically in systems where mistakes are very costly, and that's precisely the reason why you should do it anyway. You'd like to remove that feeling of risk & effort, so you could focus on growing the business by running a lot of tiny improvements and experiments instead of justifying every mistake found in production to numerous stakeholders. Lastly, as we saw with GitLab just a couple of weeks ago, sometimes your most glorious failures can serve you best in terms of building trust with your users (best marketing ever!) using today's real-time communication channels.
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
5 minutes read.
I'm a huge fan of everything that goes in Dan McKinley's "Taking Small Diffs Seriously". It can often feel very hard to do, specifically in systems where mistakes are very costly, and that's precisely the reason why you should do it anyway. You'd like to remove that feeling of risk & effort, so you could focus on growing the business by running a lot of tiny improvements and experiments instead of justifying every mistake found in production to numerous stakeholders. Lastly, as we saw with GitLab just a couple of weeks ago, sometimes your most glorious failures can serve you best in terms of building trust with your users (best marketing ever!) using today's real-time communication channels.
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
Owner vs. Victim Theory and the Pitfall of Overusing It
4 minutes read.
Helpful reminder to the ease of labeling others and the dangers of rushing to the end, applying practices we can barely understand. I enjoyed the questions suggested on how to avoid labeling the conversation (and the person!).
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
4 minutes read.
Helpful reminder to the ease of labeling others and the dangers of rushing to the end, applying practices we can barely understand. I enjoyed the questions suggested on how to avoid labeling the conversation (and the person!).
Read it later via Pocket or Instapaper.
Share it via Twitter or email.
Inspiring Tweets
@skamille: One of my favorite questions to ask when being interviewed: "What makes someone successful here?" Tends to be very illuminating.
@sarahmei: A manager's job is to empower (service), not control (authority). So much pathology on software teams comes from somebody confusing that.😣
- Oren
P.S. Can you share this email? I'd love for more people to experiment and improve their company's culture.
P.S. Can you share this email? I'd love for more people to experiment and improve their company's culture.