Category: Skills

Tech Skills: Business Needs to Give Back to Education?

Another day, another skills and tech education rant…

My thoughts here are partly triggered by this tweet about the HE system being effectively broken, from Martin Bryant of Tech North:

The overall takeaway is that the current HE models aren’t working for the tech sector on two counts: a) It moves too fast and b) There is too much to learn. Sounds like a perfect storm. The syllabuses and the people doing the teaching are continually at risk of being out of date.

I agree with the comments in the article that there is an expectation mismatch going on.

Companies can’t realistically expect graduates to just drop into a position and be as useful and productive as a person with several years’ experience, nor can they expect them to know the ins and outs of every protocol or language. As an employer, there needs to be some sort of development plan in place for every person you hire.

I’ve previously written about my own entry into the tech industry, somewhat by accident, in the 1990s: that I left University with a degree in nothing to do with tech, but with a solid understanding of the fundamentals, and basically ended up learning through apprenticeship-type techniques once on the job in an ISP.

Where I believe tech companies can help is by pouring their real-world knowledge and experience back into the teaching, and by this I mean moving beyond just the usual collaboration between industry and education and taking it a stage further: Encouraging their staff to go into Universities and teach, and the Universities to do more to guide and nurture this.

Yes, it takes effort. Yes, for the tech firms releasing staff members one or two days a week to teach, it’s going to be a longer term investment, the payback won’t immediately come for three to five years. But once it does arrive, it seems that the gift will keep giving.

For the Universities, they will need to support people who maybe aren’t experienced in teaching and find new ways of making their curriculum flexible enough to keep up.

I see this potentially having multiple positive paybacks:

  • For the University: they are getting some of the most up-to-date and practical real-world knowledge being taught to their students.
  • For the Students: increased employability as a result of relevant teaching.
  • For the Industry: a reducing skills gap and more inquisitive and employable individuals looking for careers.
  • For the tech employee doing the teaching: a massively rewarding experience that can help increase job satisfaction.

For this, I’d like to put my industry colleague Kevin Epperson on a bit of a pedestal. Kevin is an experienced Internet Engineering professional, and has worked at big industry names such as Microsoft, Level 3 and Netflix, in senior Network Engineering leadership roles. Kevin also teaches at University of Colorado, Boulder and is the instructor of their IP Routing Protocols course.

This is something Kevin has been doing for 15 years, during tenures at three different employers, and recently received an award for his contributions to their ITP courses.

The value of having a real-world industry expert involved in instructing students can’t be underestimated, yet I can think of very few people in my part of the tech industry – Internet Engineering – that actually teach in the formalised way Kevin does. All I can really think of is people doing more informal tutoring at conferences, and helping to organise hackathons and other events, which don’t necessarily reach the HE audience we’re discussing in this article.

The industry needs to be willing to move outside the rigid “full-time” staff model that I still find many companies wedded to, despite claims to the contrary, and be confident about releasing their staff to do these things, in order to give back. It may even improve staff retention and satisfaction for them, as well as produce more productive new hires! Be interested to see if people have real stats, or just good stories, on that.

Yet, at the same time, we’re talking about an industry that won’t give many members of staff a day out of the office to attend a free industry event which will benefit their skills and experience and improve their job satisfaction. Why? Who knows? I have hard data on this from running UKNOF that I’m willing to share if folks are interested.

The answer that I don’t have is how receptive the Universities would be to this? Or do they have their own journey of trust to go on?

Net Eng Skills Gap Redux: Entry Routes into Network Engineering

While I was recently at the LINX meeting in London, I ended up having a side-discussion about entry routes into the Internet Engineering industry, and the relatively small amount of new blood coming into the industry.

With my UKNOF Director’s hat on for a moment, we’re concerned about the lack of new faces showing up to our meetings too.

Let me say one thing here and now:

If you work in any sort of digital business, remember that you are nothing without the network, nothing without the infrastructure. This eventually affects you too.

Yes, I know you can just “shove it in the Cloud”, but this has to be built and operated. It has real costs associated with it, and needs real people to keep it healthily developing and running.

