Tag: technology

Remote Workers: Why I think WeWork are missing a trick

Some of you will be aware I’m a remote worker. My employer’s corporate HQ is in the US, our EMEA HQ is in London, while I’m nominally on a “work from home” contract, where home is in Manchester. I work with an International team, based all over the world.

The lease on our London office expired recently, and the company took the decision to move our EMEA HQ into a dedicated private office space in a WeWork building – I’m assuming folk reading this know what a WeWork is, if you don’t, it’s a serviced office, but just not beige throughout.

The upsides to being located in a WeWork are pretty good.

Modern offices with up-to-date decor, meeting rooms of various sizes, on-site WeWork staff to handle all the faff such as maintenance, cleaning, etc., for you, including a mail-room function so you never have to wait in for a parcel again, and all the fun things more usually associated with massive tech companies and start-ups, such as espresso machines, table football, free beer in the afternoons, etc.

The things you might expect at a Corporate HQ location, but now available to people working in the smaller satellite offices too.

So much so that we’ve done that with a number of our smaller regional offices of late. So we do put significant business (for us at least) in WeWork’s direction.

Because I had access to our old London office, that meant I became a member of the WeWork building we moved into in London. This means in WeWork’s eyes, our London EMEA HQ office is my “home” location. I have 24×7 access there. I need to come and go from there for face-to-face meetings and the like, so that makes sense. All well and good.

But you’ll remember, I live in Manchester.

As it happens, there are two (soon to be three) WeWork locations in Manchester.

I can spend 1 credit (a credit is how WeWork account for additional services, such as booking meeting rooms, and use of non-“home” workspaces) from the company WeWork account to book a “workspace” in one of the Manchester locations for the day, and sometimes I’ll do that, so I don’t go berserk working from home and staring at the same four walls all the time.

Yes, outside! People! Conversation! Change of scenery! Free coffee! Free beer! Air-conditioning on sweltering days!

Sounds great that I can use my company WeWork membership to get access to the more local facility and get out of the house, doesn’t it?

I’ve been trying this for a couple of months, I’ve found there are some downsides:

  • The “workspace” you get for your WeWork credit is basically a form of guest access to that building’s communal areas. These are areas with the kitchen, barista, coffee machines, foosball tables, ping-pong, background music, and beer.
  • So, unlike the amenity of your home location – proper desk, proper work chair – for your credit you get access to some sofas, high tops, and if you’re lucky (because it’s location dependent) some desks intended for short term use (i.e. tables and non-adjustable hard chairs). The good spots – with the more comfortable chairs and power outlets – are a) often more “cafe style” and b) coveted, tending to go really quickly.
  • Also, because you’re in the communal area, you’re basically using the same space that the building’s resident members use for coffee breaks, to eat their lunch, chat, and have informal meetings which means it can get loud.
  • Finally, because you’re not a regular user, you’re basically left feeling a bit like this rando that’s invading the other peoples’ space. You don’t really feel like you belong.

Bluntly, working as a visitor in a WeWork other than your company’s own location is actually not a great work environment if you need to concentrate, or intend on spending any length of time there.

It’s fine for short-term getting online, grabbing a coffee, checking emails, and maybe the odd informal meeting or chit-chat, or just a change of scenery – basically the things you might otherwise do in a coffee shop.

The other problem is that unlike one’s “home” location, your credit only buys you access while the WeWork location is staffed – 9-6pm. It’s also an “automatic lock-in” – very much like the cult Channel 4 gameshow The Crystal Maze, but far less entertaining when you nip out to the loo and your keycard is automatically deactivated. You’re on one side of the door, while all your stuff is on the other, and now you’re looking for someone to let you back in.

This becomes a challenge when you’re working across multiple timezones where conference calls running into the evening – especially in that 4-7pm sweet-spot where the time isn’t hugely anti-social in California, Boston, and the UK – aren’t unusual. Work days just don’t routinely finish at 5.30pm anymore!

Now this is where I believe WeWork – as a huge global co-working organisation, with offices all over the place – ought to understand this better, and are missing a trick with remote workers such as myself: people who do need access to their organisation’s corporate office, but at the same time may have a WeWork closer to their home location that they might like to use once or twice a week, and somewhere they feel they have a connection with.

Indeed, WeWork consider their “Global Network” as one of their upselling points, but the way it’s organised at the moment, each individual location feels like a separate “franchise” of WeWork. My opinion is this is where the Global Network falls down.

What would I propose they offer people such as myself?

  • The ability to nominate a “secondary location” – this would be your choice of  WeWork closest to your home, space permitting – at which you have 24×7 walk-in privileges, other benefits as though it’s your home location, and access to the communal areas (effectively this is an “add-on” Hot Desk membership at the chosen secondary location).
  • The ability to book a “proper” desk in an open plan area or small (1/2 person) office at your nominated secondary location on a day-to-day basis using credits – effectively the same as you can book workspaces or meeting rooms now, except it’s at an actual desk, with an actual work chair.

