The Freelancers are Already Marching

Following on from my piece The March of the Freelancers – the New York times has an article on the extent of freelancing focussing on the people who work online through online staffing agencies:

Recently two of the biggest online staffing companies, oDesk and Elance, have released surveys concerning the companies that hire workers over the Internet to do things like write software, and the mindset of online workers themselves.

Between them, oDesk and Elance claim to have more than four million coders, Web designers, marketing professionals and other workers. Some even spot porn on Facebook at a rate of four for a penny. In the second quarter of 2012, oDesk says, its contractors worked over 8.5 million hours, a 70 percent increase over a year earlier. The average freelancer at Elance, meantime, expects to make 43 percent more money in 2013, as more employers come online.

That’s lot of people working a lot of hours. Freelancing is already big business and getting bigger.

My changing workplace – part 8: 00′s on the road

Early into the 21st century it was time to leave the working location that I’d spent nearly all of working life in.

Lake Districts StreamsAlthough I’d moved from one company to another and worked in many different offices (5 at this point I think) I’d still been based on the same site. I’d worked with people from different sites for the same customer, but most of my focus had been on this one location. It was a large site and there was plenty of work to do but it was time to move on.

I’d been asked to lead a team of engineers working with the Microsoft technologies that were growing in popularity with our customers and the ones that we had successfully deployed already. This was a new team that didn’t yet exist and needed to be built.

There was a location where some engineers already existed, they were near to another customer who wanted to deploy the latest Windows 2000 technologies both client and server.

It was time for me to get on the road, partly to build the team, but also to help out with the Windows 2000 project. It was time to move from a desktop working life to a laptop working life. It was time to move from a desk-phone to a mobile-phone. My workplace was starting the steps away from being a location towards being an activity that took place wherever I was.

There was still a strong mind-set that was convinced that someone was only working on a project when they were there in person. This meant that I was on the road a lot travelling from project to project, customer to customer. Most of the time was spent on the A14 towards Cambridge because that was where the major project was and the only way to work on the project was to be there.

Windows 2000 included a number of new technologies but the one that would dominate most of our discussions was Active Directory. It’s hard to imagine now the extent of the change that the move from Windows NT 4.0 domains to Active Directory was. There were new skills to learn and new organisational interfaces to work through. Take DNS as an example; most organisations already had some form of DNS but it was run by the networks organisation to support a relatively small number of devices. Windows 2000 would increase the reliance upon DNS, the requirements for DNS and also, potentially the technology on which DNS was hosted. Like most Microsoft technologies the abilities of Windows 2000 as a DNS was viewed by the networks organisation with suspicion. They had existing, mission critical, requirements that they didn’t want to compromise with some ‘immature’ PC technology.

There was still a divide between so called enterprise-class technologies and the perception of the PC technologies as less mature and less stable. A maturity split also existed between the groups of people who looked after the technologies. A good example of this was the different approaches to change control. No mainframe systems programmer (where I started my technology journey) would dream of making a change without going through a management process which required them to think through the impact of the change and how to back-out of the change. PC people were used to working on individual machines without having to think too much about the impact of the change because there was only one person impacted. As the PC server technologies moved into the server room and eventually into the data centre we went through a period of time where there was to much of the PC approach and not enough of the mainframe approach. My background was on the sys-prog side of things and it fell to me to try and instil the correct disciplines. Not only did the technology have to mature our approach to that technology had to mature too.

This split made my job of recruiting interesting too. We saw many people who could build and rebuild a PC with there eyes closed but had no experience working in a managed environment like the ones we were wanting to build. We saw another set of people who’d worked in a smaller organisation and supported a small number of servers but still had a mind-set that if something needed changing they could change it there and then, and would.

The technology was maturing, the processes were maturing and perhaps I was maturing too.

As time progressed I spent more and more of my time travelling around building teams and managing people. This meant that I spent less of my time doing technical things. For some people this is a natural progression but it wasn’t the path for me. I came to the point where I realised that every time someone needed a technical authority I would launch in and get the problem resolved, I’d do this to the detriment of my management duties. Given the choice I would pick the technical challenge every time. While I was providing technical leadership I was happy and motivated, when it came time to do some administration for the team I would make it wait. In time a new role was being discussed, I’d always thought of myself as an engineer, but this new role had a different tile – architect.

There were other shifts that were reaching maturity too. UTP was the only way to wire a building. Ethernet was now the only transport. TCP/IP the only protocol. The Internet was becoming the way to connect things. AltaVista, MSN Search and Google were the options for search.

My changing workplace:

How to design a meeting

Daniel W. Rasmus has started an interesting series of blog posts on the design of meetings, or more specifically, the design of meetings that use collaborative software. He introduces his first post in a series with these words:

Welsh WatersHow to Design a Meeting: Lesson 1

We all run meetings like we know what we’re doing. We have been to so many meetings we just know how to run them. What we really know is how to model and perpetuate the poor habits and practices of our mentors and coaches, managers and colleagues.  In the era of collaboration software our meetings need to be redesigned so they are driven through the collaboration environment in real-time, as the meeting takes place. Stop all the e-mails and document duplications, or even worse, handouts and get people to engage in a collaborative way through a meeting environment that captures all of the content, the tasks and the decisions in one view (not necessarily, as you will read, in one place).

The other day I finished work exhausted. As I sat and considered what I had achieved that day I realised that I had spent most of it in meetings, but what had I achieved? Honestly, precious little. Why was that? Well, and this is where I might be getting a bit too personal for some, boredom tires me out, and I’d spent much of the day bored.

I’m not saying that meetings are boring, but I am suggesting that many of the meetings that I attend are boring. Sometimes meetings need to happen that are in their very make-up dull, the context and the subject makes it difficult to make them interesting. These are the minority of meetings though, many meetings with interesting content are made colourless by the way that we run them. We spend so much of our time in meetings we should care that they are effective. If a meeting is effective it, at least, has a chance of not being boring.

I need to hold my hands up here and apologise for the drab meetings that I’ve run too, there’s a lot I need to learn, relearn and unlearn. Daniel has provided an infographic of where he is going with the series, I’ll read with interest: