Engineering talent/skill tiers?
-
A long while back, perhaps influenced by my wonderment of software engineers that worked at "software for building software" product companies I met at conferences and knew from Microsoft, I used to believe there was a kind of skills tier for engineers.
-
[3] Corporate IT; you are building software solutions to business problems
-
[2] Consulting companies; your company was hired to solve problems Corporate IT couldn't, and need to know how to solve business problems with code and sell yourself while doing so
-
[1] Products company; the most elite, you company sells things they can't do and don't want to pay consultants to build, so you need to build a sellable product with code that can solve business problems
The companies of [1] are the hardest to get hired for, most in demand, and the best place to be as an ambitious engineer. I don't believe in this talent tier anymore.
What do you think?
For more context, here's my take on this (along with my take on marketing talent/skill tiers, which may be just as naive.
@apapadimoulis said in Chōwa has been published, give me praise and congratulate me! And some feedback:
Very few engineers want to work for companies that build software products, because product-minded organizations are inherently marketing-driven. You aren't solving problems from the business per say, you're solving problems from the marketing department, who are trying to sell a product that solves problems from a business.
Even fewer want to work for software product companies that build software in our niche, because now you're just solving marketing problems. A marketing person can't possibly understand the needs of software engineers better than a software engineer, so marketing and engineering must be tightly integrated. Most engineers feel a lot more comfortable writing code.
For marketing folks, I think there's a talent/skills tier.
- Ad agency that doing B2C marketing (think: Cocacola's advertising agency)
- Ad agency that does B2B marketing (think: Salesforce's advertising agency)
- Corporate Marketing team at B2C (Cocacola's marketing department)
- Corporate Marketing at B2B (Salesforce)
Within the lowest (4th-tier), consider our niche (or any other highly-technical one): you will never hope to truly understand it, and a technical mistake can undo a lot of goodwill within prospects and customers. It's a scary tier/niche, and not many want to do it.
-
-
@apapadimoulis said in Engineering talent/skill tiers?:
What do you think?
The problems in each of your tiers are certainly very different and require slightly different skill sets, but I don't think there's any way to order them. For example, in corporate IT, you may need to develop new features in incomprehensible legacy software behemoths nobody fully understands without breaking anything, while navigating the political minefield that inevitably exists at every large company. I wouldn't exactly call that easier than consulting or developing a product. Many engineers from products companies would give up immediately, while the consultants would try to sell you a completely different solution that will exhibit the same problems once it reaches feature parity.
-
I've worked in all three software development areas, and from my own observations there isn't much difference in software skill. There are differences in soft skills, the first one requires political ability, the second one requires marketing ability, the third one requires a blend of politics and marketing.
You can be a complete idiot in all the with regards to development, because there are too few software developers. In my opinion, a great majority of people working in the field would be better somewhere else. I believe that software would be written faster with higher quality if this majority were to leave the field.
That said, I do believe there are tiers in software development.
- The idiot tier, people that are regularly outperformed by graduates. Often stay at the same place for tens of years. Often a net negative on productivity because of their face-puncing grade code and inability to solve problems.
- The graduate tier, these usually think they know everything, having completed their education recently. Except for unicorns, they need supervision and can't be left to their own devices.
- The decent tier, can work with existing code and solve simple problems. Takes a bit of time to figure novel stuff out. Code usually stays out of face-punching grade, can be left to do their thing as long as it's not complex. For the love of Idun, do not let one of these design a system. It will be a horror.
- The craftsman tier, can do most things in the stack and tooling, but has an area where they are better and usually outperform others, usually in both speed and quality. With a few failed tries behind them, these can both design and build systems.
- The unicorns. These can learn a new skill faster than most, grasp complex problems easily, and intuitively pick better solutions. They work faster and with higher quality than most even if it's an area they haven't even worked with before. In areas they have worked with before they wildly outperform others. You can usually tell if a graduate will be a unicorn within weeks of hiring one. They will fail their first couple of attempts at systems design, but will not do the same mistake twice. Usually has the entire system they are working on in their head.
Because management doesn't seem to be able to tell the tiers apart, except graduate, they all get paid the same. Me being a meritokrat find this annoying. If you have a far superior output, your pay should also be superior.
-
@Carnage said in Engineering talent/skill tiers?:
That said, I do believe there are tiers in software development.
- The idiot tier, people that are regularly outperformed by graduates. Often stay at the same place for tens of years. Often a net negative on productivity because of their face-puncing grade code and inability to solve problems.
- The graduate tier, these usually think they know everything, having completed their education recently. Except for unicorns, they need supervision and can't be left to their own devices.
- The decent tier, can work with existing code and solve simple problems. Takes a bit of time to figure novel stuff out. Code usually stays out of face-punching grade, can be left to do their thing as long as it's not complex. For the love of Idun, do not let one of these design a system. It will be a horror.
- The craftsman tier, can do most things in the stack and tooling, but has an area where they are better and usually outperform others, usually in both speed and quality. With a few failed tries behind them, these can both design and build systems.
- The unicorns. These can learn a new skill faster than most, grasp complex problems easily, and intuitively pick better solutions. They work faster and with higher quality than most even if it's an area they haven't even worked with before. In areas they have worked with before they wildly outperform others. You can usually tell if a graduate will be a unicorn within weeks of hiring one. They will fail their first couple of attempts at systems design, but will not do the same mistake twice. Usually has the entire system they are working on in their head.
Because management doesn't seem to be able to tell the tiers apart, except graduate, they all get paid the same. Me being a meritokrat find this annoying. If you have a far superior output, your pay should also be superior.
I feel kinda odd about this listing, because - while I've encountered a similar sentiment often enough to believe it a fair reflection of reality - it seems to me that pretty much anyone below the craftsman tier should be let go as unfit for the role, with two exceptions: the graduates, who understandably need to make the leap from academic to real-world problems and the top level of the decent tier, because somebody needs to do the grunt work on a sufficiently big system.
On the other hand, at this stage of my professional life I've designed and implemented a number of systems from the ground up, typically starting from "it would be good if we could do this thing" to which my answer is usually "sure, we can do that" (less often: "yes, we can do this on a technical level, but getting the users on board may be a different thing entirely") and the thing gets done. I would expect this to be the reasonably expected level of performance, but looking at the above list, it's almost - if not - unicorn level.
I don't think I'm that good.
-
@GOG said in Engineering talent/skill tiers?:
I feel kinda odd about this listing, because - while I've encountered a similar sentiment often enough to believe it a fair reflection of reality - it seems to me that pretty much anyone below the craftsman tier should be let go as unfit for the role, with two exceptions: the graduates, who understandably need to make the leap from academic to real-world problems and the top level of the decent tier, because somebody needs to do the grunt work on a sufficiently big system.
That assumes you have more qualified candidates than slots. If we do, they aren't making their way through the door. I'd love to be rid of the idiots, but while they're probably a net negative in terms of money, marketing won't stop selling new contracts until we can staff up appropriately (software is customized for each client), so we don't really have any choice but to keep them. If the client isn't profitable, well, that's not my problem.
-
I currently work at a company that develops software for customs brokers. I'm not interested in the customs brokering business as I find that stuff extremely boring and I know only the bare minimum needed to do my job. While at least I can develop on my own, on any web stuff I get stuck using ancient JQuery instead of any Javascript frameworks because half of our customers still use Windows XP so I need to be certain that my code can run on the web browsers that run on XP (and also getting Webpack to work is a nightmare, let alone getting it to work on a ASP.NET not Core MVC solution) so I can't find work at another company because everyone wants Angular or React experience.
Also on the current project I am working on they expect me to be on call after work to solve any random minor problem that any random customer finds ASAP. Last time they texted me half an hour after my work time is over to solve a problem where sometimes when a customer enters a quantity field and a unit price field the total field doesn't get filled and before I got to debug the problem I got a sudden call with my boss and the customer liason getting pissed off at me for not fixing the code and I had a break down.
I wonder what tier I am?
-
@magnusmaster said in Engineering talent/skill tiers?:
Also on the current project I am working on they expect me to be on call after work to solve any random minor problem that any random customer finds ASAP. Last time they texted me half an hour after my work time is over to solve a problem where sometimes when a customer enters a quantity field and a unit price field the total field doesn't get filled and before I got to debug the problem I got a sudden call with my boss and the customer liason getting pissed off at me for not fixing the code and I had a break down.
I wonder what tier I am?Working in horrible company tier.
-
Monkey Tier: They immediately say everything is too hard. If pushed to do it anyway, they will spin their wheels for as long as you'll tolerate it.
Dumb Squirrel Tier: They are unable to remember anything. They write jobs to fix jobs to fix jobs to fix buggy processes. Does not matter if they wrote the buggy process.
My Friend Bob: Brilliant and somehow positive. On the very short list of people I'd trust with a project of importance.
Rick: Unwilling to say "that's a great idea!" when Shaniqua or Pajeet suggests suppressing a fire by throwing gas on it. Also unwilling to share the blame for the resulting explosion when the team decides to do it anyway.
Retired: Free to do their own thing because nobody can hold a steady income over their head.
Earth 151: Where the rest of TDWTF readers live, except whoever flips at me over style nazis.
Earth 152: Flips at me over style nazis but might be alright otherwise.
-
@Zenith said in Engineering talent/skill tiers?:
Dumb Squirrel Tier: They are unable to remember anything. They write jobs to fix jobs to fix jobs to fix buggy processes. Does not matter if they wrote the buggy process.
I have just the image for these people:
-
@apapadimoulis said in Engineering talent/skill tiers?:
[1] Products company; the most elite, you company sells things they can't do and don't want to pay consultants to build, so you need to build a sellable product with code that can solve business problems
Not necessarily. For a lot of time the company just don't want to wait people to build a system from ground, so they buy finished products from these company and customize it for their need. (Say, SAP, or Epicor, or MS Office with lots of reports built with VB scripts)
======
Btw, IMO it's really hard to tell. I've met and hired a F4 graduate that didn't even study till F5 and attend the public examination, but can write decent PHP and ActionScript (That was 2006 and Flash still was relevant technology), and I've interviewed CS graduates that couldn't do anything that's not explicitly taught by someone before.
I can tell if someone is really interested in I.T. just by asking the most interesting (Not proud, or have sense of accomplishment. Just interesting) thing the candidate have done, and see what the candidate choose to talk about, and listen the tone they use, and pay attention to the level of detail they went when talking about it. However it's only one of the factors that makes a good hire.
It's a very complex topic. (Topics regarding "people" are always complex)
-
@Unperverted-Vixen said in Engineering talent/skill tiers?:
That assumes you have more qualified candidates than slots. If we do, they aren't making their way through the door. I'd love to be rid of the idiots, but while they're probably a net negative in terms of money, marketing won't stop selling new contracts until we can staff up appropriately (software is customized for each client), so we don't really have any choice but to keep them. If the client isn't profitable, well, that's not my problem.
Agreed.
At one of the company that I worked, the highest position for each department, with the exception of HR and Accounting, is governed by how many staffs are there in the department. So the managers of each department have the incentive to fill any headcounts approved as quickly as possible.
The manager is sane enough to not giving any important tasks to them, unfortunately this also mean the tasks are only distributed among those who can do.
The same goes to any outsourcing company who receives government T-Contracts. (For those who've not heard me explain it, the "T-contract" in Hong Kong Government operates like this: The government opened new project and need a team of developers work on it. So they published requirement to job agents joined the scheme and let the source candidates to fill the contract based positions at fixed price - usually at price higher than market value. When a candidate secured a position, job agent get the difference between the government-given-package and the salary negotiated between the candidate and the job company. The candidate is now hired under the job agent and not the government, and usually have little to none benefits package - some not even have medical insurance.) The job agent will try to secure as many position as possible, with little concern on whether the candidate is "good fit".
-
@apapadimoulis said in Engineering talent/skill tiers?:
What do you think?
I think you're mixing concepts: companies vs individuals. I'm sure you can find all sorts of individuals at all sorts of companies.
You might not find people who can't FizzBuzz writing software at Google but I'm sure they have plenty of people who make all sorts of dumb mistakes. It also feels like you've never tried to use many "software products" out there.
It feels like you're projecting some of your experience. I honestly don't know much about Inedo but I'll take your word that it's nothing like Office Space. I'd be willing to believe it's because you've done a really good job creating a functional culture and atmosphere. I've seen that and its opposite at all kinds of companies, not just software.
-
There is a bit of a mix of 'engineer talent' and 'corporate culture' in this thread. Although they are inter-related, because a top tier engineer probably won't join or stay in a WTFy business without other reasons, there are still all sorts of people in all sorts of companies.
Here's my experience of people:
- 'Should be doing another job' tier - can't even follow instructions or understand basic concepts like testing and class structure (I've used C#Java so it's OO, but the same would apply for coding concepts in other types of language). Fortunately I haven't met many of these, but offshore shops seem to be full of them
- 'Labrador' tier - keen and want to help, and can do what you ask them to, but keep forgetting simple things and have to be reminded of them
- 'Basic competence' tier - can understand how to write decent code and fulfil specified requirements, but not really much in the 'big picture'. Having some of these people on your team is good, there are always boring but important tasks to be done and these people typically get less bored by those
- 'Engineer' tier - as well as the above, can do some component design and understand how a feature should fit into a wider codebase in a coherent manner. (Or analogously, for testers, how a new system test can fit into the wider test architecture.) These guys are valuable.
- 'Creative' tier - as well as the above, can visualise the system design and participate in the design of improvements to the whole system, understand how components fit together and make sure that new component design fits the model. These guys typically end up with a title like 'architect' and, if they're good, are the most important people you have in the long term.
And your corporate culture needs to not frustrate the creatives by keeping them in too small a box so they can't get involved in systems design and improvements.
-
@apapadimoulis said in Engineering talent/skill tiers?:
A long while back, perhaps influenced by my wonderment of software engineers that worked at "software for building software" product companies I met at conferences and knew from Microsoft, I used to believe there was a kind of skills tier for engineers.
In addition to what's been said about mixing companies/individuals, I really think your classification reflects more what you've seen than some sort of absolute truth. Although maybe that applies to "software for building software" (which isn't what I'm doing, granted), but I doubt it. In my niche technical domain, there are areas where we have the more or less the exact opposite tiers:
- [1] Products company; the most elite, you company sells things they can't do and don't want to pay consultants to build, so you need to build a sellable product with code that can solve business problems
Products companies will churn out software that's useful to us, that might handle all the boring bits (i.e. not really related to our technical domain, such as database management), but we seldom use their tools in our technical domain, and whenever we talk with them they are usually clearly not up to scratch in that domain.
- [2] Consulting companies; your company was hired to solve problems Corporate IT couldn't, and need to know how to solve business problems with code and sell yourself while doing so
We don't use much of them, but some of the first tier (products company) have some highly customizable/on-demand development that put them in this category. Usually they are pretty good at the very niche-inside-the-niche that justifies us using them, but apart from that, they're pretty average. And often the niche-inside-the-niche is so small that using them is more about convenience or habit than a real need (i.e. we sometimes stop using them and haven't that much of a business problem replacing them with something, even if that something is technically inferior).
- [3] Corporate IT; you are building software solutions to business problems
This is where the true experts of the technical domain are (either here or in one of our direct competitor, who is obviously never going to do consulting [2]/products [1] for us...). They are the best, at least in that technical domain.
Though there is a level [4] above (in our case), which is companies that buy our services and own the data on which they are applied -- but while some of them are technically very good (sometimes very good people from [3] get hired by a company in [4]), they don't do software development in any significant way, so they're a bit out of the scale.
The companies of [1] are the hardest to get hired for, most in demand, and the best place to be as an ambitious engineer. I don't believe in this talent tier anymore.
The companies of [1] (products companies) are the easiest to get hired for, basically because they are bunch of graduates changing every 2 years max, doing first-line support/bugfixes but without any deep knowledge of the domain (so support is boring because all you can say "have you tried clicking here?" and bugfixes is an endless treadmill because you fix the symptoms without understanding the cause).
-
@remi said in Engineering talent/skill tiers?:
they don't officially do software development in any significant way
Quite often they'll have people whose main job (by proportion of time and effort spent) is actually software development despite them vehemently claiming otherwise.
-
@dkf Meh. In my very specific case (I wouldn't claim universality in any way), I know for sure that in many such companies, they really don't. At best they'll have a couple of research people hacking around for research purposes. So of course from time to time that software might morph into something that's really used even if they don't say so, but that's not very common.
A couple of other companies do have their own software development teams, but then they tend to be pretty upfront about it, and will simply not do business with us (or our competitors) in that specific technical domain. Or if they do, they'll be very clear about what they decide to do internally vs. what they pay us to do. Which I guess puts them in the [3] bracket, and ourselves in the [2] bracket in that case, but since they do that explicitly to benefit from in-house technical knowledge that we don't have, it still fits the overall picture of [3] > [2] > [1], just shifting my own position in it ([2] rather than [3]).
