Earlier this year I was promoted to Senior Development Operations Engineer and I thought I must really know what I’m doing. But then something comes along, like this amazing slidedeck from Tanya Reilly and I realise… crap I know nothing.
Glue Work
Upon reading this I realised I had an understanding of glue work already, I’d managed project rollouts while being the lead engineer, I’d been a Delivery Lead and I’d filled in when my manager left and we hadn’t been able to hire a replacement. Glue work is anything that helps enable your team to deliver business value. You are an enabler and it’s a core part of a Senior’s job to enable the team to be more effective and grow.
Rightly or wrongly though you often need to prove yourself technically before you can be premoted to a senior role that involves more glue work (post-technical we call it). This is the topic explored more deeply in Tanya’s talk so I won’t go into more detail (you should read it!). But in short I totally think her hypothetical situation was unfair because her manager utterly failed to tell her what they expected.
But Glue Work is still immensely important and something all engineers should get exposure and guidance on. Too many managers focus on staying technical and don’t appreciate it, this makes them unable to properly mentor engineers into good senior engineers. They chasticise glue work in front of their staff “I didn’t get any real work done yesterday”, “I have meetings all day so I’ll get nothing done”.
It’s ok for managers to vent, but they need to balance it with good apprasals of the work that enables the team.
When we are unable to effectively prioritise it and instead focus too much on “busy” work, we end up like Brent. Don’t Be Like Brent.
A Healthy Team Dynamic
A manager is as responsible for a team’s dynamic and culture as a senior engineer is responsible for a code base. Place too much emphasis on one person and everybody else shirks that responsibility. Don’t get me wrong, managers and seniors must lead from the front, but they are truly successful when the team can lead itself. We talk about resiliency a lot in the technical world, but somebody pointed out to me recently that it’s the wrong word, what we mean is “robustness”. Resiliency is the ability to deal with “unforseen scenarios”
Answers don't neatly fit into 280 characters, but in a nutshell: resilience is the sustained adaptive capacity for handling unforeseen/unanticipated scenarios at a systemic level. Robustness is component/process handling at a mechanistic level for scenarios that are anticipated.
— John Allspaw (@allspaw) October 10, 2018
In order to build “resilient” teams we need them to be able to deal with numerous curve balls that may come their way, including lack of leadership for periods of time and external pressures.
When we appreciate the importance of Glue Work, mentoring people, dealing with stakeholders and vendors and identifying and containing risks to our team and projects, we create resiliency. Because the other engineers know the importance of the work and understand it’s part of their job. That without people to fulfil those roles they would not be as effective or worst could be out of a job.
The Role of Seniors
Charity Majors, who first pointed out the slide deck I mentioned, has had many threads lately discussing the role of Seniors. She’s nailing it as she always is, that Seniors need to have a good breadth of knowledge.
there are many different archetypes for senior software engineers.
— Charity Majors (@mipsytipsy) October 30, 2018
* some are deep subject matter experts
* some are more project manager than SWE
* some are good at bootstrapping new projects
* some are super coders who churn out 10x the code and let you iterate rapidly
Seniors don’t have to be great at Glue Work, but there has to be a balance in the team. Someone has to fill the role of mentoring, otherwise people get bored and move on, or the senior leaves and nobody has any idea how it all hangs together. Someone has to be able to identify and contain project risks early, before they derail you.
The blog post I linked earlier about Being a Delivery Lead seemed to over-emphasis their role in doing this work, but I disagree with that notion. It’s everyone’s responsibility but who does what is ultimately up to the team to decide and great teams have a variety of personalities that are well suited to specific tasks.
Most importantly though, they each recognise the value of the work. Without that we’re doomed to be like Brent.