How does a single person influence the team towards consensus and a positive change in team culture?

Question

Background

I am a software developer in a small team of half a dozen people. I am the member that has joined most recently (around 18 months) but am somewhat older than most of my colleagues.

We work for a prestigious German brand with international reach (from another Western country) and our (new but successful) project is used in multiple countries, so there is pressure to deliver a reliable, quality product. There is some time pressure to add on more functionality, ASAP.

We have quite an informal structure and flat management hierarchy and are very much self-directed. We get along well with the German management we work with directly - there may be the occasional cultural differences, but manage to resolve them as it is not a surprise. Our team itself also consists of different ethnicities/cultures, and although we use English as a lingua franca, only 1 colleague is a native English speaker.

We work mostly from home, with some office time each month. We are fairly stereotypical introverted software developers. While at the office, we will socialize some, but only about superficial everyday stuff: sport, news events, weather, that sort of thing. Almost never regarding deeper theoretical or philosophical underpinnings of our trade.

Problem

Individuals in a team have widely varying backgrounds regarding training, prior experience, interests, knowledge, how we look at problems and come up with solutions. In practice that means the way we do our work has not a unified style: everyone has a different style with can often be discerned just from reading the program code (every unit may contain contributions from multiple people added at various times). In software there are many ways of working, philosophies, methodologies, paradigms, or whatever you want to call them - let's call it the work culture of the team. (This may include things like an Agile methodology, Clean Code and code formatting conventions, Object Oriented and Functional Programming, all the way up to architectural decisions).

The problem is that we as a team are not "all on the same page" regarding many of these issues. As an example: Colleague A has read Clean Code and follows it slavishly, colleague B has read it but has some (what she terms "common sense") reservations regarding some parts, but still applies others, while colleague C has never heard of it. Another example: Colleague D still does everything in indexed for loops and builds messages with string concatenation, while colleague E keeps up with developments and uses more modern, clear and concise features from later revisions of the programming language like streams iterators and string interpolation (sorry to non-technical readers for the technical terms, they are just for illustration). In a recent discussion between me and a colleague we agreed that new additions should follow "the pattern" but could not come to an agreement at what exactly "the pattern" is.

The net result, some of the team members feel, is that the software becomes harder to maintain and more prone to errors as time goes by, since there is no "unified culture" how to approach the work. The fear is it will take longer and longer to add features and fix bugs, because reading and understanding someone else's intentions takes longer. But, we have been warned that things will speed up as more users use the project.

As well-paid professionals, our employer has the (often unspoken) expectation that we do work professionally and according to good industry practices/standards (unfortunately, there are so many of them these days (<- irony), none of which are followed that well to my experience).

I understand that realistically a single person, especially not with leadership authority, won't change everything in one fell swoop. Step-by-step influence in the right direction may be the only possible way and certainly not a certainty.

What has been tried

1. This team follows an Agile methodology, which in theory includes some "ceremonies" where team self-reflection and self-correction ("without fear of retribution") should be part of the weekly cycle. In practice we tend to gloss over those occasions so as to be able to get back to more urgent, or at least more interesting, work. Under the topic of "what can be improved" some great suggestions were put forward and actions initiated, but it then petered out/silently disappeared through negligence during day-to-day work.
2. There is opportunity for training sessions, where in the past, ways have been presented on how to effectively apply some techniques that (should) form part of our work culture. These have been received enthusiastically, but then ignored during day-to-day work.
3. Because of the above, various team members that do feel a change is needed, are now hesitant to suggest anything further and "just do their job".
4. I have - I feel - a good rapport with one other colleague, we have worked together well on aspects on some occasions, and often share frustrations with what is wrong - but even among us we don't instantly agree on everything and it takes literally hours to discuss differences, without necessarily coming to a conclusion or compromise (language and culture differences may come into play). I shudder when I multiply that effort for the other team members. Talking and convincing is not a strong point of any of us.
5. I get the feeling that people in general are resistant to change. It is easier to continue with "business as usual", it is a comfort zone and our project is successful despite it. People often don't see the big picture of the forest, how things will likely tend to go in future, when they see the single trees of the work of immediate concern in front of them.

Question

So how does a single person, not necessarily with good political convincing skills or reputation as an expert, approach a group and effect consolidation of differing opinions? How do we come up with "the pattern" and get everyone to follow it, and formalize it so that newcomers are also able to follow it - without reinventing the wheel where others have written tomes on software development? Note that in many cases, I don't care whether methodology A or B is followed, as long as the group can agree on a choice, and somehow stick to it.

---

Related

• How to tell my team that they are doing their work in the wrong / poor way? (closed) seems superficially like a similar question, but the specifics differ and so I feel the answers don't apply.

Answer 1

First, I paraphrase my interpretation of your question (the crux):

"My colleagues and I do creative but technical work. Our solutions can be correct or incorrect, but there are multiple tradeoffs and stylistic factors which confound the determination of what is 'best'. Nevertheless, consistency enables scale, and we are suffering from a lack of it. How to improve the situation without exacerbating tensions, demotivating team members and wasting time on meta work?" Blockquote

Second, I will declare my personal bias. My opinion is that creative output is maximised when all (or at least the most productive) staff members feel that:

1. They have autonomy over implementation details that they care about.
2. Directions they receive are the outcome of a negotiation between them and their boss/client. And that conversation begins with sharing the end goal.

The first of these "requirements" can conflict with standardisation (e.g. coding to a pattern). But not necessarily. And if the second goes awry, you can lose productivity to an indecisive democracy.

You mentioned that a key issue is maintainability. Why do you care? It's good for the business. But it could also be good for morale. That's where you need to focus.

