Share
In the previous post I stated that there is more need for engineering talent, and that there is a war on talent going on which will only increase. However, we see many organisations that have trouble hiring engineers, and even then there is a high chance that these new hires leave within a year - sometimes even within a month. The reason is that those organisations do not provide the right environment - they do not understand the engineer’s mindset. In this part of this series we will talk about what the engineering mindset is.
Engineers are professionals like any other, but there are some specific characteristics that are relevant to create the right engineering culture. Here “engineer” means the following things:
- Engineers create products. Their career is defined by creating or changing a product. A product can be interpreted broadly. It can be software, a physical object, but also a changed team or company culture. This is literally a creative job: engineers create things.
- Engineers are the ones who must care about how well a product is built. They share a responsibility with other roles for aspects like ensuring economic feasibility and fit for use, but they are the prime role that deals with product quality, performance and other technical requirements.
- Engineers live in a meritocracy. As knowledge workers, the engineer’s bragging rights are based on what they know and how well engineered their products have proven to be. In a field where the state of the art is moving forward quickly, an engineer also must stay ahead in the knowledge rat race or see their career fall behind.
Engineers are Makers
Engineers are makers. They impact the world through the products they create, and this is their
main source of pride. Engineers want to point at something in the world and say: “I created that”.
Once I was pleasantly surprised - and had a moment of pride - when I was sent a box of flowers for my birthday: not for the flowers themselves, but for the postal routing sticker on the box that was printed by a program I built for the postal service…
A good engineering culture makes sure that the engineer can identify with the product they make over the type of work they do. Most organisations get this wrong by focusing mostly on the work a person or a team does. It even shows in how we identify employees: they have function titles like “programmer”, “tester” or “widget cleaner”, but that only describes what they do, not what they create. For a maker there is a lot more pride in “I created this product” than “I performed this task”.
To illustrate this point: I was once helping a large retailer start with eight Scrum teams. They used to be organised according to function: there was the Oracle database programmers team, the Java programmers team, the testers team, and so on. However, the Scrum teams were organised around products: in this case the product catalog, the web shop, the internal financial system, and so on. Of course there is always some resistance to such a change, but there was quite some resistance from an Oracle programmer who was the only one on the catalog team. She felt that she would be alone, away from her Oracle colleagues.
But then something interesting happened: she became a lot happier and engaged. When I talked to her I noticed that her self-identity had changed. Before the change she referred to herself as “an Oracle programmer”, now she was “a member of the catalog team”. The difference in motivation was striking and when I talked with her about it she told me that before she would get assignments that were “Oracle work”, but that was far removed from what the company did. Now she felt a direct connection whenever a new product category would go live on the web shop and this was a source of pride for her.
Maker’s Schedule, Manager’s schedule
Another effect of engineers being makers is that they often need to hold complex ideas and structures in their head. This takes focus, and this focus is often disrupted by the environment, rituals, rhythms and interactions in an organization.
Paul Graham of YCombinator wrote a very good essay that coined the term (Maker's Schedule, Manager's Schedule ). Since then other publications have picked up the term, like this well-written post on Farnham Street (Maker vs. Manager: How Your Schedule Can Make or Break You).
The essence of “makers versus managers” is that makers need long uninterrupted blocks of time to maintain focus and build up their mental model. As a programmer I was only truly “productive” at the end of a working day: often the beginning of a day I would be busy building up the mental model of the problem at hand. Any disruption in that focus is like blowing down a house of cards: you have to start over again, wasting a lot of time.
A good engineering culture makes sure that makers can work on a makers’ schedule.
Challenge and Mastery
Why does a mountain climber climb the mountain? Because it’s there. Engineers are motivated by overcoming hard to solve problems. Like solving a puzzle, this challenge is engaging, and overcoming the challenge is satisfying. Dan Pink’s “Drive” talk (so wonderfully illustrated by RSAnimate: Watch video on https://www.youtube.com/watch?v=u6XAPnuFjJc) mentions Mastery as one of three core drives for people. By learning and improving the engineer is satisfied by achieving mastery in solving that particular problem. But sadly with mastery, the challenge is gone, and this is boring. So we move on to the next challenge.
The cycle of challenge - mastery - boredom is why automation, scripting and custom tooling is so important to an engineer. It allows the mastered subject to be handled automatically, which frees up the engineer to look for new challenges.
Not all organisations are a natural fit to this cycle of challenge. They may just need endless variations of the same website, or only small changes to a mature product. An organisation with a good engineering culture takes this into account to make sure their engineers stay challenged and engaged. This does not even have to be that often: hackathons, ship-it days and variants of a day of organised freedom are a great step in scratching the challenge itch.
There’s an even more important reason for an engineer to constantly seek new challenges: their career depends on it. Engineers live in a meritocracy where the most successful engineers are the ones that can tackle the hardest problems and are up to date with the current state of the art. If an engineer is forced to keep working with technology that is outdated they run the risk that their market value is so diminished that they can not be employed anymore…
A good engineering culture keeps its engineers engaged and helps them improve their market value by offering them challenges. It’s best if these challenges are a natural consequence of the product they’re making, but if not it’s important to provide challenges through other means, like hackathons or exploratory assignments.
Engineers are focused on tomorrow’s product
Even though it’s nice to have a product out in the world, engineers know that they have to make sure that the product can keep evolving with speed and quality. And this is hard. Engineers are therefore more worried about getting ready for tomorrow’s product than the current one. There is a fine line that needs to be walked. On one hand you can always deliver today’s product really fast by completely destroying the maintainability and changeability of the product. On the other hand you can go overboard with yet another abstraction or layer of indirection that deals with a vector of change that may or may not happen. Experienced engineers know how to balance these two things, but it’s not something you can fully predict beforehand.
A related topic is effortless delivery and maintenance. When a problem occurs, the total time to repair consists of the time to detect, analyse and repair a problem. In practice the time to analyse the problem is 80-90% of the effort and time spent. Investing in fast analysis of problems is a massive time saver and reduces a large source of frustration for engineers.
A good engineering culture recognises the importance of the maintainability for tomorrow’s product and allows its engineers to put fitness for change on the agenda next to fitness for use.
Elegance and Functional Beauty
Engineers are obsessed with elegance and beauty, but not in a traditional sense. To an engineer the beauty is in the way the product is built, not what it looks like on the outside. My colleague Theo illustrated this well in our discussion:
“When I played with Lego I would literally not see the colour of the Lego blocks: I was completely fascinated by creating an elegant suspension system. To me that was the most beautiful car I could make.”
A painter knows that there is a danger of working on a painting for too long. After the painting is made there is a tendency to keep embellishing details, which has the danger of ruining the overall work. Engineers can have this same tendency if they go too far, but it does point to a strong motivation: the wish to create something that is elegant and beautiful. Any software engineer understands that “elegant code” or “beautiful code” is a perfectly valid statement to make, and are always looking for that sense of elegance in what they make.
On the other side there is the depression that can follow from having to work in a dirty and depressing environment. Pressure, lack of knowledge and time lead to short-cuts and easy but ugly fixes. Engineers not only have to look at something they consider to be ugly and inelegant, when they were the ones who produced it they are constantly confronted with the shame of the quality they delivered. Do not underestimate how strong this effect can be: bad code is literally a depressing environment.
A good engineering culture respects the need for engineers to create elegance and 
functional beauty, and will ensure that they have the interest and technical knowledge to have a mature conversation on technical subjects. From an engineering culture perspective purely driving through functional changes without any attention for elegance and functional beauty is just about the most stupid thing you can do! This does not mean that we’re giving in to the personal wishes of engineers to the detriment of the organisation. The engineer’s definition of beauty and elegance is towards a well-functioning product, which is completely in line with the needs of the organisation. Even so, allowing a refactoring has business value that you may not have thought of before: the happiness that comes from a working in a clean and beautiful environment.
Conclusion
Attracting and keeping your engineers means understanding what makes them tick. Remember that they are makers, that they have a maker’s schedule, offer them challenges and maintain their career, help them build tomorrow’s product, and support them in their search for elegance. You’ll be surprised what they’ll do for you… :-)
This installment of the series could not have been written without my colleague Theo Gerrits, thanks dude.