It is incredibly powerful to realise that a single engineer can influence a team’s overall happiness and, by extension, their own happiness.
But it can be frustrating sometimes can’t it? Sometimes, people just don’t get it, and sometimes, they don’t get you.
Do you remember when you just built stuff? That feeling you get when you put something together as an individual or as a team? It was good, right?
As software development professionals, we learn to listen to other people’s opinions and offer our own. As we become more senior, people will seek our opinions. Sometimes, this can be a good thing, and sometimes, it can become a challenge. We can find ourselves at odds with other opinionated people, and our ways of getting what ‘we’ want must become more integrated with what is considered good for the product, the organisation, and others.
So it’s almost inevitable that as we grow as engineers, we conflict with others. There are so many variables to choose from in this abstract world of software development and operations that there is often no way of telling if our suggestions will work better.
Therefore, despite being nominally ‘right,’ we often find ourselves unaligned with what others are doing. Sometimes, it can feel like our voice is not heard or valued.
How can we navigate these trickier waters? How can we work together as a team and still be individuals? There is a moment when you realise that you’re only a day or one bad decision away from a new challenge. This can be tiring, sometimes exhausting, and so with this in mind, I’ve put together some of the following tips, which I hope can be useful.
1. Learn to say No
Sometimes, there are those who want us to do things without following the process. And this can seem both a good thing and a bad thing. Because there’s nothing worse than a bad process that everyone is following because “it’s always been done like that” but process means repeatability and audit which was put there initially for a good reason.
So before you give in to someone who is trying to persuade you to do something, make sure you’re aware of the implications of doing it as much as you’re aware of the implications of saying No. And don’t feel afraid to say No.
2. Don’t become Isolated
One way to deal with tricky software development or operations situations is to disengage from those holding our opinions to ransom. Let those thoughts go and let the other person have their way. You don’t need to necessarily give in to their way of working but you can open your mind fully to other possibilities.
While this can be good for karma and blood pressure, it can be bad for the product, the team, and the company in the long term. But who says you need to do it alone? As an engineer (even a senior one) you’re not being paid to make all the decisions. If discussions are causing you discomfort and pain then lean on those around you to help.
Here’s an example:
I once worked with someone who had just become “Head of Developer Experience”. Although the role was a good one in theory and the person was well-meaning, she saw it as an opportunity to manage people when, in reality, this should have been handled through the existing process. She was inserting herself into situations where this could be more effectively handled by what we already had. I had a choice as an engineer to go along with her or to push back on this situation which I plainly saw as a deviation from how we worked. But after realising that she wouldn’t let it go with a “No”, I just stopped talking to her. And then I also made sure that those who did make the decisions were aware of our conversation and the implications of what she was trying to make me do.
This has the dual benefit of calling someone out on their behaviour but also providing an opportunity to explore our interaction from both sides and see if things can be improved.
3. Don’t Follow the Crowd
Saying no or calling out what we perceive to be conflicting behaviour can be good for our individual mental well-being. But if the whole team adopts this attitude, it can quickly give the impression that the team is too comfortable and prefers the status quo over making changes. We are, after all, there to change things in a controlled manner so what is our purpose if we just say No all the time?
While ‘not standing out’ in a team can be a powerful force, in the long term, this is not very satisfying. How do we balance this without opening ourselves to suggestions?
Be aware of the team’s mood. Every interaction, both internally and externally, is an opportunity to test a hypothesis. We can use external conflict to solidify the feelings of togetherness we feel when we deliver something new.
By being aware of what the ‘crowd’ is doing and trying things, we slowly find a pace of change that suits us and that we are comfortable with. We think more like a team than an individual.
4. Choose Small Actions over Big Opinions
Sometimes, we feel it’s not enough to build the software. Instead, we must impress the world that our way of building software is the right way. Occasionally, we convince ourselves that others are looking for answers, and we provide them without asking.
Log on to LinkedIn and have a look around. There is a sea of opinions. Look at your bookshelf and find more opinions. Some of these opinions are backed up with data points – case studies, surveys, facts, figures, graphs. Some of these opinions open our minds and make us more amenable to working in certain patterns that can address individual problems.
But does any of this adequately capture what is happening today or tomorrow in our software engineering jobs? Unless you’re involved with a process or tooling change, probably not. If you’re not involved in a transformation of some kind – probably not either.
And if you are involved in a tool or process transformation – then most likely, this won’t be your full-time job, or if it is, you will be looking over your shoulder.
Likewise with ways of working.
So rather than resorting to giving an opinion or quoting a book or an engineer we regard highly, think about your context. Think about what single action you can do today or this week to improve things. Don’t justify it, don’t doubt yourself, do it.
5. It’s Easier to Ask Forgiveness
Sometimes, it feels like we’re fighting everyone else. If you want to get something done, something different, you might need to consult your team, your manager, your architects, and your CTO.
Why? Because of the process and technology tools we are given allow it to happen. People can use the levers that exist to further their own agenda. And that is not wrong; everyone has a different role in a company, and you should know yours as much as you understand others. There could always at any point be a discussion on any seemingly ‘big’ decision.
This can also be frustrating. It can mean anything from slowing down the organisation’s work to limiting your personal growth. Junior or Senior – indecision can effect you.
So sometimes, you have to act. Pick a technology or a framework or a change and run with it. Run with it without thinking. Build a system. Demo it. Throw it away. Start again.
While it can seem like a lot of successful software engineers are out there writing papers, giving talks and inspiring others – working software speaks louder than words.
6. Don’t get Sidetracked by Efficiency
Many good engineers think that automation is the key to everything. It isn’t. Knowing what and when to automate is useful, but automation itself can be a distraction.
Most of the time there are better things you could be spending your time on.
7. Keep your Situational Awareness
Sometimes you have to realise you’re just in a bad situation and you need to get out of it. See this example from a recent Dropbox report.
“Generic sabotage advice was to exploit the PR process.”
“My boss said that we should aim to keep all their reviews open for at least 15 days.”
Making offensive PRs as punitive actions against ‘enemy’ teams.
Remember that you can choose your boss. Therefore choose not to work for one who messes with your head and messes up your relationships with others.
8. There is a Time for Idealism
I recently listened to the CoRecursive podcast where an engineer talked about taking a stand on architectural change while being a front-end engineer at LinkedIn. While, to some extent, he wrote off the experience as a bad cultural fit, I felt with better management, his skill and passion could have worked out really well for the company. Sometimes you just need to stick with your idealism and see where it takes you and sometimes you just need a job.
There’s an interesting discussion about this episode with views from both sides of the story on Hacker News.
9. Working Together towards Team Happiness
Large organizational changes are never a good thing, but even seemingly small daily changes can make people feel uncomfortable. Taking responsibility for our own emotions, sharing regularly with others when appropriate, practising empathy and working in a way that focuses us all on the job at hand can make a big difference to our day-to-day working environment.
We become happier people by making our everyday work pleasant and productive. Therefore, we should continuously review our own happiness and learn to integrate it with that of the team.
The benefit of this is that we become closer as a team, we gain trust and we can make decisions together without having to make it a conflict.
10. Don’t forget your Day Job
Focussing on interactions and team dynamics is powerful but we must also succeed at the thing we have been hired to do. Be the best engineer you can be and keep learning. Support others in your team, be open to criticism and always be ready to help others.
Conclusion
We work in a team. As software engineers, we want to build the best solutions, but we must always work together to succeed.
It’s tempting to think that just changing our behaviour can change the world, but it’s definitely not that simple.
While easily said, these approaches can be hard to implement. The effort is not always immediately rewarded, and in the wrong environment, change can either be very slow or impossible. However, in the right environment and with the right support, a team can become something where decision-making is almost frictionless.
Therefore, it is incredibly powerful to realise that a single person can indeed influence a team’s overall happiness.
Even “problem teams,” where big personalities cast long shadows, can become effective, happy places to work through the influence of a single individual.
Under the right circumstances, you can do this by setting a good example, modelling behaviours that you would like to see in others, and ensuring that boundaries are defined and respected.