4 ms·
I agree with this advice, and especially the follow up comments about being well-rounded in general. But one thing I hate is when a business or a manager tries
by p4wnc6 11y ago
I agree with this advice, and especially the follow up comments about being well-rounded in general.
But one thing I hate is when a business or a manager tries to politicize this whole "t-shaped skills" buzzword, by arguing that importance of generalist skills entitles the business or manager to almost completely disregard someone's specialization.
If you hired someone as a machine learning expert, and instead you've got them working on a legacy Ruby on Rails codebase or going down some rabbit hole about containerization, then it's gone too far. Yet politically, this will be defended endlessly in the name of "team player" and "business bottom line" HR code words.
But specialization of labor is hugely important to society. We need people to be deep experts, and for the trend of getting deeper and deeper into a field to continue, and well-defined roles within an organization are important for this. And yes, this does require managers and planners to work very hard to actually understand the business's needs, so that they can hire a machine learning engineer when they need one, instead of hiring one, then trying to repurpose the engineer into a Rails engineer by appealing to "be a team player" nonsense.
Any way, I think it's just important that as good as generalization, well-roundedness, and basic curiosity are, developers and knowledge workers especially have to be really pedantic and adamant that businesses respect specializations. Don't let the politicization of "be a generalist" get used as an excuse for your employer to stop respecting your specialization.
This is a major reason why I dislike the trend of "full-stack" development. It's great when developers really do have full-stack skills. But it's a huge red flag about a company when they actually want, and encourage, people to work in an essentially purely generalist capacity. It can often mean the company is either trying to get by cheaply (i.e. they're happy with relatively lower quality work from a generalist working in a specific area that is not the generalist's specialization) instead of seeking higher quality solutions through the appropriate specialists, or else they are just not doing the hard work of actually mapping their business needs correctly onto the skills that different specialists have, meaning that "full-stack" is just a hiring buzzword to avoid hard work somewhere up the staffing foodchain, and build in plausible deniability when it doesn't work out (e.g. "But we hired full-stack people...").
- pottereric 11y agoGreat points. One of the things that I tried to point out is that the breadth of your skills specifically supports your specialty. A company should appreciate your breadth of skills because it makes you better at your specialty.
- danieltillett 11y agoI think there is a difference between hiring someone as a machine learning expert with the intent of having them work as a ROR maintainer and hiring the person and asking them later when an urgent need comes up. If you are a small company growing rapidly it is impossible to anticipate all future needs in advance. This means on occasion you get mismatched between skills and needs.
- p4wnc6 11y agoIf this happens once or twice and gets resolved quickly, then sure it's OK. It can happen, and even if "team player" is often misused as a politicized HR code word, most of us developers still do want to be team players in the real sense, and so helping out is not a problem. But if the issue lingers over time, either because the small company doesn't want to foot the bill to hire an appropriate specialist, or because the company tries to paper over the wrongness of the on-going situation by acting like this sort of "team player" working-outside-my-speciality-because-someone-claims-it's-urgent status is just "how start-ups work" or "that's just start-ups" or "everyone's got to wear many hats" or whatever other bullshit, then that's a huge red flag. It means that not only did the company fail to plan for its needs (which should be some cause for concern, but not catastrophic since start-ups are hard), but even more, after learning that they didn't plan staffing correctly, instead of considering the deleterious burnout effects it might have on a specialist to force them to work way outside their area for prolonged times, the company just doubles down on it and even tries to build their company culture around it, as if "just do what you're told, no matter how hilariously far off it is from what we said you'd be doing" is a centerpiece of company culture, and indeed that somehow that's "just how it is" at any start-up. So, even if there is no intentional deceit or planned bait-and-switch, it's still a big red flag if this happens a lot and/or doesn't get resolved quickly. If you are a specialist, any employer who doesn't care enough about your specialty to be sensitive to the request to make you work way outside of it is really bad news for your career, unless you have other reasons for wanting to work there that, for you personally, supersede however much you value career progress in your chosen specialty. At the very least, companies should be apologetic about this when it happens, and should really work to find a compromise that doesn't cause burnout or create big gaps of time on an employee's work history during which the employee is not gaining experience related to their actual career specialty. If managers can admit the situation is not ideal, and level with you about the business emergency causing it, that's somewhat better (though still not an excuse for it to linger on for a long time). But if the business can't be bothered to admit they are doing something really suboptimal, something specifically fucking with your career progress and ability to gain experience, then it's probably time to just move on to another job. The company's not showing you any loyalty at that point, but they are expecting a pretty extreme form of loyalty and trust on the engineer's part.