11 Comments
User's avatar
Michał Poczwardowski's avatar

Just forcing ourselves to write things down or put them on a scale triggers reflection.

That's why I find "knowledge maps" to be something worth implementing, and I use them in a similar format.

P.S. Thanks for all the mentions & support, Anton! It means the world to me. I'm glad you found it valuable.

Anton Zaides's avatar

You are welcome! :)

Just J's avatar

Skills mapping ended the chaos in building our squads. I implemented it with my teams and added interests too—key because teams excel not just on skills, but when passions align with business goals.

Gaurav Jain's avatar

Love the structured approach, thanks for sharing Anton! Is there a template available for that spreadsheet somewhere?

Bruno Oliveira's avatar

You should proofread before posting, I am put off to even continue reading when there's typo every couple of lines

Anton Zaides's avatar

Thanks Bruno, appreciate it! Fixed what I found, will be more diligent.

At least you know it was not written by AI :)

Kacper Wojaczek's avatar

As I was reading it I was wondering if you're going to mention "task relevant maturity" because it's a neat framework that applies here well 😅

Great stuff as always!

Anton Zaides's avatar

Haha thanks Kacper! :)

James Riall's avatar

I appreciate the subtitle of engineering management in a sentence is a very likely an oversimplification (so apologies if this feels nitpicky) however I'd fundamentally disagree that matching resources to mission is truly at the core of being an effective engineering manager. I think the core thing that this sentence misses is what is the mission? In many ways I see the most important aspect of my job being to make sure that the mission is actually valuable to the company. Resources permission is obviously important but if the mission is fundamentally misguided and does not have value to the company then no amount of smart resource matching is going to save it. Very often the highest leverage use of my time is to be working with business stakeholders, execs, product managers, engineering leaders, engineers etc to ensure that what we're building actually serves an important business need.

Anton Zaides's avatar

Yeah it's definitely an over simplification :)

I think the second part 'and how to support them' enacpulates more than just matching resources to mission.

I fully agree with all your points though!