Yes, I propose that WeWork deliberately hold back a handful of small offices and open plan desks in each location, and set them aside for upgraded hot-desking.

How many credits would a desk cost? The cost of a UK WeWork credit is £20 (I know it’s $25 in the US).

Most co-working spots I know of that offer an “occasional user” membership (i.e. aimed at 5 days a month, but not religiously policed, could be 8-10 half-days) will charge around £100-120+vat a month, but for that you do get a proper desk with a proper chair, and you’re not working out of a sofa or from a high-top in a corridor all day.

At WeWork, the closest thing that gets you a proper desk is a Dedicated Desk plan, and those currently run to £330/month in Manchester, they are more expensive in other locations. If you assume 22 days per average work month, it’s £15/day. (Or 261 work days in 2019, so 330×12/261 = 15.17)

So let’s say that 0.5 credit will get a “secondary member” a proper desk in the open plan office area for the day. Remember, your organisation is already paying WeWork a small fortune back at “home base”, so why shouldn’t they get a good deal in the other branches?

What about a private office? In Manchester these start from £460/month, depending on which building.

I’d suggest private offices are offered from 1 credit per seat for the day in cheaper buildings and maybe 2 credits for the busier and more expensive cities and buildings with higher demand.

I know I could technically book a small meeting room, but again these aren’t intended for you to get dug-in for a full day’s work. They are designed around being comfortable for relatively short periods of time, and encourage turnover so other WeWork members can use them. Plus, using them during peak hours chews through credits.

So that’s where I think WeWork are dropping the ball the most, at least for annoying people like me with non-conventional work locations and patterns.

I’ve not even gone into detail here about their online systems and app, through which you do have access to their “Global Network”. Despite the growth of WeWork, it’s still centred around the assumption that you’re really only interested in and attached to one building (and therefore one WeWork “community”) at a time – which enhances the feeling of being a bit of a rando if you’re in a WeWork other than your “home”, or if you change to follow your “secondary” location means you become disconnected from your Company’s main base.

As ever, please leave a comment, or tweet me with your thoughts: Are you a remote or nomadic worker that occasionally needs a good bolt-hole? Are you disappointed by the WeWork “global” offering? Are you aware of some “secret menu” of WeWork membership that does exist and will actually do what I’m looking for?

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.

The Network Engineering “Skills Gap”

Talking to colleagues in the industry, there’s anecdotal evidence that they are having trouble finding suitable candidates for mid-level Network Engineering roles. They have vacancies which have gone unfilled for some time for want of the right people, or ask where they can go to find good generalists that have a grasp of the whole ecosystem rather than some small corner of it.

Basically, a “skills gap” seems to have opened up in the industry, whereby there are some good all-rounders at a fairly senior level, but trying to find an individual with a few years experience, and a good grounding in IP Networking, system administration (and maybe a bit of coding/scripting), network services (such as DNS) and basic security is very difficult.

Instead, candidates have become siloed, from the basic “network guy/systems guy” split to vendor, technology and service specific skills.

This is even more concerning given the overall trend in the industry toward increasing automation of networking infrastructure deployment and management and a tendency to integrate and coalesce with the service infrastructure such as the data centre and the things in it (such as servers, storage, etc.) – “the data centre as the computer”.

This doesn’t work when there are black and white divisions between the “network guy” and the “server guy” and their specific knowledge.

So, how did we get where we are? Firstly, off down a side-track into some self-indulgence…

I consider myself to be one of the more “all round” guys, although I’ve definitely got more of a lean toward physical networking infrastructure as a result of the roles I’ve had and the direction these took me in.

I come from a generation of engineers who joined the industry during the mid-90’s, when the Internet started to move from the preserve of researchers, academics, and the hardcore geeks, to becoming a more frequently used tool of communication.

Starting out as an Internet user at University (remember NCSA Mosaic and Netscape 0.9?) I got myself a modem and a dialup connection, initially for use when I was back home during the holidays and away from the University’s computing facilities, all thanks to Demon Internet and their “tenner a month” philosophy that meant even poor students like me could afford it. Back then, to get online via dialup, you had to have some grasp of what was going on under the skin when you went online, so you could work out what had gone wrong when things didn’t work. Demonites will have “fond” memories of KA9Q, or the motley collection of things which allowed you to connect using Windows. Back then, TCP/IP stacks were not standard!

So, out I came from University, and fell into a job in the ISP industry.

Back then, you tended to start at the bottom, working in “support”, which in some respects was your apprenticeship in “the Internet’, learning along the way, and touching almost all areas – dialup, hosting, leased lines, ISDN, mail, nntp, Unix sysadmin, etc.

Also, the customers you were talking to were either fellow techies running the IT infrastructure in a business customer, or fellow geeks that were home users. They tended to have the same inquisitiveness that attracted you to the industry, and were on some level a peer.

