Skills Gaps

All posts tagged Skills Gaps

What’s Wrong with Hiring Cheap?

Posted by tropicaltheartist on February 26, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , , . 1 Comment

kerry-rawlinson-TNl4aR3kidM-unsplash

Abstract: Hiring the cheapest candidate looks like sound business management, at face value, but cheaper employees can be problematic and companies may be screening out the very top talent they actually need to succeed in a highly competitive environment.  The ultimate, true, hidden cost of refusing to entertain the idea of paying fairly, to attract top talent, may be catastrophic for the viability of the company, in the long term.  The widely reported skills shortage has its roots in low pay.  Much of the best talent simply leaves the industry for good, seeking better pay elsewhere, or better quality of life.

With an exclusively financial focus, it would seem to be the case that if you can fill a certain job specification for much less money, it is a benefit to the business, but is it really?  Do people that offer low salaries really understand the consequences of their actions on the viability and competitiveness of their company?  Is a candidate that works for half the money really as good as the one that wants a higher salary and is the difference significant, if there is one?

Silicon Valley employers will tell you that penny pinching, when hiring talent, is roughly the same as guaranteeing your company won’t produce anything outstanding and will, therefore, fail to succeed in the highly competitive world of technology-based products and services.  They know that really good talent is scarce.  For every incremental dollar they pay for talent, the multiplicative effect on company value increases dramatically.

There is anecdotal evidence that, at least in the UK, pay scales for technical talent are lower now than they were ten years ago, for equivalent roles and skill sets.  Real wages have not only failed to keep pace with price rises, they’ve fallen, leading to lower material standards of living for technical talent.  Meanwhile, the complaint of a skills shortage regularly does the rounds.  What is the cause?  Why are UK-based companies so apparently unwilling to pay to attract the best technical talent?  Is low pay for technical talent an attitudinal problem, or a structural one, or both?

Many technical roles in the UK are filled through recruitment agencies.  As they predominate, the salaries they set are taken as the benchmark for all technical salaries.  In this process, the employer asks advice from the recruitment agent regarding salaries and the agent nominates a salary range on the basis of what they think they will be able to find talent for most easily.  There is pressure on recruitment agents to nominate low salaries, as they compete on price, which is ultimately tied to the salary offered (as a percentage).

Given their almost total stranglehold, as gatekeepers, on the employment market, the salaries that recruitment agents nominate, in order to keep their fees to employers low, fixes the salaries on offer to all technical talent.  Technical talent is forced into a “take it or leave it” position.  There is no possibility of negotiating a salary.  When a recruitment agent learns that a candidate requires a higher salary than that on offer via the advertised position, they simply screen them out of the recruitment process.

From the employer’s perspective, this means that they never even see the very best candidates, because the recruitment agent screens them out before their CVs are ever presented.  They remain invisible.  Employers are forced into settling for less than the best talent they need, because the salary has been established for the job specification in question.  The option of increasing the salary on offer to attract a slightly, or even dramatically, better candidate never arises, because no such candidate is ever presented to the employer.

Often times, the job specification asks for just about everything imaginable, while the salary attracts only those with, at best, a partial match to the job specification.  This attracts chancers, who are prepared to represent themselves as meeting all of the job specification requirements, while not actually having the skills and experience required.

The prevalence of chancers applying for roles has led employers to suspect all candidates of being chancers, to some degree.  This causes another problem.  When a candidate presents with broad and deep skills and experience, it can make their CV look less specific to the role advertised.  Consequently, they are assumed to be under-skilled for the role, whereas in fact the opposite may be true.  They may have such an arsenal of skills, that they make a small deal of the specific skill the role demands in their CV, even though they are more than accomplished in it.

Despite careful screening, employers frequently make offers to chancers who have bluffed their way through the process, claiming they can do more and have done more than they really have.  The problem with hiring chancers is that they are learning on the job, making costly mistakes that could have been avoided entirely, by hiring better talent.  While chancers are prepared to work for a relatively low salary, in order to remediate their work history, two chancers do not produce the same bottom line results, for the company, as a single top flight talent who asks twice the salary of each chancer.  It’s a false economy.

