How to build a Github in a university?

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.