My first late week-notes, shame on me.
Five dysfunctions of a team
On Friday, our Tech Leads group (consisting of the development team leads and others) went across to the News UK building to take part in a day-long team-building workshop: we reflected on ourselves through the lense of Patrick Lencioni’s Five Dysfunctions of a Team.
In brief, a successful team (in reverse order):
- Trusts each-other
- Does not shy away from productive conflict
- Commits to decisions made by the team (even if there is disagreement)
- Takes accountability for their actions
- Focuses on the results driven by success of the team, not individuals
Crucially, each stage is made much more difficult without the previous stages - Lencioni actually models it as a pyramid with trust as the foundation.
It was intense but worthwhile - I learned a lot about my fellow tech leads and the different ways we handle conflict, for example. There was a lot I took away with me that I can use to both reflect on my own mores and the way my team is perceived by the rest of the group.
(Author’s Note - I realised on reflection that I’d had 5 coffees that day, which may have been a contributor to my perception of how intense it was!)
Sell, sell, sell
One of the biggest take-aways from the session was a discovery on the way that my team interacts with the rest of Unruly’s product development team.
While almost every other team has demands foisted on them by the wider business in the form of broader feature-set or support, Shift is in a position of trying to ‘sell’ what we’re proposing to the other development teams.
This was a bit of a penny-drop moment for me, and I’ll be mulling over the implications of this relationship over the next week.
Will we need to change the way we work with other teams? What does a successful team if we use ‘sales’ as a metric rather than technical measures?
PDFs are rubbish
Before an election, government bodies like councils publish a Statement of Persons Nominated (or SoPN) with a listing of the candidates for the role - however, there is no standard format for these documents, and a lot are generated as PDFs. Extracting that data to use in platforms like WhoCanIVoteFor is a very manual task.
I had a punt at running the library over some sample SoPNs and it’s not perfect but certainly better than other libraries I’ve looked at in the past. Camelot’s unique selling point seems to be that it incorporates a degree of ‘fuzziness’ and configurability into its parsing.
I’m excited by the possibilities that this library might expose - anyone else interested in this area should take a look at Sym Roe’s excellent blog-post about using Machine learning to help elections