Monday 3-2-1 – mentors, scrum constraints, productivity offenders 💡
Hey, Luca here 👋 welcome to the Monday 3-2-1 ✨
Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.
You will also receive the regular long-form one on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
🔨 Retool Workflows
I have been a big fan of Retool for years, and I am happy to promote it in the newsletter today.
Retool is launching a new product called Workflows, which helps you build powerful automations fast, with all the hackability you’d expect as a developer.
Stop provisioning infrastructure and maintaining one-off scripts. You can write and automate cron jobs, custom alerts, and ETL tasks 10x faster with Retool Workflows.
Back to this week’s ideas!
1) 🌱 Look for mentors outside your company
Having mentors you can reach out to is one of the best ways to supercharge your personal growth.
If you are not able to develop such relationships within your company, you can look for them outside. Here are a few places you might want to look at:
Your network — this is obvious and should be your first bet. Think about people in your network you would be happy to get mentored by, and reach out to them. You may ask directly if it’s ok for them to have periodic calls, to keep each other updated and get their advice. You will be surprised by how often people are happy to do that.
Communities — engaging in communities is a great way to get “distributed” mentorship and get to know new peers you can build relationships with. This is exactly what we are going for with the Refactoring community. Other related communities are also: Engineering Managers, Rand's Slack, and Dev Interrupted.
Professional coaching — there exist platforms where you can get professional coaching and mentorship. I did some coaching myself on BestPracticer, which is very good. Other options include CTO Craft and private mentors.
2) ⛓️ Why Scrum feels constraining
Scrum gets a lot of flak for many things these days. Most of it revolves around overhead.
To many teams, Scrum feels too constraining, so they either give up parts of it, or move to a different process entirely.
Why is it so? Scrum is designed around a single, powerful idea: work in short cycles.
Sprints are the central unit of work, so (almost) all ceremonies are scheduled on a Sprint basis. And there are plenty of them:
🗺️ Planning — to lay out the work to be performed during the Sprint. At the beginning of each Sprint.
🔍 Review — to inspect the Sprint outcome and sign it off. At the end of each Sprint.
🗳️ Retrospective — to plan ways to improve the process. At the end of each Sprint.
☀️ Daily Scrum — for coordination and to inspect progress. Everyday.
These are all legit activities. Every team needs to perform them in one way or another, whatever framework they choose. Anchoring them to the Sprint duration, though, doesn’t always feel right.
Whatever Sprint duration you choose, you may want to do something less often, and something more often than that.
Let’s take a bi-weekly Sprint as an example. Here is common criticism from startups I talk with:
Planning needs more time — “to deliver valuable product features we need longer cycles of planning”.
Review should not happen at the end — “we review work continuously and need to release multiple times a day”.
Retrospective is shallow — “two weeks are not enough to discover meaningful insights about the process”.
Daily Scrum is a burden — “most of the time coordination is easy and the ceremony feels like wasting time”
These are not absolute pitfalls: any of these may or may not apply to you.
The central point is that for many teams Scrum manages to be too much and not enough at the same time.
Don’t be dogmatic — adapt the process to your team. It’s ok to use Zombie Scrum.
3) 🙋♂️ The biggest offender to devs productivity
Consider the 2017 Pluralsight survey about productivity.
Among other things, people were asked to rate the things that drain the most productivity from their days.
As it turns out, the biggest offenders are… other people! Either in the form of meetings, or waiting for them to do stuff, or more.
I wrote more on dev productivity and how you can help as a manager in a previous article 👇
And that’s it for today! If you liked the article, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
I wish you a great week! ☀️