From Silicon Alley Insider, on hiring decent engineers:
Unemployment in the United States is still at a brutal 9.6%, but for software engineers the job market couldn't look much better.
Everyone in tech knows that there is a serious engineering deficit, but apparently no one outside tech knows about it, so new talent isn't flooding in to fill the demand.
There's an interesting disconnect in the economy right now.? Employers think that with high unemployment, people should be desperate for work, including software engineers (and BPM experts, incidentally).? But software engineers have more leverage than they've ever had because:
- Young(ish) companies like Google, Facebook, Twitter, etc. have created thousands of new jobs.
- Old(er) companies like Oracle and Microsoft and IBM seem to keep growing their software staffs no matter how many hiring freezes and layoffs they might have.
- Seed capital is plentiful
- The cost of starting up has come down dramatically, at least for "web startups"
But the key issue, captured brilliantly by Evan Korth (my emphasis):
Evan Korth, a computer science professor at NYU and cofounder of HackNY, tells us that people outside of tech, and college students in particular, are largely ignorant of how lucrative the opportunities are for programmers. This partly the result of stale media narratives, he thinks. In 1999, everyone was told that becoming a computer geek was the path to riches. Then the dotcom bubble burst, and the media was writing about out-of-work coders with no options. Programming skills were in high demand again before long, but the media was more concerned with the largely make-believe narrative that programming jobs were all being outsourced to India. So opportunistic college students are still focused on Wall Street.
If you watch the news, they're still portraying software jobs as being under great pressure from outsourcing.? While that is true, supply and demand have found some equilibrium, and corporations and startups have realized that outsourcing isn't a panacea, though some companies have clearly made it work well for their businesses (and others have not).? The overall job opportunities and job security for software engineers is quite high, as is the earning opportunity.
In the BPM world, there's another dimension that makes things more difficult.? MWD Advisors' Neil Ward Dutton captures the issue perfectly here:
And that disparity was something I saw echoed around other sessions in the conference and in conversations with those attendees who were already succeeding with BPM. Right now, success quite often depends on driven individuals who feel compelled to transcend their technical backgrounds and learn unfamiliar skills and languages.
I concur - the efforts required - cultural as well as business and technical - are so great that these individual heroics are often necessary to get an organization started.? But yet, a few driven individuals aren't enough to sustain these efforts over time.? They have to transition to creating a culture of learning new skills and languages - and surmounting barriers.
Increasingly, though, as the pace of business change increases and technology platforms bundle more and more high-level capabilities, the most crucial practices for IT organisations to get right themselves [...] are probably better classed as ?art? or ?craft? than ?engineering? ? and please note that this doesn?t make them less important.
I couldn't agree more - I've long been arguing that Software is more of a craft than an engineering discipline - and the way that we approach BPM is as a craft - taught by experienced practitioners to people who are still learning the ropes.
John Reynolds takes it a step further:
It's time for a wakeup call in the world of programming... Our collective need for custom programs is growing at a much greater rate than our supply of master programmers.? We can either continue to focus on tools for these master programmers - to make them even more productive - or we can figure out how to empower those occasional programmers to do it for themselves.
If we don't build tools that are targeted at the "occasional" audience, then nothing will change.? Occasional programmers will continue to suck.
John's take is that we need to focus tooling for the "occasional" audience.? I agree.? And in particular, I think this is something that a tool like IBM's Lombardi Edition could live up to (IBM is John's employer) if the engineering team focuses on consistency (making sure that all similar functions are rationalized in a consistent fashion to the process author - inconsistencies make the experience more complicated), simplicity (make the easy cases easier, and boil away excess feature-itis ), and appealing (address the experience of both author and end-user). Interestingly, this could be done without giving up more advanced APIs and features.? (Not everyone believes this).
There's also an interesting opportunity to address the "not programmer".? If we divvy up the world into "master programmers", "occasional programmers" and "not programmers... The latter two are clearly under-served markets- particularly in BPM, despite claims to the contrary!
Update: Looks like this topic got good treatment at Forrester's Business Process Forum 2010, in a Connie Moore session (thanks to Sandy for blogging it!)