Issue #254, 6th October 2017

This Week's Favorite


On Leadership vs Management
5 minutes read.

Silvia Botros writes it beautifully: "Sadly we do not learn enough of that in our fancy CS degrees. Too much emphasis is put on algorithms and software and not enough in understanding how to talk to the business side of the company, how to have empathy for the customer-facing team members and how to behave and think as one team that is ultimately providing a service to paying customers." -- talk about with your engineers about the business just as much as you talk about the architecture. Sharing context will save a lot of time falling in love with the solution instead of the problem.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Culture


DO NOT HELP GOOGLE FIND SARAH CONNER.
1 minutes read.

My humble effort to help you start the weekend with a smile on your face. Google captcha is evil.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


On Writing Product Roadmaps
12 minutes read.

Starting Q4 of 2017, this post by Gaurav Oberoi is everything you need to build effective Product Roadmaps. We do quarterly planning and it allows us to debate around the "must have" and "nice to have" before we run to execute on it. Above all, I think it helps to set expectations around the team's velocity: It's easy to feel that every feature is essential and any delay there means the team is ineffective. This is far from being true.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


How to Overcome the Guesswork of Product Development With Hourly Engineering Estimates
8 minutes read.

Hiten Shah shares how he prefers to break down projects to cut down delays and complexity early on in the process. This is a heated debate for sure, so be ready for it and share it with other teammates to get their opinion. People who work with me know that I prefer hourly estimations (and then assume you're working 5-6 net hours a day making sure) as a way to improve your time estimations. I hate buffers or fake deadlines; it smells from lack of trust. Ask yourself after each task or feature is done: "Could I have foreseen it before starting to write a single line of code?" -- if the answer is no, you're probably on the right track to build stronger instincts around estimations.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Tracking Compensation and Promotion Inequity
4 minutes read.

This post by Lara Hogan is a must read for leaders in the organization who have access and control over compensation: "Plenty of tech companies are attempting to make their pipeline of candidates more diverse. But an organization won’t find much success recruiting a more diverse group of employees unless its leaders are aware of their existing internal inclusion and equity issues."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Peopleware


What to Do When You Start Managing Former Peers
4 minutes read.

There is no better way than "Take the awkwardness head-on" -- this transition is strange for everyone, so try asking them "What would you need me to do to improve? What mistakes should I avoid if we want to get this to work?"

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


The Equifax Ex-CEO Throwing an Unnamed Technician Under the Bus for the Equifax Breach Is Positively Maddening. Some Thoughts: (Thread)
2 minutes read.

Patrick McKenzie‏ reminds us that good leaders cannot escape failures or blame their teammates: "Speaking of failures in leadership: if your immediate instinct as a leader is not to protect your team then what leader are you?" -- I also like Bob Moris's comment: "It also implies their chain of command and oversight is non-existent. One person should not be responsible for security."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


What the Smartest People Do on the Weekend Is What Everyone Else Will Do During the Week in Ten Years
2 minutes read.

An old post by Chris Dixon but still as relevant as ever. Where it makes sense, try to get side-projects become core products or services in the business, if you want to increase retention and get people to feel their ideas can get the sponsorship needed within the company. For example, Gmail was a side-project in Google.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Inspiring Tweets


@cyberomin: As a senior engineer or a technical team lead, it's perfectly okay to say "I don't know, let's research this together."

@kriswager: "Our job is not to write code. That is the easy part. Our job is to make decisions" -- @jessitron on the real work of developers

- Oren

P.S. Can you share this email? I'd love for more people to experiment and improve their company's culture.

Subscribe now & join our community!