Recognising the importance of glue work

It has become a cliche of our technical culture that developers are lone wolves in hoodies, coding late into the night as they push themselves to build the perfect solution to every problem. Apart from the hoodie-wearing, this is not a sustainable way to work in the long term. Trying to do everything alone explains why many developers feel burned out.

Software today is just too complex to be built by one person. Consider a new software as a service (SaaS) product , for example: You need to understand design, frontend development , mobile development, APIs and backend development , and you probably need a good grasp of the cloud too. And that’s just the technical aspects of the build. You cannot do it all on your own.

Despite common perceptions, many software engineers today spend less time coding than they would like. Apart from coding, they could be attending multiple meetings, onboarding new developers, reviewing design documents, updating roadmaps and trying to keep everyone going in the same direction. On top of those tasks, they may be performing QA, cutting releases, shaping stories, running the agile choreography and advocating for other developers.

They do all this non-development work because it is the glue that keeps the team together. Eventually, however, somebody may notice just how well they do this work and suggest a move to an apparently less technical role. This is the dilemma for developers: Ensuring the solutions they create are as good as they can be involves a lot of non-coding work, but doing that work could put them out of a job — as a developer, at least.

When it is recognised as being a pivotal part of the work the organisation does, glue work helps to develop strong technical leadership skills. But if it is simply assumed that developers will do this work while also trying to meet their development obligations, it leads to burnout and can even drive talented people out of the industry.

[caption id="attachment_300015259" align="alignnone" width="600"]

Matteo Collina’s CodeMotion talk “Be the glue”.[/caption]

If you are a developer who does glue work, you know how important it is. You know that if the colleague who needs help is neglected or the flaw in the design document is overlooked or the gaps in documentation are not filled, projects fail, tasks are overlooked, teams are not aligned and nothing is completed satisfactorily.

However, if your job description doesn’t cover this kind of work, you may be passed over for promotion and find it difficult to get any kind of credit for all the time you devote to it. Ultimately, if your team management is not recognising the value of all the work you do, you may decide to focus only on the work that is valued.

And this is an option for developers who really want to continue coding and don’t want to burn out. All of those non-coding tasks you are completing may be necessary, but they should be distributed fairly, and you should be recognised for doing extra work.

It comes down to what you want to do with your career. You need to be proactive about what you hope to achieve to avoid becoming overwhelmed by work you don’t want to do and are not being rewarded for. Otherwise, you will end up in a role you don’t want because somebody tells you that you would be good at it.

Be deliberate about choosing a role that you are happy with and that will progress your career in the way you want. And when you reach a decision about where you want to go, consider whether the organisation you are with now will help you get there.

Organisations that want to retain and progress their developers need to recognise that glue work keeps teams together and projects on track. In fact, glue work is among the key responsibilities of a developer — and they should be rewarded for it. Accordingly, team members should be promoted based on their proficiency at the kind of tasks that ensure the team delivers on its targets.

This means building a culture where taking on so-called boring tasks is considered as important as developing a really challenging feature. These tasks can determine the difference between a success and a failure because they fill the gaps that can doom projects.

However, organisations typically promote developers based on their coding work, even though there is a lot more to technical work than writing software — and the leadership qualities demonstrated by those who excel at glue work are either overlooked or seen as a reason to direct a developer into a non-technical role. There are no metrics in place to measure non-functional requirements such as quality, security and scalability, and, even though developers may have specialist skills in these areas, they are not always recognised.

Of course, not all of the work you do should make you eligible for promotion; some of the routine tasks you complete are just part of the job and should be shared fairly among the team. However, if you are spending a substantial proportion of your time on non-core work, you are damaging your career prospects.

Work that doesn’t fit naturally into anybody’s job description should be shared equally and tracked the way other work is tracked. If it is not distributed in a planned manner, the same people will end up volunteering to do it, and that leads to resentment and burnout.

At NearForm, we have created a delivery architect role, which is based entirely on glue work. Many of the delivery architect’s key responsibilities revolve around managing the team — because the ultimate form of software engineering is team architecture. Successful software engineering requires effective team practices.

This means that the delivery architect is expected to provide technical and line-management direction for their development team, assume responsibility for the successful delivery of projects and shape and define architectural decisions. They should also have the foresight and analytical skills to identify and resolve blockers before they become issues.

They work directly with clients, translating requirements into technical briefs, and they also deliver reports to clients and their managers at NearForm to ensure clear understanding of project status and drive good decision-making. However, despite the emphasis on leadership, they are also expected to maintain their technical proficiency and stay up-to-date in their field of expertise. This twin focus on leadership and technical proficiency means that a delivery architect never needs to fear that their development skills will become obsolete.

As long as developers are not being rewarded for doing necessary but non-technical work, and their managers are failing to ensure that the glue work gets distributed fairly, developers will continue to burn out and organisations will continue to lose good people. However, if people can focus on the career paths they want to follow, and glue work is recognised for the vital role it plays, organisations are more likely to retain top talent and deliver better solutions faster.