The moral to the story is that offering half the salary only attracts people that are half as good, if you are lucky.  They will not be able to produce the outstanding, breakthrough products and offerings that a really good candidate, who costs more, would.  If you want a higher rate of mistakes, as the candidate learns at your company’s expense, burning customer good will and competitive advantage in the process, hire inexperienced and cheap talent.

Setting low salaries for technical talent is a “red flag” signal, to candidates, that the company does not properly value the contribution of its technical people.  A company that is unwilling to move on salary, on discovering an outstanding talent beyond their nominal salary range, is kissing a valuable opportunity for outstanding performance and results goodbye.  On the rare occasions that top technical talent finds a company with a position to fill, sticking rigidly to a fixed idea of what the salary ought to be, without being open to negotiation, is going to guarantee that top talent goes elsewhere, perhaps to a competitor.

By the same token, working for too low a salary, relative to one’s skill set, sends the signal that you don’t value your skills, experience or contribution either.  This leads to abusive or difficult working relationships in both cases.

There is an ageist bias that works negatively in technical recruitment, as well.  Most recruiters, today, are drawn from the ranks of the Millennials, or those born in the decade before.  Millennials, it appears, think that nothing of significant technical merit happened before they were born, whereas in reality some monumental technical feats were accomplished, using computers that were too slow and which had not enough memory, to provide user experiences that were often superior to those provided by profligately wasteful, modern technology stacks.  I know of at least half a dozen of the finest engineers from that era, top talent, currently struggling to find a suitable role for their skills.  While their credentials are impeccable and their abilities beyond doubt, among their peers, recruiters born much later cannot understand or appreciate the value of these long work histories, it seems.  They are frequently overlooked for younger, cheaper, less capable candidates.  Employers are, again, short changed.  Talent is squandered.

About a decade ago, there was an enthusiasm for offshore development, because it was thought that much cheaper engineers could be hired to produce the same quality of result, due to differences in exchange rates and local costs of living.  While the engineers were often impeccable, the use of offshore development teams came with hidden management costs.  The most expensive part of using offshore development teams turned out to be in transferring the requirements and domain knowledge to remote developers.

Irrespective of how diligent, capable and dedicated they were, offshore developers struggled to produce the same quality of finished technical work as those that were embedded in the markets and geographies they served.  Rework was more prevalent and products mismatched to requirements were frequently produced, due to incomplete understanding of the problem domain, despite the best will in the world and sincere efforts to produce the right thing.  The enemy was simply the paucity and limited nature of the rich communication that is required to produce excellent technical things, caused by distance, language incompatibilities, differences in cultural norms and expectations, and time zone differences.

Offshore development proved to not be a route to cheaper results, but the effect on technical talent salaries was that it depressed them, because the perception arose that the same technical talent could be obtained for much less money.  Factoring in the additional costs of managing offshore development, however, this was never true, but that did not stop the chilling effect on technical salaries.  Offshore development often ended up costing more, in the end, than on shore development.

Very few of the best technical talents can afford to work cheaply, due to the cost of living where they are and their stage in life, with its attendant commitments.  Working at less than would be required to maintain a reasonable standard of living, in the overpriced real estate markets that characterise the location of most technical jobs, means that the technical talent must accept a considerably reduced standard of living, effectively subsidising their employer through their own personal sacrifices.

Having worked hard and incurred considerable expenses to become top flight technical talent, it is very unattractive to be required to accept a lesser remuneration today, than a decade previously, yet that is precisely the offer many technical employers are making to potential hires.  For this reason, employers can only fill their positions with people who are able to structure their living expenses to work for less.  This means single people, younger people and people with alternative or supplementary incomes (parental support, etc.).  That eliminates a lot of the very best people and the very valuable skills they have.  It also dooms the people that accept lesser salaries to permanently constrained lives, in which having children, for example, becomes impossible, financially.  Recreational and discretionary spending is also severely constrained.  Work becomes their whole life and drudgery.  Consequently, they become progressively more miserable, increasingly unwell and less productive.  Outstanding products will not pour forth from people working under such duress.

