In an environment of rapidly-changing technology and approaches, an internal tech conference can be a powerful and effective way of spreading new ideas and practices and sharing learning & experience. Having organised and run several internal tech conferences (at different organisations), Victoria Morgan-Smith and I decided to write about our experiences in an article for InfoQ: Internal Tech Conferences – How and Why. We also interviewed several other people from various organisations who have also run internal tech conferences in order to give a broader perspective.
Our aim was to inspire and enable other people to develop and run internal tech conferences in their own organisations, building on the experiences of the teams and organisations in the article.
In this article we draw on our personal experience of running internal tech events at companies we’ve worked with, along with reflections and advice from people at Paddy Power Betfair, Callcredit Information Group, ING and others. You’ll find further reading & listening material at the end of the article – there is so much inspirational work happening in so many organisations.
Software engineering today is as much about people as the technology itself: an internal tech conference can give a huge boost to your organisation’s social capital – that currency by which relationships flourish.
The format you choose for your internal tech conference depends on what you want to achieve from it: it can be “by the people for the people”, or a showcase to celebrate achievement. You can keep the audience or speakers to just a single department, or invite other divisions, or even invite external speakers and/or audience.
Making the event a success takes effort: choose your speakers well, and mentor themas they prepare their talks. Work on the logistics – it’s the little things that count.
Remember to have fun: ‘death by PowerPoint’ will mean people remember the event for the wrong reasons!
Follow through: for a lasting impact, keep sight of the outcomes you seek and be ready to work with others to keep the momentum going.
We hope that the article is useful for people thinking of running or improving their own internal tech conferences!
Thanks to everyone involved: people we interviewed, the amazing InfoQ team, and to my co-author Victoria Morgan-Smith.
At the Unicom DevOps Summit event in London on February 28th 2014 we experimented with some extra audience/attendee participation by asking for questions on record cards and encouraged people to ‘dot-vote‘ on the questions most interesting to them. There were some good questions, but unfortunately we did not get chance to discuss many of them, so here are all the questions from the card board, along with some very brief attempts at answers.
Should security be a part of DevOps?
To what extent and how do you insist on standardisation for multiple Scrum + ‘DevOps’ teams with no separate Operations team?
What’s the likely process flow of / disruptions to / duration of DevOps adoption?
Where does ‘Operations’ sit in the ITIL model? All over the place? e.g. Service Transition?
How about some example scenarios? Tangible comparison points would be useful.
Where does DevOps start and finish (from a process perspective)?
Is DevOps just a job title?
Is co-location of resource necessary for successful DevOps?
How essential is cloud technology to DevOps?
How will the announcement that ThoughtWorks are ‘open sourcing’ their Go DevOps product affect other vendor products? Why pay for other products?
There are a lot of open source DevOps/release/orchestration tools – is anyone using (or know about) the Windows equivalent?
How do you overcome developer resistance to writing Run Book docs? Are the processes to drive adoption? Is it a sackable offence?
I recently presented a webinar on What Does DevOps Culture Feel Like? in which I attempted to characterise what it feels like to work within a DevOps culture (part of the Experience DevOps workshop series).
Here are some criteria which should be useful when trying to cut through the tangled mess of “DevOps” job titles in order to work out if a prospective role will actually lead to working within a DevOps culture, or whether you’ll be stuck in an old-school IT silo with a fancy “DevOps” name tag and the same crappy us-and-them mentality.
Over the past seven or eight years I have developed a list of five key interview questions for recruiting staff to software development teams. These five questions have come to stand out as being highly indicative of the candidate’s aptitude for approaching software in [what is now called] a “DevOps” manner, namely, seeing software as the running, evolving system in the Production environment.