The most common misconception people make when they hear Human-Centric Engineering is that it’s all about the “fluffy people stuff”. Things like increasing engineer happiness (whatever that means), mood surveys, and “wellbeing Wednesday” initiatives.
But that’s not it at all.
You see, that so-called fluffy stuff generally comes from a place of good intention, but there’s very little practical outcome. Not for the engineers, the leaders, or the organisation. Broadly speaking, it is surface-level niceness, and everybody knows it. There’s also a pervasive cultural sense of “this stuff doesn’t belong at work” and that if you lean into it too heavily you will start to lose credibility.
Human-Centric Engineering is different.
Sure, we also have good intentions, but from our time in the field - as engineers and leaders - we know that to have real impact we need to generate practical outcomes. We also recognise that whilst companies often focus on technologies, tools and infrastructure, the greatest obstacles and challenges are human factors.
A first step towards Human-Centric Engineering is acknowledging this: people are the delivery method of software. Despite all of the tech, tools, processes, and practices out there, the key component in any engineering team or tech company is people. Without the people and their relationship, there is no software.
Human-Centric Engineering then, is about getting the best out of people, teams, and organisations. It’s not about getting the most out of people, but enabling people to give their best. The clincher being that if you expand the time-horizon just a little, that “best” overtakes “most” anyway. Sustainable success sounds good, right?
So how do you get the best out of people on an ongoing basis? Well, this is where you have to:
Recognise engineers for what they are. People. Humans. Complex.
Create the environment and ecosystem for them to consistently give their best.
It’s about being more humane and creating the conditions for thriving in a long-term sustainable way.
Yes, this still sounds somewhat lofty and fluffy, but we’ll get to that. First we need to lay some foundational definitions. We have developed a Human-Centric Engineering philosophy and associated set of 10 principles to act as a mindset guide for creating, leading, and managing human-centric practices. These are open-sourced on GitHub and we welcome feedback and suggestions for improvement.
The Human-Centric Engineering Philosophy
The philosophy is directional and aspirational, designed to exist beyond the confines of our business. It positions the way of thinking and the “why”.
Software engineering is not just a technical endeavour, but a deeply human one. It’s more than the software and the engineering. It’s about the people who come together to build the software. The creators are as important as the creation itself.
Understanding systems and software is hard, but understanding humans and their relationships is so much harder. Working with humans is more art than science, more sensing than reasoning, requiring continual learning and adjustment to thrive.
And when engineers thrive, we create the conditions for world-class software delivery and team performance.
Human-Centric Principles
We ground our thinking and our work in fundamental Human-Centric principles which form the basis of our approach to products we build, the services we offer, and the practices we employ.
The following principles are applied in all that we do.
1. Always be human-centric
Humans create organisations and build products to serve human needs. The work we do in organisations should also fulfil human needs, not just for mere survival but also as a source of fulfilment in its own right. Humans need community and meaning. We should strive to organise work in ways that encourage human flourishing, being alert to anti-human processes, technologies and behaviours which diminish human thriving.
2. Don’t fear reality
People are often afraid of speaking up for fear of reprisals. We can be very good at hiding reality or avoiding difficult situations. Encouraging open, honest communication ensures that challenges are addressed head-on, leading to a transparent and resilient organisation capable of making well-informed decisions and taking decisive actions. Embracing reality builds a foundation for trust and continuous improvement.
3. Anyone can lead
Leadership is not just a role, it’s an attitude that anyone can adopt by being proactive and inspiring others to take responsibility. For this to happen, people need to be trusted, supported, and encouraged to lead, with a clear view of the objectives of a given situation. People and teams flourish when they are trusted with responsibility.
4. Encourage team-first thinking
Engineers thrive in teams with a strong purpose and clarity in their roles. Working from the context of a cohesive product vision, with appropriate cross-functional skills, teams can be autonomous, self-determined and self-organising. Delivering as a team, not as individuals helps with enhancing productivity and ensuring the work is meaningful and motivating.
5. Developer experience predicts customer experience
Miserable engineers are unlikely to make software that makes customers happy. Prioritising the developer experience doesn’t mean pandering to engineers, or obsessing over their feelings, it is an indicator that they are working efficiently and effectively to deliver sustainable value. Developer Experience is a good proxy for productivity.
6. Mastery matters
Engineering work is susceptible to drudgery and unsustainable heroics when relentless pressures fail to allow time for developing mastery and craftsmanship. People are more invested in their work and crave opportunities for continual learning when quality and engineering excellence are prioritised and nurtured within the organisation. People care about mastery, people care about being good at what they do.
7. Appreciate complexity
Engineering teams, like living organisms, are complex adaptive systems with many entangled and dynamic elements. Our understanding of complexity is inherently fragmented making cause and effect difficult to discern and frequently our actions will have unintended consequences. Engineering is a complex sociotechnical discipline and human judgement and behaviours can only be assessed within the context and influences of the wider ecosystem. Understanding the difference between complicated and complex helps us to accept and appreciate complexity for what it is.
8. Humans are fallible
Recognise that humans are inherently fallible. We all have blind spots and emotional triggers that affect our ability to make good judgements. When we communicate with one another our messages are subject to filters, biases and flaws leading to misinterpretation and misunderstanding. We should foster blame-free cultures where curiosity and experimentation are encouraged, failures are systematically incorporated into organisational learning, and assuming the best intent is normalised.
9. Value flows through the entire organisation
Value creation is a collective effort, not just the responsibility of engineers. Engineering is an equal stakeholder in this process and their practices should be transparent and visible to all in the value chain. It begins with providing context, with information flowing freely so everyone understands their role in creating value. Effective communication and feedback throughout the value chain ensures that no one works in silos.
10. Pragmatism over dogmatism
There is no single best way to lead or transform teams. There are many frameworks, models and variations in how these are implemented and it can be tempting to follow the latest trend as a silver bullet to solve organisational problems. However, the inherent complexity of organisations does not yield to ‘best practices’, or even ‘good practices’ - they require the pragmatic discovery of ‘emergent practices’, through experimentation and inquiry according to the unique circumstances teams face.
What does this mean in practice?
This is all relatively high-level, and that’s intentional. These are, after all, guiding principles.
It’s not a “how to” guide or a blueprint for success.
So much of the people stuff is deemed “fluffy” because it’s unmanageable. It’s unmanageable because it’s confusing, frequently ambiguous, and highly contextual. Not to mention constantly shifting.
For this reason “how to” guides and blueprints simply don’t work.
The aim of our work is to bring human-centricity to organisations by removing the fluff, confusion, and ambiguity, and closing that context gap. To unearth and visualise the motivations and behaviours at the heart of your team dynamics to close the human context gap. To create contextual feedback loops to monitor the impact of change, bringing hidden barriers, blockers and bottlenecks to the surface so they can be managed.
Through closing the context gap and presenting the previously unmanageable in a manageable way, we can become more human-centric without the fluff.
By doing so, we are able to create the conditions for engineers to thrive.
And where people thrive, organisations prosper.
Love this! Early on in my career as a software dev I always felt like something was wrong or missing about the way myself and coworkers were treated by leadership. It wasn't until I became a leader myself that I realized many organizations treat tech workers as if they are robots, and many leaders in tech follow suit because they never learned any other way. I'm writing about human-centric engineering and management over at Humanware. Glad I found this newsletter.