Those with ambition, skill or natural flair soon found themselves climbing the greasy pole, moving up into more senior roles, handling escalations, or transferring into the systems team that maintained the network and servers. My own natural skill was in networking, and that’s where I ended up. But that didn’t mean I forgot how to work on a Unix command line. Those skills came in useful when building the instrumentation which helped me run the network. I could set up stats collection and monitoring without having to ask someone else to do it for me, which meant I wasn’t beholden to their priorities.

Many of my industry peers date from this period of rapid growth of the Internet.

Where did it start going wrong?

There’s a few sources, like a fire which needs a number of conditions to exist before it will burn, I think a number of things have come together to create the situation that exists today.

My first theory is the growth in outsourcing and offshoring of entry-level roles during the boom years largely cut off this “apprenticeship” route into the industry. There just wasn’t sufficient numbers of jobs for support techs in the countries which now have the demand for the people that most of these support techs might have become.

Coupled with that is the transition of the support level jobs from inquisitive fault-finding and diagnosis to a flowchart-led “reboot/reinstall”, “is it plugged in?” de-skilled operation that seemed to primarily exist for the frustrated to yell at when things didn’t work.

People with half a clue, that had the ability to grow into a good all-round engineer, might not have wanted these jobs, even if they still existed locally and were interested in joining the industry, because they had turned into being verbal punchbags for the rude and technically challenged. (This had already started to some extent in the mid-90s.)

Obviously, the people in these roles by the 2000s weren’t on a fast track to network engineering careers, they were call-centre staff.

My second theory is that vendor specific certification caused a silo mentality to develop. As the all-round apprenticeship of helpdesk work evaporated, did people look to certification to help them get jobs and progress their careers? I suspect this is the case, as there was a growth in the number of various certifications being offered by networking equipment vendors.

This isn’t a criticism of vendor certification per se, it has it’s place when it’s put in the context of a network engineer’s general knowledge. But, when the vendor certification is the majority of that engineer’s knowledge, what this leaves is a person who is good on paper, but can’t cope with being taken off the map, and tends to have difficulty with heterogeneous networking environments.

The other problem sometimes encountered is that people have done enough training to understand the theory, but they haven’t been exposed to enough real-world examples to get their head around the practice. Some have been taught the network equivalent how to fly the equivalent of a Boeing 747 or Airbus A380 on it’s extensive automation without understanding the basics (and fun) of flying stick-and-rudder in a little Cessna.

They haven’t got the experience that being in a “learning on the job” environment brings, and can’t always rationalise why things didn’t work out the way they expected.

The third theory is that there was a divergence of the network from the systems attached to it. During the 2000s, it started to become too much work for the same guys to know everything, and so where there used to be a group of all-rounders, there ended up being “server guys” and “network guys”. The network guys often didn’t know how to write scripts or understand basic system administration.

Finally, it seems we made networking about as glamorous as plumbing. Young folk wanted to go where the cool stuff is, and so fell into Web 2.0 companies and app development, rather than following a career in unblocking virtual drainpipes.

How do we fix it?

There’s no mistaking that this needs to be fixed. The network needs good all-round engineers to be able to deliver what’s going to be asked of it in the coming years.

People wonder why technologies such as IPv6, RPKI and DNSSEC are slow to deploy. I strongly believe that this skills gap is just one reason.

We’ve all heard the term “DevOps”, and whether or not we like it – it can provoke holy-wars, this is an embodiment of the well-rounded skill set that a lot of network operators are now looking for.

Convergence of the network and server environment is growing too. I know Software Defined Networking is often used as a buzzword, but there’s a growing need for people that can understand the interactions, and be able to apply their knowledge to the software-based tools which will be at the heart of such network deployments.

There’s no silver bullet though.

Back in the 2000s, my former employer, LINX, became so concerned about the lack of good network engineering talent, and woeful vendor specific training, that it launched the LINX Accredited Internet Technician programme, working with a training partner to build and deliver a series of platform-agnostic courses which built good all-round Network Engineering skills and how to apply these in the field. These courses are still delivered today through the training partner (SNT), while the syllabus is reviewed and updated to ensure it’s continuing relevance.

IPv6 pioneers HE.net offer a number of online courses in programming languages which are useful to the Network Engineer, in addition to their IPv6 certification programme.

There is also an effort called OpsSchool, which is building a comprehensive syllabus of things Operations Engineers need to know – trying to replicated the solid grounding in technology and techniques that would previously be picked up on the job while working in a helpdesk role, but for the current environment.

We’ve also got attempts to build the inquisitiveness in younger people with projects such as the Raspberry Pi, while venues such as hackspaces and “hacker camps” such as OHM, CCC and EMF exist as venues to exchange knowledge with like-minded folk and maybe learn something new.

We will need to cut our existing network and systems people a bit of slack, and let them embark on their own learning curves to fill the gaps in their knowledge, recognise that their job has changed around them, and make sure they are properly supported.

The fact is that we’re likely to be in this position for a few years yet…