Now for the hard part... how? How can you get the team to agree? You probably can't do it in a series of abstract meetings. You are unlikely to achieve it with an abstract methodology. I recommend that you encourage dialogue about specific challenges. Look for small problem domains where consensus can be found, or instruction is clearly needed, where immediate improvement can be realised, within the normal flow of work.

Be strategic about who you involve when you embark on this unsolicited quest. Obviously don't engage the least confident members of the team in an open discussion about flaws in their work. If the workplace is relaxed and informal, you might be able to introduce an element of humour to lubricate the conversation. Finding improvements could be fun. On the other hand, one needs to be realistic about what they are dealing with. If you work in a proverbial graveyard, then I would not suggest any attempts at improvement. Save yourself.

I can picture a developer working late on a Friday evening, cursing their colleague for "thwarting them again!" This isn't the ideal time for coding, nor for dealing with stress. I doubt it's very funny in the moment. However, most of us can tolerate a few mistakes from our colleagues, provided it doesn't become a pattern. If people are bottling it up and getting serially frustrated with particular individuals, or circular conversations that achieve nothing because they attempt to solve everything, then the business will eventually become toxic, or lose good staff "unexpectedly". Yet if team members feel comfortable discussing issues with each other - and especially if they can laugh about it afterwards - then these problems will resolve themselves. I have found my most successful collaborations were with people who were impervious to embarrassment. That is the key emotion you must not invoke. Though approach it from the other direction, by making people feel comfortable.

You can lead by example. You can make fun of yourself, or invent fictitious situations in which some work of yours bamboozled your colleagues. When it's make-believe, the more ridiculous the better. Though I haven't done anything so contrived (I usually try to inject humour "in the moment"), you could start some suitably frivolous code golf in a group chat. By such means, you can be amusing without the time pressure. Be aware that anything can be taken the wrong way by anyone, but without risk there is no reward. One can always find ways around a difficult crowd, to get them feeling good about solving a problem. And you really must pitch a good invitation; nothing will happen if you don't.

The best work is done voluntarily. I do not recommend setting a goal of arriving at a standard for best practice. Rather, I would aim to foster a forgiving, commitment-free, ongoing conversation around improving the consistency of future work. If the conversation is light hearted, interesting, and well intentioned, then it will gain its own momentum and eventually inertia (the good kind). You can always document whatever is agreed, but - even then - I advise giving each idea time to prove its merits before carving anything in stone. Agreeable people can agree on anything, but when the rubber hits the road... For example, you have probably (I have) encountered instances of people agreeing on the best object-oriented coding pattern for a specific problem, and then disagreeing on which of the subsequent problems qualify for application of the rule. It's just not usually that simple, since each problem exists within a broader context, and there are many ways to skin that cat. Furthermore, documentation is a burden. People sometimes feel compelled to write documentation, so let them. But you are correct to avoid a time investment until you are confident that the standard will stand the test of time. This will not make you unpopular.

When there are strong disagreements on a given topic, and both sides have a point, then maybe leave it alone. Usually there is a line of responsibility. If someone feels strongly, and they are responsible when something goes wrong, then that might be OK, but what if they leave? Some concessions will be needed for redundancy. I often wonder, who will take care of this when I'm gone? Sadly, the answer is that the code better work, because my work tends to be specialised. Whatever the specifics are, no one wants to be working overtime to fix something, and you can win points by encouraging them to develop with that mindset. Everyone wants to go home on time, so you can use that as something to rally around. However, you really want to start with the easy stuff, as even friendly debates (if had in the open) can cast a dark shadow on the entire initiative for conflict-averse people. I myself have engaged in productive debates with colleagues that were evidently "too intense" for the onlookers present, who subsequently shied away from related "learning opportunities" which others tried to foist on them. So I try to temper even congenial dialogue when it might be intimidating (I mean in a complexity sense) to others present. Revealing too much complexity to the wrong people tends to demotivate them.

Make it fun if you can. If there are some big personalities, bring them onboard, and ask them to have a good time with it [not advised in case of graveyard]. But keep it short or entertaining. Discourage long form debate in a group context.

Depending on the workplace, collaboration might be what is missing. Perhaps you just need to clearly blur the lines of responsibility when it comes to the maintenance of work. But it's very situation specific. It can also go the other way. Sharing too much responsibility might constrain your star performers. What matters is that people are thinking about each other. How will Ben fare if he has to read my code? Does Sharon have time to teach John how to adhere to this standard? Can we reasonably expect a new hire to be familiar with this pattern? Cultivating an environment where the ease of broad adoption is valued requires...? Actually valuing it. In dollars. That might be unrealistic, so go easy on yourself. Many plans are undermined by sudden changes in priorities, and the agile methodology celebrates its preparedness for this eventuality. But a business that doesn't know what it wants is (usually) not a business that values your time. Colleagues who are resigned to it all being pointless will reasonably curtail their improvement ambitions. Though if there is some stability in the priorities, things can get better.

Given the specific context of everyone working from home, developing software, I strongly recommend pair-coding. It's not that much of a boon when the two coders have a large knowledge gap (e.g. when reviewing code one has already written), though it can be very effective when writing a solution to a new problem together. I find it easier to compromise with others when the code hasn't yet been written, although one often finds that what was agreed in the earlier conversation is not practical when the writing begins! Oh well... at least you know where to start the next conversation.

In summary, the answer is "Gradually." If you can get people reviewing each other's work in a low-stress, high-value, low-consequence, few-people pattern of intellectual exchange, then problems will solve themselves. Later on, you can record the outcome.