What many financially-oriented people, in a company, fail to recognise and acknowledge is that their company’s value derives critically from the talents they hire, especially in engineering.  Making people disaffected, financially distressed and grumpy, by underpaying technical talent, or else hiring the relatively incapable and inexperienced, puts the value of the entire company in peril.  Even the best marketers and chief executives cannot sell substandard products profitably, if produced by mediocre technical talents.

If a company hires somebody relatively cheaply, to do their hiring and firing for them, they often lack the experience and wisdom to really know what they are looking at, when the candidates for various positions they are trying to fill come in.  Their hiring decisions are apt to be sub standard.  There is also some evidence that they hire to protect their position, not to find the best possible talent for the company.  Feeling insecure about their own qualifications, they tend not to hire outstanding individuals who might eclipse them, within the organisation.  They rarely recognise exceptional talent, anyway.

In recruitment, the inexperienced hiring manager makes some characteristic mistakes.  For example, when technical people applying for a role have done a lot, in their career, it is a total misreading of their CV to assume breadth of experience means shallowness.  This perception arises when you fail to take into consideration the sheer length of their career, relative to that of a person who looks more specialised, but has only been working for a handful of years.  It is also a mistake to hire somebody that appears to be more dedicated to the narrow job specification advertised, because the limited range of their skills gives the impression that this implies depth, on their CV.  What you are actually getting is somebody with not very broad experience, not a specialist that will do superior work.

The lack of experiential breadth means the seemingly more specialised candidate will not know how to really do the job, because real working roles are rarely as narrowly and specifically defined as the written job specification suggests.  Broadly skilled candidates bring highly valuable, additional abilities to the company that the job specification writer may not even be aware the company desperately needs.  Inexperienced recruitment consultants and inexperienced people making the hiring decisions compound and exacerbate this issue, with their obsession with exact keyword matches between CVs and job specifications.  Buzzword compliance is a poor measure of ultimate candidate value.

Somebody struggling to make an entire career, specialising in just one thing, is not a better hire than somebody that has successfully accomplished many things, professionally, including the particular area of skill written up in the job specification.  The more broadly skilled candidate is the more valuable because, not only do they possess the depth necessary for the specialist role advertised, they can also readily adapt to do the thousand and one other things that a real job requires of them.  They are rarely in a position of not knowing what to do, when faced with challenges beyond the nominal job specification.

Strangely, underinvestment also has played a role in depressing technical salaries, in recent times.  While potential investors, with piles of cash, certainly exist, they are currently hoarding it, rather than investing it, for fear of the mass market not having the discretionary spending power to buy anything they might make or offer, produced by any enterprise they might invest in.  As inequality has increased, the tendency to impoverish the middle classes, which describes the economic status of the best technical talent, has also increased.  The richer the richest have become, the poorer the best technical talent has consequently become.  Potential investors are playing out a self-fulfilling prophecy, as their failure to invest guarantees that fewer people have the money to spend with any enterprise.  Enterprises, therefore, find it harder to make a good return on any investment.  As a result, good investment opportunities have become harder to find.  It’s a downward spiral.  Cash hoarders, ironically, are ensuring that the value of their hoarded treasures is more in peril of collapsing than ever before.

The perceived skills shortage has its origins in low pay.  Some of the best talents simply find better things to do with their lives, which are more remunerative or which offer a better quality of life.  As a result, they leave the industry for good.  Their skills are no longer available to potential employers.  Low pay for technical talent drives out excellent skills, leaving a vacuum in its wake and creating an artificial skills shortage.  There may be many candidates, for each advertised role, but the best skills are no longer in the market.  The overall quality of candidates is reduced, as the best and brightest simply exit the market forever.

