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
🎒 Hiring & Onboarding
You will also be receiving 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:
1) 🎽 Reactive vs proactive coaching
In the past few months I have coached several engineers and managers. One thing that I learned is that coaching needs a constant push / pull dynamic.
Typically, either the coach or the coachee takes a more proactive attitude, while the other is more reactive.
When the coach is in reactive mode, conversations are driven by the learner’s stated needs, using questions like: “what are your current challenges and opportunities?”. This has a dependency on the learner to be self-aware and proactive, and it is generally easier to execute for the coach.
It doesn’t always work, though.
Sometimes, coachees need to be pushed, and you have to switch to proactive mode:
You may directly suggest skills for the learner to develop.
You may ask about feedback they received from managers and peers to get clues about direction.
You may ask about performance reviews, 360s, and any other artifacts that may be helpful in assessing how to improve.
The same coaching style, just like management style, simply doesn’t work with everybody.
2) 🔨 Create good tasks
Over time I have found that many problems that plague engineering teams, like bad estimates and missed deadlines, are considerably mitigated by creating good stories.
A good story (that’s how I usually call atomic tasks, but you can call them whatever you want) has three main qualities:
🤏 Small — it never requires more than a few days of work.
👌 Clear — engineers understand what needs to be done. To hit this consistently, both PMs and engineers need to be involved in the creation process — to refine, correct, and possibly split the story in multiple ones.
🤝 Independent — it can be deployed in isolation. If it is part of a larger release, you should be able to deploy it anyway and put it behind a feature flag.
Out of the three, the most important one — by far — is being small. In fact, being small also helps with the other two:
A small story makes it easier to spot missing or unclear requirements.
A small story is more likely to be independent from other tasks.
3) 🎒 The three main hiring sources
There are three main sources of candidates when it comes to hiring:
☕ Network (low reach + high context)
🎪 Communities (medium reach + medium context)
📋 Job Boards / Aggregators (high reach + low context)
As an employer, you can evaluate these channels based on two factors: Reach and Context:
Reach: the more people you can reach, the more people you have the chance to convert into employees.
Context: the more context people have in advance into your company, and the more you have into them as well, the easier it will be to find good matches.
More about hiring channels 👇
And that’s it for today — I wish you a great week! 🚀 If you liked the article, consider doing any of these:
1) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. That also gives you access to the community and the curated library.
p.s. 30-days money-back guarantee, no questions asked!