A reflection on changing workplace practices

I initially wrote this as part of my pair programming article but split it into a second post since I realised this is applicable for any workplace change. Some people thrive in a changing environment, others don’t, and a further group have more important things going on in their lives to spend energy on than your companies “Agile Transformation”.

I have worked at three businesses during my career where pairing was the default practice. When I compare these jobs with roles where I did not pair, it is obvious to me that the quality of the software produced while pairing has been significantly better. The mix of knowledge sharing, mentoring and collaboration on requirements during implementation has meant that I have on-boarded and learnt new technology faster in these organisations. The real time discussion of design and non-functional requirements has led me to write more performant, fault tolerant and cleaner code.

Having said this, the experience is tiring and makes the job of being a programmer a very different experience. While I was a consultant I was often being brought into teams that didn’t pair and to support the businesses objectives we would bring the practice of pairing into the organisation. This felt partially like a way of encouraging a culture of collaboration. As a way of creating a more communicative and therefore higher performing team in an organisation which needed support from consultants because it wasn’t achieving its goals. Having said that, it was also the most practical way of normalising the fact that we were there to teach and coach the team. Sometimes we were supporting an organisation in a technology switch and other times we were there to up skill a workforce that an organisation felt was the best they could hire in that corner of the world. It was also the case that were often teaching project management practices and other Extreme Programming practices like Test Driven Development at the same time. Sitting with other engineers to do this feels like the best way of achieving this while maintaining development throughput, the alternative being stopping develop to running a series of lectures and workshops before continuing. In my experience, learning with real world problems is the best way to learn efficiently.

Coming in and changing the work practices and therefore the day to day experience of being an engineer in these businesses can go one of two ways. More often than not the experience was a positive one, more collaborate, more learning which supports increased interest in the job at hand as well as the career development associated with the faster learning. I am proud that some individuals I have had the pleasure to teach Extreme Programming practices to are now Technical Coaches, Principal Engineers and CTOs. Another, thankfully smaller, group though had a very negative experience. Some simply struggled with the change. Others were very content with the job they were already performing and didn’t enjoy the increased collaboration with others in their days. Some folks said they struggled to think clearly with others around and others just explicitly stated that they disliked the work, the project they were working on, their colleagues, and having to engage in it with more of their energy was not something they were willing to do.

As a consultant, it was clear to me that it was going to harder to mentor folk that didn’t want to pair with me and given I was being brought into a place by an organisation who felt they needed help to produce higher quality software so being “disruptive” and changing the experience of working in the team felt inevitable. After all, If we changed nothing then the client wouldn’t see any benefit from what we were doing. Having said that it is never enjoyable to disrupt such a large part of an individual’s life. Some of these people required transfers to other areas of the business and a few quit their jobs to fine roles in organisations where they didn’t have to pair. In some ways these outcomes were fine but simply ‘changing jobs’ isn’t an option for many people and its an extremely stressful process particularly when you feel forced.

In my current workplace I joined around 1-2 years after pairing became the default practice. My understanding is that there was a group of individuals who chose to move on from the company when the practice was brought in. Interestingly the same practice that caused them to leave was the same practice that drew me to the company. Now the practice has been established for 7 years, all our recruitment documentation and interviews talk about it to make sure they people know what they are getting into. This feels much better because regardless of if they get along with it when they arrive there in a generally understanding that its part of the job and therefore what they opted into.

There is no “one correct way” to do anything in life and there are lots of times and places where software engineers don’t pair. Notably very little of the open source community pair. So much of the software I use was not paired on. For me this boils down to the fact that not everything in life has to be “efficient”. There are many works I would use to describe the development of the Linux kernel, “efficient” isn’t one of them and yet some of the reasons it isn’t efficient are benefits. Not merging changing that people have worked hard on might not be efficient but it protects the quality of the software and stops the kernel from moving too fast which might lead to a greater number of breaking changes and ultimately result in a less stable environment for Linux users. I imagine pairing with Linus Torvalds would be one of the best ways of getting your change merged into the kernel, but good luck scheduling the pairing time in with him.

The other thing plays on my mind is that even in the context of an company that wants to be efficient, as an employee, we tend to paid for our time or expertise at a market rate. We can chose to work in any way as long as there is a market for it. Life is not, and should not be, all about the company’s bottom line. Ultimately if you don’t want to pair because it impacts your life outside of work or you just don’t enjoy it and you can find a job elsewhere that pays well enough and that you do enjoy that then is great. Perhaps it was working as a consultant or perhaps I am too deep in capitalist work culture/propaganda for other reasons. I have to constantly remind myself that we don’t have to be totally aligned with the goals or the company we work for, particularly when there is often very little incentive for you as an individual.

I am privileged to be in a position in my career and with the skill set I have built to get a job at an organisation whose goals align with mine. Many of our clients are non-profits and all of them seek to enrich the lives of the communities they serve and so (unlike when I ended up consulting at banks) constantly seeking to make the company more efficient and for the companies software to be higher quality feels like a fulfilling goal.

The company I work for is a B Corp, which is nice but I would go a step further by saying that a lot of the ideas Yanis Varoufakis talks about in his book “Technofeudalism: What Killed Capitalism” for building companies and an economy that serve all in society rather than a small number of extremely wealthy post-capitalist feudal lords.

If you are going to change a workplace in a meaningful way they at the very least, you must do it empathically. Do your best within the system work are working within. Aim for improvements to peoples lives and work for organisations that aim to benefit communities around them. Limit negative impact to other people in the workplace but acknowledge openly that change is necessary for improvement. Negative impact will likely never be part of the goal but do your best to make sure its not an implicit part of any goals your organisation has accidentally by the ambitions you have or deliberately, placed there by the greed of profiteers.