Great talent, if you are lucky enough to find it, is worth every penny to a company and then some.  The returns on investment in outstanding people are always much more than any increments in salary required, to secure their services.  Setting salaries at too low a level screens out exceptional talent.  Those are the very people who are necessary to create extraordinary offerings.  No company can thrive, or even survive, offering unremarkable products, today.

The Stupidest Way to Design a Software-Rich Product

Posted by tropicaltheartist on January 27, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Leave a comment

cecilia-fornazieri-Yuik6-xIgoM-unsplash

Abstract:  Divorcing a product design’s key technical characteristics from its shape, feel and market appeal sets your company up to develop a product that works badly, even if it looks great.  Product development requires a broader developer skill set than straight-forward coding.  Saving pennies on product design, which will determine the fate of your company, is stupidly suicidal.

I’ve done a lot of full lifecycle product development, in my time, going from back-of-the-envelope concept, to refined minimum viable product definition, through to prototype models and onward to shipping product.  Most engineers that work for software product development companies have not.  It’s an important gap in their knowledge.  There’s much more to developing a great product than coding well.

When a company designs a new product, there is usually a lot at stake.  For one thing, the company’s entire future prospects may hinge on how successful the product is and how quickly it establishes itself in the market, after launch.  There is an entire product design discipline that goes under the banner of “New Product Introduction Processes”, which is necessary to ensure that the right product for the market is built, with the right characteristics, to make the product a runaway success.  Failing to do any one of the necessary new product introduction process steps has the potential to make the product fail in the marketplace.

A crucial part of the new product introduction process is the up-front ideation and product definition.  This is where the design tradeoffs are made.  Here, product marketeers and engineers gather to determine what product characteristics will be offered and a first cut at how those might be realised is contemplated.  Technology has limitations, but it also makes incredibly worthwhile and attractive product features easy to implement, if you choose the right technology.  Choose the wrong technology, or be forced into a compromised technology choice, for bad reasons and you may create a product that just doesn’t work in a way that is satisfactory to your customers.

Product design has to start somewhere and often, that’s in the design studio of an industrial design firm.  They will produce sexy, three-dimensional drawings and photorealistic renderings of a beautifully sculpted object, which will be the thing you ultimately ship as your product.  It can be a device (and often is), or else the visually appealing designs of some fancy web or mobile applications.  In both cases, some electronics and/or software will have to go into the design, to make it actually work, but industrial designers know little about user interaction, software and electronic components, in the main, so this tends to be an afterthought.  (N.B:  The better design agencies do have electronic design and user interaction design capabilities!)

If the industrial design agency is permitted to characterise the minimum viable product (MVP) on the basis of meeting the functional requirements in the brief, independent of any software and electronic engineering design input, a product release disaster can ensue.  A “look alike” prototype has been produced, but so far it looks good and doesn’t do anything.  Sure, tooling up for the sexy case or the fancy graphical design has long lead times, so you have to get there early, but what about the non-functional requirements of the product, which are an essential component of the product’s actual appeal to paying customers?

In stupid product design, it’s after the look-alike prototype has been designed and the MVP feature set determined by the agency that the technical staff are hired.  This is where the trouble starts.  Usually, to save costs, an outsourced development house is chosen.  The risk is seen as smaller, because the money spent on development is less than for a dedicated, in-house team.  It isn’t.  Here is what you sometimes (often) get:

Firstly, the developers will have no clue about your company, your market or what the product has to do.  They will share little of the cultural context and know almost nothing about the products that compete with yours.  In essence, they can code, but code what?

Satisfying the requirements of a user story in an MVP product backlog can be done multiple ways.  The solution can be elegant and make customers delightedly happy, or else it can be kludgy, awkward, and bass-ackward, causing endless annoyance and frustration to users.  Both solutions tick the agile development “done” box, but only one of them makes your company’s new product sell and maintains the goodwill and loyalty of the user base.  How can the remote developer tell which solution is which, with so little context and immersion into the world your company serves?

