One of the sources I have drawn from in my research on the pre-history of hacking in the university is Henry Etzkowitz. His research into the history of MIT and ‘entrepreneurial science’ was especially useful and interesting. As something I want to come back to at a later date, I’ll leave you with this quote from his paper, Research groups as ‘quasi-firms’: the invention of the entrepreneurial university, Research Policy 32 (2003) 109–121 (PDF). I was reminded of this by an article in Tuesday’s Guardian newspaper.
Research groups operate as firm-like entities, lacking only a direct profit motive to make them a company. In the sciences, especially, professors are expected to be team leaders and team members, with the exception of technicians, are scientists in training. As group size increases to about seven or eight members, professors who formerly were doing research are typically compelled to remove themselves from the bench to devote virtually full time to organizational tasks. Often persons in this situation describe themselves as “running a small business”. To continue at a competitive level with their peers, they must maintain an organizational momentum. Once having attained this goal, it is extremely difficult to function again as an individual researcher, so every effort is made to sustain leadership of a group.
Research groups within universities operate as small businesses lacking only a direct profit motive. Discuss!
This post is not about building a source code repository in a university.
Alex posted this presentation to our group’s mailing list a while back. If you are a developer or work with developers, it will mean something to you. Take a look and then read on.
Github are one of a few companies that talk openly about how they organise themselves and their work. Valve (cf. their Handbook – PDF), Automattic and 37signals are similar examples of how technology companies are both using and building technologies to change the way they work and the way they understand the role of work in our lives. When I watch presentations of enviable working environments like Github, I try to think of how it translates to working in a university, which in many respects also offers an enviable working environment in that academics at least, manage our own time, pursue our own interests, receive decent paid holidays, a pension, full pay while sick, etc. etc. There might be aspects of university life which we complain about, but relative to most other work, it is good work. I enjoy it and on the whole find it very satisfying.
In LNCD, we’ve been watching companies like Github for a while now and have been trying to learn from them and put their approach to work into practice. It is not easy and, off the top of my head, here are a few reasons why:
It is not a case of companies like Github employing an ‘agile methodology’, there are significant structural differences between technology startups and large institutions, too.
Github is a relatively small (108 employees) company compared to a university, which in our case has over 1300 staff and 12,000 students.
Github offers a single service (github.com), which although comprises a large number of underlying technologies, provides focus and direction for employees. Such narrow focus could grow dull over time, but I’m sure that the scale of growth (1.9m users over 4 years) keeps things interesting and challenging and during that time new complimentary technologies have been introduced which they have leveraged (e.g. configuration management software like Puppet).
Github appears to be a rapidly growing, dynamic company that currently works on a 1:17500 staff:customer ratio. Their customer-base is technologically savy and so they no doubt benefit from fast and valuable feedback, which drives the product forward. They release a new version of their product/service between 20-40 times each day.
A university’s focus is broad, loosely arranged around the themes of research, teaching, learning and enterprise. ‘Education’ doesn’t sum it up. I can’t think of a word that does. Sometimes universities focus on ‘the student experience’ or ‘research excellence’. Within these themes there are then multiple disciplines (e.g. Engineering, Arts, Humanities, Social Science), which have their own needs and expectations of the institution that supports them. Traditionally, they have operated quite autonomously and still do at some institutions. Organisationally, they are brought together as Colleges, Faculties, Schools, Departments, Teams and Committees. Perhaps it helps if we think of universities as a federation of multiple organisations. In some ways, research groups are similar to firms.
Universities grow quite slowly. They typically require large amounts of land, building work and the staff:student ratio at Lincoln is 1:9, which includes non-academic staff. Communication and ‘feedback’ within a university tends to happen quite slowly, too. We have annual surveys of both staff and students, course evaluations, committees and ways of providing adhoc feedback, but compared to Github, a university is a relative stable organisation and they tend to have a great deal of longevity.
Github’s message to other companies who wish to emulate them is ‘automate everything’; that is, where a machine can do the work better than a human, the machine should do the work and that the short-term effort put in to taking this approach will reap rewards in the long-term. This approach frees up the relatively few staff they have to be productive and creative. So far, no-one has left Github to work elsewhere. Employees are not being made redundant because their work has been automated.
Github builds the tools it needs to develop as a company. There are a number of examples in the slides above. We use one of their tools here at Lincoln, called Hubot. Github (the product) might appear to be a single, coherent service, but it is built on a great many underlying services which are coupled together. Github (the company) have built the service from the ground up using largely open source technologies and, where necessary, developing their own glue and renting complimentary services such as Rackspace, Campfire and Heroku.
Github claims that is has no managers. I am a manger and I can tell you that as far as I’m concerned, the holy grail of management is to be able to do away with it. The problem is creating the conditions that allows this to happen. What might they be?
Here are a few ideas off the top of my head: A relatively small company, working on a prestige product, where employees feel fortunate to work and can quickly see the benefits of their work; they are aware that their work matters and that people rely on them; there is a great deal of focus on improving internal communication and automating processes wherever possible; they do not require face-to-face contact to be able to contribute, so they can recruit nationally and internationally without employees having to relocate; despite this freedom, all productivity is logged through version control software, campfire chatrooms, issue trackers, etc. which discourages freeloaders; and employees are encouraged to work on tasks/projects that interest them and might at some point bring benefits to other employees. Interestingly, Github employees regularly open source their project code, which suggests that even with the freedom to hack on stuff of interest, employees are not always required to turn over their IP to the company.
There is a culture of innovation in a university – it’s called ‘research’ – but that does not necessarily mean that the university itself as an institution is innovative. At Lincoln, I think that we have been innovative in our teaching and learning strategy and curriculum design, Student as Producer, but this has not yet translated to equivalent technological innovations. Much of the time, I feel like we try to keep up with technological innovations led from elsewhere.
Specific institutional innovation groups (e.g. ‘Skunkworks’ teams) seem very rare in higher education. There are Educational Technologists or similar in most universities but their remit is rarely research and development. Most Educational Technologists are regarded as support staff. I find it perplexing that institutions comprising of thousands of people do not typically have a small, dedicated R&D team that are core funded. Over time, the value that such a team could generate for the institution should be far greater than the relatively small cost of running it but it is an investment that may take years to recoup and some of its value will be hard to evidence as it may not result directly in income generation (i.e. patents, grants, commercial services, etc.) Through innovation, such a group could contribute to the reputation of the university as well as overall efficiencies, which are harder to place a value on.
Finally, on a more positive note, I think universities could be ideal places to grow future companies like Github. Y Combinator recognised this in its early days, and universities have played an important role in the history of hacker culture and venture capital. It seems quite feasible that universities could become hackerspaces whose work fed back into the transformation of research, teaching, learning and enterprise across the institution.
In my previous post, I mentioned a small on-going project I have started to collect short interviews with developers working in universities. It is inspired by The Setup and relates to my interest in hacking in the academy. I hope that over time, it will provide a record of the people working in the developer community and add to the recognition of the work we do, how developers learn and how their working environment impacts upon their work and learning. Here’s the initial announcement I made at Dev8D. Please spread the word.
Calling all Developers working in Higher Education!
I’m setting up a site based on http://usesthis.com but focusing on Developers working in HE. It’s part of a research project I’m embarking on to understand how software developers (in universities) learn their craft.
It would be great if you could send me something. It will be published here http://hackingtheuniversity.net/ It shouldn’t take more than about 15 mins to write and about 5 mins to read (although longer is OK). Over time, I hope to compile a rich profile of developers who happen to work in universities.
How you answer is up to you; browse the site and read other people’s contributions. Alternatively, I’d be happy to accept something different, like this: http://why.usesthis.com/ You don’t need to hyperlink to your software and hardware. I will do that, in many cases automagically!
Here are my interview questions. If you don’t feel like writing, I’d happily accept an audio file to transcribe.
Who are you, and what do you do?
Who taught you how to do what you do?
What tools do you use?
Describe your dream working environment.
I need a nice image of you, too, at least 500×335 pixels.