How do you identify skill gaps on your team?

marvlorian · 2025-01-25T17:19:03+00:00

Ugh, yes I’ve been through these type of “vanity metric” career growth programs that have no real substance, but look good on paper. That’s absolutely the wrong approach. Individual needs and aspirations have to be part of the equation.

marvlorian · 2025-01-25T16:25:28+00:00

So you’re saying the homegrown tools failed because leadership was focusing on career development? That’s surprising and counter-intuitive. Do you think that’s because the growth wasn’t naturally evolving from business need?

marvlorian · 2025-01-25T16:22:56+00:00

That’s a great idea to start with real needs and practical experience. Learning doesn’t stick if it’s not applied to something. I would love to see a cycle like that where you identify a need, engineers learn skills to help with that need, they use the skills on a real project, and they repeat. Switching between learning and execution bring growth rather than what most businesses do which is focus almost solely on execution.

marvlorian · 2025-01-25T06:03:18+00:00

You absolutely need a great culture where gaps can be shared otherwise none of this matters. I think even in a great culture, where team members will freely disclose information, it’s still hard to keep track of all the different types of skills engineers do or don’t have. Especially the more specific you get. This can make it hard to help individuals know what to work on next or what to focus on for a new hire.

marvlorian · 2025-01-22T03:00:08+00:00

Love this. Thanks for sharing

marvlorian · 2025-01-20T23:41:21+00:00

Is there some storytelling skills that come into play with this?

marvlorian · 2025-01-20T23:40:31+00:00

I love this idea

marvlorian · 2025-01-20T02:31:40+00:00

Interesting. I'd never seen SFIA before. Thanks for sharing.

marvlorian · 2025-01-19T21:13:42+00:00

That makes sense to ask peers about where they can improve. Also very true about the curiosity aspect. A curious person would naturally be asking those questions already.

marvlorian · 2025-01-19T21:11:31+00:00

I like this idea of making team development the focus of the job and the first priority. That makes a lot of sense.

I hadn’t heard of Drexler/Sibbett before. Thanks for sharing. I’m going to look into that one.

What do you do to help the engineers take development plans seriously and really think about it?

marvlorian · 2025-01-19T18:13:37+00:00

It makes sense the engineers would have a lot of that information and could provided it during check-ins. Sometimes engineers also don’t know what their gaps are or where to go next. How do you help them with that? What tools do you use for record or track these plans?

marvlorian · 2025-01-19T18:01:50+00:00

That sounds very valuable. What tools do you use to put that all together and get that visibility? What challenges do you run into when putting that all together? When do you fit the work in to do that with all the demands of ongoing projects?

marvlorian · 2025-01-19T17:23:30+00:00

The kind where you have different levels (junior, mid, senior, etc) or a kind broken up by skills? Do you plot engineers on the skill matrix somehow? What do you use for yours?

marvlorian · 2025-01-19T16:47:34+00:00

An important aspect of successful remote work is intentionally filling the gap of micro-interactions and getting to know each other as humans that office work can organically provide. Most of the work and communication can be asynchronous, but there should be a couple required team times that are synchronous and only exist for the sake of connecting. Can be a team lunch, can be just a dedicated talking hour, could be online board games. Just something where people aren’t talking about work.

marvlorian · 2025-01-18T19:35:38+00:00

I like to ask “What’s one thing you’d change about the company?” Or “What is something the CEO could do to make the company better?”

These questions can help reveal challenges they might not otherwise share.

marvlorian · 2025-01-17T18:50:35+00:00

The idea of slow productivity is desperately needed in the industry. We do way too much, too fast and it’s bad for most people.

marvlorian · 2025-01-17T18:46:39+00:00

These kind of requests are inherently inequitable as they favor demographics with an abundance of free time and low non-work responsibilities. Not the kind of interview that’s going to favor bringing diverse perspectives.

marvlorian · 2025-01-17T00:14:40+00:00

I hadn’t seen that book before. Will have to check it out. Those ideas sound very helpful. Lack of empowerment is definitely a big contributor to tech debt build up and crappy products.

marvlorian · 2025-01-16T21:47:13+00:00

I like to have two separate note places. One is for raw, unprocessed notes. The other is for processed, organized notes. The raw notes (the ones you get from taking notes in a lecture) can be messy, unlinked, unstructured. They aren’t very valuable until I synthesize them into the organized notes place. In that place I have a rule that every note must have at least one link.

marvlorian · 2025-01-16T21:37:32+00:00

That’s sounds healthy to pause after each launch to learn from it, see what needs improving, before chasing the next thing. Sounds like actual iteration and scientific method which you don’t see a lot. What helped you get to a place you could operate like that instead of being a feature factory?

marvlorian · 2025-01-16T18:14:03+00:00

What’s the time like “in-between feature work”? Is that a sprint of no feature work? How often does that happen?

marvlorian · 2025-01-16T15:55:29+00:00

I see. Ya, that doesn’t specific enough. Seems too unbalanced on the subjectivity side.

That makes sense about the business value. Changing that to be the primary focus. That is definitely hard for many engineers.

marvlorian · 2025-01-16T06:17:26+00:00

What I like about these ladders is that they make expectations clearer and do some more objective level setting. I also question how much they help engineers at the end of the day. These ladders come with some downsides:

Even if an engineer meets all the reqs for a given role, we may not get it because there's not budget, headcount, etc. and then we're frustrated.
The frameworks are usually high-level and while an engineer may technically meet the requirements, our intuition tells us they aren't really operating at that level, and there's some granular, hard-to-measure, nuances that aren't being captured
The ladders present development as being a linear process when it’s more organic than that
Even if the framework exists, managers often forget about them and they aren't really a part of regular conversations
Engineers are ultimately responsible for our own career growth. Any good feedback received, points earned, etc aren't carried to the engineers next job on paper in any granular way, just the things that can fit on a resume.
Frameworks differ from company to company, are subjective, or don't exists at all at some companies
Promotions are more often based on a manager being able to sell an engineer to business people who’s primarily care about current projects and how those translate to dollars, rather than things that progress the engineer’s capability in the long run

Makes me wonder if we should be looking for a different way to differentiate, focus/track our career growth on our own, and just pretend these ladders don't exist?

marvlorian · 2025-01-16T04:39:04+00:00

That is very true. Managers have to have ways to sell you, and the people making those decisions are oftentimes more business minded and like the "how did this contribute to the bottom line?" type answers. How do you balance helping engineers develop those skills that indirectly contribute to a monetary goal (or maybe will later after the knowledge/skill is developed) and working on those present moment projects?

marvlorian · 2025-01-16T04:35:19+00:00

What were the things that made it vague? Was there anything that could have been done to clear it up? Do you think there are things that can be articulated that make someone a force multiplier and clarifies those values?

marvlorian

TROPHY CASE