User stories require elaboration, but this becomes much harder to accomplish, if the product definition people are remote from the coders, in different time zones and with language issues to navigate.  Essentially, you are setting your product up for failure, because the high bandwidth, rich, frequent communication that needs to take place, between the developer implementing a feature in a user story and the person who wrote the story, as part of the MVP definition, is exceedingly difficult to schedule and accomplish.

Then, long after the industrial design agency has disengaged and moved onto other clients, it is discovered that the look-alike prototype is too small to put a big enough battery in it and there is no way to dissipate the heat generated by the electronics.  There will be a lot of software running in the background, you learn, so the unit will always be draining battery and running hot.  Even the sexy “home” button will have to be used much more often than anticipated and there isn’t the room to put in a switch with the rated number of switch actuations actually required.  There’s no room for a beefier switch.

Because nobody wants to redesign the sexy outer shell and scrap all the expensive tooling, at this late stage, a smaller battery is the compromise and the switch will, for certain, wear out within a few months of ownership.  Sadly, for sexiness reasons, the case is snapped together and bonded with superglue, in the factory, so there is no possibility of changing batteries in the field.  Suddenly, you have created a product with too short a battery life, which runs way too hot and which has a switch that fails within a few months that cannot be user-serviced or serviced at all, in the field.  Bravo!  Your product has gone from being a winner to being a dog last loser.

In product design, I always advocate a “work alike” prototype, before the “look alike” is made.  Why?  Well, it’s a chance to test the non-functional requirements that will be the difference between your product being viable or not.  You can test the battery life and heat dissipation.  That will tell you how big a battery you must include for the product to be saleable and successful.  You can also put in the switches, connectors and other things that the product needs to have, rated to a suitable lifetime of normal use.

For software applications, a work-alike prototype gives you the chance to run usability labs and make the software easier to use, before you freeze the wrong design in fancy, brochure-quality graphics, placing key functionality in terrible on-screen locations.

Having written some software to exercise this dog-ugly prototype and measured what’s going on, you now know how to constrain the sexy case design, so that it not only looks sexy, but it also provides a suitable enclosure for a product which actually works the way your customers need it to.  The sexy case is designed around the essential performance-determining technical components.  It doesn’t constrain them.

If you employ engineers that know about new product introduction processes, they also use the work-alike prototype to get preliminary EMC compliance and electrical safety tests done.  It complicates the new product release, but in so doing, it ensures that the product shipped will not have to be recalled, that everything works correctly, right out of the box and that the earliest adopters will not be product guinea pigs.  They can be first in line to buy the product and rely on the fact that it does what it says, in the marketing blurb.

From a software point of view, creating work-alike prototypes of the software, outside of the final shipping case design, allows early iterations around working product features.  They can be exercised, at an early stage.  You can discover that you don’t need that second front panel switch after all, or else determine that the product will be useless unless it has one.  You can also guide the look-alike prototype designers regarding human affordances, so that nobody tries to ship software with a cursor that is too small to actually touch, on the final miniature touch screen, or else places key functions in places that are inaccessible, unless you happen to be double jointed.

Product design is not a series of separated, isolated, serial operations.  It’s iterative, messy and interconnected, so different disciplines have to be prepared for resets in their progress, because a dependency discovers something unexpected, in their design work.  Product characteristics are not a gloss coat painted over a neutral technology platform.  They interact intimately.

To the customer, how the overall product works, what it is like to live with and how useful and relevant it is to their real lives is what counts most.  Putting lipstick on a pig doesn’t achieve the desired result.

It’s a form of self-inflicted, self-destructive, delusional insanity to try to shave pennies off the cost of your designers and developers, during the design of the very thing that is supposed to sustain the company.  If you cut your design effort to the bone, using the cheapest of everything, you get a crippled, vandalised product.  Given how much depends on the success of the product, it’s plain stupidity to think you can get away with throwing vital aspects of your key product’s design over various anonymous walls and hope for a coherent result.  It’s like shooting yourself in the foot, before you even launch.

Above all, use seasoned research and development engineers, with new product introduction skills.  Just being able to code isn’t enough.

