If you have spent most of your working life outside any form of IT department or engineering team, you probably won’t have come across many of the personalities that you find within those areas. I have been a software engineer since graduating from university
and I can safely say that we are a unique bunch, more so when compared against a cross section of a financial institution.
I am always amazed at how many “managers” of IT based functions have never been engineers for any substantial amount of time, in most cases they have never been an engineer at all. For me, this is a worrying sign for various reasons, primarily the lack of
understanding of engineering effort, the lack of understanding of engineering complexities and the lack of understanding of the personalities that can be found across engineering teams.
Often a lack of engineering experience within more senior functions, or management functions within IT, especially within financial services, leads to the embedding of misplaced values when it comes to agile and agile culture. In addition, the lack of experience
interacting with the personalities that make up IT also leads to an inability to keep engineers fully engaged, fully motivated and firing on all cylinders.
Expectation
Often, we have an expectation that teams and individuals are fully motivated, motivated because of the remuneration they receive. It seems that within financial services this is a very common mistake. Sure, remuneration is a part of why an engineer stays
with your company and yes it may motivate them slightly, however it’s actually a small part of the overall picture. Sadly however, remuneration is often perceived to be the only motivating factor.
For engineers there are other factors that motivate them. If the executives need hard proof, then remember this, for the majority of engineers they have the allure and option of “contracting”. This does take money out of the equation, as more often than
not, engineers move from role to role as contractors for the same daily rate. So it is clear other things motivate engineers.
For me, working on new technologies, the challenge of solving a problem that no else has yet looked at, building a proof of concept, proving you can make a solution work, these are all motivating factors. This is true for almost every engineer out there
I’m sure. However, this isn’t always enough either.
So, what does motivate?
Engineers are as I said, unique, so it should not be surprising that the things that help keep them motivated, aren’t similar to how you may motivate other functions across your organisation. Over the past 20+ years of engineering, here are a few key areas
that I've noticed help to ensure that engineering remains motivated.
Autonomy
Engineers are highly intelligent, highly logical people. They are problem solvers, so it is imperative that they are empowered to solve problems and to make their own decisions. Teams must be autonomous to ensure they remain motivated. One of the challenges
that the executive must overcome is centralised thinking. All too often, at that management/executive level, decisions are made regarding the definition of “what the problem is”, and therefore “how to solve it” is also decided. This thinking flows down and
ultimately removes that autonomy from engineering teams, after all, they are being dictated to on what to build, when to build, how to build.
Autonomous teams should have all the skillsets and specialists within them to best solve the problems the team will face. Sure, a strategic approach will be set at the executive from which “product” can be derived, but that product is only derived by engaging
with teams, and, individual team products are designed, solved, and built by autonomous teams, keeping aligned with the bigger picture and strategic goal.
Engineers have an inherent need to have to use their brains and solve problems, if this is taken away from them then their motivation soon follows.
Mastery
Engineers take pride in their work, fact. Sometimes far too much so, which leads to some internal friction within teams and can also lead to scope creep within your product, but that is all manageable (and another reason why you need a good coach for your
team – see my previous article within this series). Management therefore needs to embrace the fact that engineers love to master their trade and remember that they need the space and some time to be able to do this (within reason).
Mastery coupled with autonomy is why we see so many engineers heading home after a long day, only to switch on their personal machines and contribute to the open-source code bases. They want to get better at their trade, they enjoy their work, they enjoy
the autonomy of solving a problem, and they enjoy the concept of building something that is engineered well.
Management must understand that these engineers aren’t getting paid for this work, they do it because they want to contribute to something they believe in, contribute because it challenges them, because they can problem solve, and they get the opportunity
to master their trade. Money is not on the table here…
Updating your core values
If you look at your core values across your engineering culture, do you call out autonomy? In the previous article within this series, I provided two core values, delivery is greater than predictability and principles are greater than practices. Here is
a third:
'Autonomy is greater than control!'
Bring this into your core values and ensure your teams get to be as autonomous as possible with their ability to define problems, solve them and given the time to master their trade and bring quality products to production.
Communication and alignment
With autonomy comes some challenges, however these are solved very simply. That is, by involving teams in the process of product definition. Your executive and board may set the strategy, but the conceptualisation of a product needs to involve the teams,
this gets them all aligned with the bigger picture so that when they define individual product, when they solve their problems, they are all working towards the same end goal.
Great leadership understands that great communication and inspiration leads to great alignment.
Consistently challenge and stretch
Pretty much all engineering efforts have an element that isn’t challenging for the engineers, it maybe time consuming but not necessarily challenging. This can de-motivate individuals and it is this that makes things feel like a bit of a long slog.
In my experience, engineers need to be constantly stretched in terms of their problem solving, so they need fresh problems on a regular basis. In a product driven world this isn’t always possible, which is why so many engineers move from organisation to
organisation, they are seeking that constant stretching of their mind.
To overcome this, it is often worth thinking about what innovation is. Within an organisation, especially one within banking, innovation is limited to the products that are to be brought to the market, which are aligned to a specific strategy. However, there
is always space for additional innovation, new ideas, concepts, out of the box thinking. So why not provide engineering teams with the opportunity to innovate, to come up with their own ideas.
In a few instances now, I have implemented an innovation day, or days. These are days, typically once a month where all teams can take a break from their daily efforts and set their own work, think of it as a day/day’s hackathon on work that the engineers
have set themselves. At the end of the hackathon, they demonstrate what they have built to all other engineers, this is topped off by a bit of a social gathering. What is great here is that you can flex the concept of an innovation day – but it encourages
engineers to challenge themselves, look at new technologies and build product that we would never have built normally. In many cases, the 'winners' from an innovation day have their products moved into the product backlog and help enhance the overall product
offerings.
Unfortunately, an innovation day like this can often be looked at by the executive as a 'costly' day, or wasted cash. This really isn’t the case and is a very narrow view of what is actually going on: with an innovation day, engineers are being stretched,
they are becoming re-vitalised within their job, they are forming social relationships (something that always needs promoting within engineering), they are less likely to want to move organisations and they come up with ideas that in many cases, enhance the
financial organisations overall product offering. This is nothing but an all round win.
Summary
Motivation is not always about cash, especially with individuals that can seek challenges for the same money elsewhere. Engineers are motivated by the challenge and gratification they get from overcoming that challenge, they are motivated by making their
own decisions, solving problems in their way and having the time to master what they do. Smart people like engineers need to be constantly stretched, so look for ways to stretch individuals minds outside of the day to day job.
Motivated teams function much more effectively, they are far more productive and, they ship better products with less bugs. Keeping your teams motivated is probably the most important aspect of a COO/CIO/CTO responsibilities back to engineers.
To date, this agile series has very much focussed on creating and maintain the right 'agile engineering culture'. Moving forward, we will start to look at how software architecture, design patterns help enforce an agile engineering culture. We will also
look at the role of specific functions, from DevOps to RISK.