One email per week, 5 links.
Would you like to learn how to build better teams, improve your leadership skills, and company culture?
Keeping up to date with all the blogs, podcasts, and articles is time consuming so why not let someone else curate the content for you?
With our weekly newsletter you will get five top stories hand-picked into your inbox every Monday.
This newsletter is perfect for every CTO, engineering manager, team leader, technical lead, or senior engineer who wants to learn more about the human side of software development.
Escape the distractions of social media and own your focus. Check out the latest issue and subscribe!
Tech Lead Digest#41
this week's favorite
Through my years as a manager, I’ve been fortunate to work with truly amazing folks. I can count the number of people I’ve dreaded having 1:1s with on one hand.
By “high growth”, I mean in terms of employee count and roughly doubling or more every year. Even at slower growth rates, some of the phenomena I’ll describe may be relevant.
In most organizations, if there's a Product Owner, the dev team is generally subservient to it and charged with building whatever the Product Owner comes up with. That's not to say they aren't often "on the same team", but the flow of responsibility is usually the PO pushes new requirements and the developers respond to them. Sometimes this relationship, even if only implied, has ramifications for the developers.
Last time, I explained that, although estimating software project timelines is hard, you should do it anyway. With that background, I want to go into some detail and share the technique I use when I need to develop a project timeline.
What is the right way to build products? Earlier in my career, I would have told you everything should be AB tested, and that you should build only as little as you need to validate a hypothesis. Every problem should have user research involved at the beginning, aligned on the problem instead of just validating or invalidating solutions. Every key result should be outcome based. Every engineer, designer and product manager on the team should be involved in defining the problem and the solution. These are all good ideas. However, once you add enough of these “best practices” up, it reads kind of like those articles talking about the morning habits of the most successful people in the world. If you actually try to follow all of those habits, it would take you six hours a day and cost a lot of money. I was once reading an article about what a futurist at Google eats for breakfast every morning to live longer. The article added up that his diet of food and pills cost him $1 million per year. My morning ain’t that long, and I ain’t got that much money.
or subscribe with
Join 3,100+ readers for one email each week.