What Don’t We Know?

Posted by tropicaltheartist on January 27, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , . Leave a comment

dex-ezekiel-fg8tdcxrkrA-unsplash

Abstract:  Development managers often conceal the fact that not everything the team needs to know actually is known (or can be known), at the beginning of a development project.  This leads to poorly designed products and missed deadlines.  Stakeholders are let down and feel deceived.  Developers are punished for other people’s deceptions.  It’s better to state the unknowns, honestly, even if you lose face, because honesty and transparency are paramount and lead to better software development outcomes.

One of the more insidious problems, in development, is intellectual dishonesty.  An architect, or development manager (or team) will be selected to develop some software product, or other, and there will be a lot of the company’s success riding on the outcome of the project.  Everybody knows it’s important and that nobody must be seen to be “difficult” or impeding the project, for no good reason.  The temptation to simply present the development exercise as one of simple, routine execution, based on well-known certainties and a full and lucid understanding of the requirements is immense.  In other words, there is a great deal of expectation that the technical team pronounce the project as “easy” and to offer iron-clad guarantees on cost, feature set, quality and delivery dates.  These guarantees, if given so robustly at the beginning of the project, are almost certainly fictitious lies.

The problem is that if the project is truly worth doing, it will carry some unknowns and risks.  There is little point developing something that already exists, which can be bought, so for something new to be made, there will be things that the development team will have to research, experiment with and discover; maybe a lot of things.  An intellectually honest manager, or software architect, would acknowledge the scope of the unknowns, imagine the best and worst case scenarios and detail them.  Unfortunately, that’s often not what happens.

We all have different experiences and expertise.  Not a single one of us shares the same track record as our colleagues.  We’ve all come from different backgrounds, product developments and technology stacks.  We also all have different interests, as people.  Some care about the details, others are clear on the big picture business drivers.  Nobody can know it all, but the temptation is to pretend you do.  That is pure posturing and it’s ridiculous, because it puts the software project that the company’s fortunes depend on, in peril.  It comes from a deep seated insecurity and a fear of being let go, if you don’t appear to have everything in hand, under control and fully understood, all the time.

Key project stakeholders, also aware of how important the project is to the fortunes of the company, will exert extreme pressure on the technical staff to come up with dates, costs, scope and quality promises they can bank on.  That’s what they need.  Their belief that a technical person can actually give them those guarantees, based on an insufficiency of information, is naive at best and foolhardy at worst.  In some cases, the non-technical stakeholders are merely Teflon coating themselves, in the event that the project doesn’t meet its goals, which given the behaviour of the key stakeholders, it almost certainly won’t.  At that unhappy moment, they’ll be able to point to the technical guarantor of project outcomes and throw them under the proverbial bus.

The technical person often succumbs to the political pressure to pretend to know what all the answers are and what product features are required, or about the problem domain in detail, when they really don’t.  They’re trying to save face and to please the other stakeholders, when the truth is that they may not fully understand the customer requirements, the industry that the product sells into, the competitive landscape, the technology choices for this particular project, the abilities and limitations of their development team members, the peculiarities of the tools they will be permitted to work with and a thousand other variables that can drastically impact cost, delivery date, feature set and quality, no matter how agile the development method employed.

The thing about unknowns is that they inevitably assert themselves, during development.  If the technical staff member has been too keen to nail his reputation to the mast by making unbreakable, non-negotiable promises to the other stakeholders, then as soon as one of those unknowns goes in an inconvenient direction, for him, there is no way to rescue the product launch, the project budget, the reputation of his development team or the business from the disappointments that will arise.  A bloody and brutal death march will result, with developers whipped and flogged, almost literally, to “make up for lost time”, when the thing they were attempting was always going to take longer and cost more than the initial guesstimate promises made.

A good and seasoned development manager exposes what isn’t known, by the team, at the start of the development project and brings any new unknowns to the stakeholders, as they proceed.  They explain to other stakeholders not only what isn’t known, but what cannot be known and how long it will take (and what it will cost) to do the learning and research required to eliminate the unknowns.  This extra time and money needs to be baked into the project schedule and budget at the beginning.  In order to identify what isn’t known, though, some confession will need to take place.

