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.
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.
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.
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.
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.
“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
This installment of the series could not have been written without my colleague Theo Gerrits, thanks dude.