I’ve written about this before here, almost 3 years ago. But it seems we’re still not much better off. I think that’s because we’ve not done enough about it.

One twitter correspondent said, “I didn’t know the entry route, so ended up in sysadmin, then internet research, and not netops.”

This pretty much confirmed some of my previous post, that we’d basically destroyed the previous entry route through commoditisation of first-line support, and that was already happening some time around 1998/1999.

It’s too easy to sit here and bleat, blaming “sexy devops” for robbing Net Eng and Network Infrastructure of keen individuals.

But why are things such as devops and more digital and software oriented industries attracting the new entrants?

One comment is that because a large number of network infra companies are well established, there isn’t the same pioneering spirit, nor the same chance to experiment and build, with infrastructure compared to the environment I joined 20 years ago.

My colleague, Paul Thornton, characterised this pioneering spirit in a recent UKNOF presentation titled “None of us knew what we were doing, we made it up as we went along” – note that it is full of jargon and colloquialism, aimed at a specific techie audience, but if you can excuse that, it really captures in a nutshell the mid-90’s Internet engineering environment the likes of he and I grew up in.

Typing “debug all” on a core router can liven up your afternoon no end… But I didn’t really know what I wanted to do back then, I was green and wet behind the ears.

Many infrastructure providers are dominated by obsessions with high-availability, and as a result resistance to change, because they view a stable and available infrastructure as the utopia. An infrastructure which is being changed and experimented upon, by implication, is not as stable.

do-not-touch-any-of-these-wires
DO NOT TOUCH ANY OF THESE WIRES

Has a desire to learn (from mistakes if necessary!) become mutually exclusive from running infrastructure?

In many organisations, the “labs” – the development and staging environments – are pitiful. They often aren’t running the same equipment as that which exists in production, but are cobbled together from various hand-me-down pieces of gear. This means it’s not always possible to compare apples with
apples, or exactly mimic conditions which will exist in production.

Compare this to the software world, where everything is on fairly generic compute, and the software is largely portable from the development and staging environments, especially so in a world of virtualisation and containerisation. There’s more chances to experiment, test, fail, fix and learn in this environment, than there is in an environment where people are discouraged from touching anything for fear of causing an outage.

This means we Network Engineering types need to spend a lot of time on preparation and nerves of steel before making any changes.

Why are the lab environments often found wanting? Classically it’s because of the high capital cost of network gear, which doesn’t directly earn any revenue. It’s harder to get signoff, unless your company has a clear policy about lab infrastructure.

I’m not saying a blanket “change control is bad”, but a hostile “don’t touch anything” environment may certainly drive away some of the inquisitive folks who are keen to learn through experimentation.

Coupled with the desire of organisations to achieve high availability with the lowest realistically achievable capital spend, it means that when these organisations hire for Network Engineering posts, they often want seasoned and experienced individuals, sometimes with vendor specific certifications. You know how I hold those in high esteem, or not as the case may be, right?

So what do we need to do?

I can’t take all the credit for this, but it’s partly my own opinions, mixed in with what I’ve aggregated from various discussions.

We need to create clear Network and Infra Engineering apprenticeship and potential career paths.

The “Way In” needs to be clearly signposted, and “what’s in it for you” made obvious.

There needs to be an established and recognised industry standard for the teaching in solid basic network engineering principles, that is distinct from vendor-led accreditations.

In some areas of the sector, the “LAIT” (LINX Accredited Internet Technician) programme is recognised and respected for it’s thoroughness in teaching basic Internet engineering skill, but it’s quite a narrow niche. Is there room to expand the recognition this scheme, and possibly others have?

A learning environment needs to exist where we enable people to make mistakes and learn from them, where failure can be tolerated, and priority placed on teaching and information sharing.

This means changing how we approach running the network. Proper labs. Proper tooling. Proper redundant infrastructure. No hostile “change control” environment.

Possibly running more outreach events that are easier for the curious and inquisitive to get into? That’s a whole post in itself. Stay tuned.