The team members and management will need to be open and up front about what they do not know, even if that exposes a gap in their expertise or experience.  As I said before, not everybody can know everything and nobody knows it all, so stakeholders need to be realistic in acknowledging the team they have, while talented, always have some learning and research to do.  That’s just in the nature of making something brand new, which didn’t exist before.  You literally cannot hire a team of people that know all they need to know to do the job without stopping to learn new things.  If you can, it’s a warning sign that the product you are about to create has no unique selling point.  It has been done before.

Some company cultures posture in a stupid, macho way, belittling anybody that confesses to a need to learn something or to a gap in their knowledge or experience, but that’s a very stupid posture to take, given that it applies to all developers and their managers.  The reality is that people always need to climb learning curves, dig deeper into what they’re being asked to produce and learn about this particular market and customer base.  There really is no such thing as pure development.  It’s a myth.  Every development exercise carries some burden of necessary research.

Agile, as a development method, does not make the research part explicit.  Perhaps that’s why stakeholders think that any team which cannot execute on a product backlog and task backlog, mechanically and interchangeably, is a sign that the team members are incompetents.   If we don’t call out the need for individuals to learn as they develop, then the expectation is set that the job market is full of perfectly trained, fully formed developers that intuitively know everything about your product, customers, competitive landscape and market.  How could that possibly be, unless every developer in the world developed exactly the same products, for the same people, using the same technologies and tools?

These same stakeholders, who will deny funds for developer training, have an expectation that all other firms, in the world, pay generously for people to be trained, or else that the individual developer has so much spare cash and time, that they spend it all on personal training courses.

Take away the shame of being exposed as being without some (considered to be) vital skill, experience, understanding, tool, or piece of information and you open up the possibility of having looser, yet more realistic project budgets and schedules.  While you might not like the added apparent cost, you will like the added certainty that you can plan around a product release date more reliably and may even have time in hand, if things go well.

Once the development team members lose the fear of being called inadequate imposters and of exposing their relative skills gaps, the team can work better together, as a team.  Time can be allocated to go find out what each needs to know.  In some cases, the false economy of hiring junior programmers is revealed, when this step happens.  You realise that some team members need to learn a lot more than others.

Most importantly, team members no longer try to conceal trouble, when they encounter something they don’t know how to solve, or have an incomplete understanding of what they are supposed to be building.  The phrase I have heard used is: “Don’t sit on anything smelly.”  The spirit of this motto is to ask team members to expose unknowns and issues early, when something can be done about them.  The corollary to sitting on something smelly is that it just gets smellier and smellier.

When you transparently and honestly expose to stakeholders what the development team needs to go and find out, before they can set more accurate expectations on budget, delivery time, feature set and quality, you either get the support and permission necessary (what other choice do the stakeholders have?) or else the project is shut down.  People fear unemployment as much as they fear being found wanting in skills and knowledge, so the temptation to lie, to keep a non-viable project going, is strong.  However, the truth always comes out.

A non-viable project reveals itself to be so, at some point, so better to have the stakeholders understand this and make an active management decision, before all the gnashing and wailing, rather than letting the train wreck happen and have to live with the downstream consequences.  If the project is viable and worth doing, then it’s going to be worth getting the development team up to speed with what they need to know to develop it well.  If it’s not, the project should never have been started in the first place.  Too many stakeholders start non-viable projects, on a wing and prayer, with insufficiently deep pockets, and then blame the technical staff for not being able to pull off the required miracle.

It is the responsibility of every development manager and software architect to explain to stakeholders that nobody knows everything and that the people in their team were hired on the basis of being agile-minded enough to go find out.  It is unrealistic and dishonest in the extreme to expect developers to know everything particular to the stakeholders’ business and software code, straight off the street.  It’s time to stop play acting and making promises that nobody can keep.