An in-depth perspective on human-centric development

Intro

Human-centric approaches are essential to success. We live in a highly autonomous and technological world. We rely on machines and technologies to provide great services and satisfaction, often over human operators.?

Yet still, behind it all is humans. Humans developing technology, operating technology, overseeing the technology. It seems to me that we need to be reminded of that. So, what can we do to recapture the essence of why we invest so much time in developing great software?

Purpose of technology

Now, this isn’t an anti-technology post. Far from it. Though my experience tells me we all need a little reminder about the importance of humans, and human connection in the environment we all work in.?

Technology (including Salesforce, I am a Salesforce guy after all) at its core is about improving the lives of people. Everyday users, your business’ customers, executives and those making strategic decisions. We’re probably not far from the majority of software interactions being automated processes with minimal human-human interaction. But there’s always a person, or many people, emotionally invested in the results.

Specifically in a business context: if we’re not building systems to improve people's lives then we might as well not build at all. You can’t build software “for fun” in a business context. Your business is going to fail.?

The question I asked folks while writing this post was “have we evolved as technologists and engineers to be so fascinated about whether we could build something, that we’ve lost sight of why we build things?”. Not quite Ian Malcolm a la Jurassic Park, but close enough. The answer? Yes, sometimes.?

I’m not saying “don’t build software for fun”. Absolutely do that if you’re an engineer. For example, build that wacky Flow in a personal developer org (they’re free!). Or, I was introduced to esoteric programming languages (not the esoteric type because it’s specific to legacy systems or programs) as part of my research and my mind was blown. Do that if it’s your jam. Just do it in your spare time. Do it because you enjoy it, or like to nerd out with other engineers, whatever it may be. At the end of the day you’re a human too, and you absolutely should do things that make you happy.

The purpose of software and technology is making those who use it and develop it happier. But if building software is your job and you’re doing it for a business, you need to make sure you can stay focussed on the job in hand.

Focussing on the job to be done

Harvard scholar Theodore Levitt said “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole”. Thinking in this way uses the “job to be done” (JTBD) framework. Why is this important? Because people use software or technology for the outcome, not the process.?

When focusing on the JTBD, we achieve better results. Folks are more likely to use our product or services if it helps them achieve the outcome they’re looking for, and thus are more successful. One of the most challenging aspects when working with a JTBD mindset, however, is communication. Often we receive a ticket, work on the request, and ship it — without any communication with the users that will be using the feature. We need to be incredibly wary of this. We should be collaborating closely with Product and BA’s to make sure we ship applications and features that improve quality of life.?

To effectively demonstrate a JTBD framework, let's look at an example:

“Build a solution that allows me to communicate with colleagues across the business electronically.”

Based on that statement you could easily build email, or a stripped back version of Slack. But by communicating, asking questions, and digging deeper it helps us understand the true desired outcome. By doing this we want to work to get to a ticket or statement that looks like this:?

“Build a solution that allows us to communicate with colleagues across our business where we’re able to include relevant people at the right time and segment conversations based on specific projects or teams. We should be able to search our internal communication and documentation easily so that we retain context of shared information, with a view to effectively collaborating internally across multiple teams and ensuring knowledge isn’t lost.”

Much better. We’re more likely to end up with a better solution that our users like, that gets used, and helps the business achieve its primary objective of better internal collaboration. On that note, if anyone can honestly hold their hand up and say that they still use email as the primary tool for internal comms and it doesn’t drive them to insanity, I’ll eat my hat. Which brings me back to my point; users want to use things that work, with great UX, and provide less friction in their day-to-day lives.

What happens for people when we focus on people?

It’s relatively simple to understand the human impact of great technology on users. Think about your favourite application(s) that save you time, energy, money, or help you learn etc. The impact of this software as a user is tangible. They make us feel good, allow us to do more of the things we love with our time, or contribute to personal growth. But what about developers or admins?

Focusing on the JTBD doesn’t just make the people using the technology happier and more productive. Developers and admins that I’ve spoken to also say that the gratification that they feel from working closely with the users — building solutions that drastically improve the user experience — is significantly greater than just building cool things with cool tech.?

For leaders, this gratification is hugely important for your team. It generates buy-in and belief. This is essential for healthy and productive growth of the application or product you’re building. And, there are some simple ways you can start to shift the mindset to human-led, JTBD ways of working.

Mechanisms for enabling human centric development

There’s a few areas that in my experience and were founded from my research that prove the most promising and productive for creating better human experiences in development.?

Shift left

The first place I recommend starting is with a “shift left” mindset. Shift left is nothing new when it comes to software development. We often think about shifting left when it comes to testing. Test software earlier in the software development life cycle (SDLC) to catch bugs, reduce rework etc, sooner rather than later.?

Human centric shift left means to bring the users, and contact with users, into the life-cycle sooner. I mentioned earlier that tickets are often worked on without human engagement or interaction from the development team. This isn’t human centric. We don’t want to be waiting until UAT — typically pre-production after all the development work is completed — until the users interact with or give feedback on a solution. Instead, give space and time for engineers to clarify requirements on tickets. Bring them into planning sessions with users, or user feedback sessions with Product and BA teams, to help unify the experience for everyone. Breaking down silos in this way proves hugely valuable. Once more, it’ll reduce rework.

Continual reflection and communication

I can’t emphasize the importance of continual communication enough. In my experience this is where workplace collaboration tools such as Slack are invaluable.?

Another common theme from my research was that development teams can become embroiled in code or the platform they're working on. Often this is unintentional and merely a symptom of how their minds work. They like the complexity and challenge. They lose sight of the forest for the trees.?

To counter this, create intentional opportunities to step back and review the path a particular feature is taking. If opportunities aren’t created to refocus on the feature that solves a problem, rather than the code or technical nuances of a solution, then it’s easy to get lost in the weeds. I’m not a promoter of meetings for meeting’s sake (hence my affinity for Slack and async comms), but if standups are common make sure these are productive. Use standups to provide opportunities to see the forest once again, rather than an opportunity for status updates and pressure to deliver a solution for solution’s sake.?

Providing opportunities for communication and reflection like this doesn’t just break down silos. It’s hugely important for the morale of an engineer. Even small assumptions can lead to large amounts of rework. The impact on the developer(s) responsible can cascade into “if I can’t do this small thing well, then what am I doing? Am I good enough to do this?”. Creating opportunities to refocus and remain user centric will prevent this mindset. The likelihood is that the developer is hugely capable, and that erosion of confidence is hugely detrimental to their ongoing development and success within the team.?

Create systems that support failure

Failure happens. Death and taxes. Another tech cliché is “fail fast”, but often this doesn’t translate across every industry, or even within tech itself. The bigger an organization, system, or application becomes will often lead to eschewing failure when it was once supported. Supporting failure and encouraging failure aren’t the same thing. We don’t actively look to fail over and over again, but it will happen, and a mindset of acceptance to that fact is crucial for agility.

Teams that have mechanisms built into their development process that support failure are likely to be happier and more successful. This means it’s incumbent to design a SDLC that supports easy rollbacks, that systems are protected with backups of data and code, and most importantly there isn’t a blame culture.?

Failure is an indication that things aren’t working as they should, or that there’s room for improvement. I highly recommend retrospectives and objective analysis of failure events in a way that promotes growth and development. If a developer or configurator isn’t afraid to fail because systems of support are there to catch them and help them improve, they’re likely to innovate faster. They’re also going to feel more secure which is huge for their mental health and attachment to the company or project they’re working on.?

Metrics are a catch 22

We now operate largely in environments where everything is tracked and measured. It’s common in DevOps and wider engineering. The DORA metrics for example are commonly used as core indicators of performance. However, I’ve found metrics to be a bit of a catch 22 when it comes to the folks impacted by metrics. And we can largely attribute that to Goodhart's law which states: “When a measure becomes a target it ceases to be a good measure.”

Why are metrics a catch 22? On the one hand, when teams don’t have visibility of making a difference, or the effort they put in doesn’t have a tangible result, it can be really hard to convince engineers to do something well. This makes the argument for having visible metrics that we can feel good about improving on. We’re then led to setting targets to achieve in relation to those metrics, such as reducing lead time for change to a couple of days (one of the DORA metrics).?

On the flip side, introducing metrics can have the opposite effect on motivation. If we work with unresponsive or challenging systems, improvement is hard to make. This can lead to an element of learned helplessness, and it’s difficult to not fall into that trap. This can become an entrenched “it’s always been this way and we have to deal with it” mindset which doesn’t help.

In addition, if metrics are introduced, and performance rewards are tied to those metrics, people will start to game the metric. For example if you have a contract developer rewarded for tickets closed or delivered then they’ll game for the fastest result and volume closed, rather than necessarily what’s best for the end users.?

Metrics on the whole need to be thoughtful, and should represent the overall health of an application or delivery process. But on the whole I see the only metric that truly matters when it comes to human-led development being a high level of user adoption. If this number is a high percentage, then we can be confident that the work we’re doing is proving valuable.?

An important point about deadlines

Closely tied to metrics is deadlines. Having hard deadlines imposed on software teams can be dangerous for the emotional state of teams. Missing deadlines doesn’t feel good. Pressure to hit deadlines at all costs leads to burnout and a dip in quality of development. The gaming industry is notorious for it.?

Another common theme from everyone I speak to is that deadlines can shift. A small bit of investigation can lead to a large number of knock-on consequences for an application and how it’s delivered. What could seem like a small, trivial task can quickly balloon into something much bigger.?

From a leadership standpoint, an understanding of change is critical to the happiness of the teams when considering deadlines. Once again, focussing on user-based outcomes, and overall application performance as it relates to improving business outcomes is the main goal.?

Positive human experiences create better outcomes

Hopefully this post has highlighted why focussing on people is the right thing to do, always. It's been my experience that working within a hugely people-centric organization has led to greatly positive outcomes for my colleagues, as well as everyone that uses the Gearset platform.?

The best feeling I get as a member of the Gearset team is hearing feedback from our users. Feedback that the platform has changed how they work for the better, reducing stress and tension, allowing them to focus on the things that matter. Be it their professional progression, alleviating pressure, and even freeing up hours of their personal time when they would usually have to work. This wouldn’t be possible without the great leadership in our engineering and product teams that allow us to deliver a great user experience and quality application through keeping in mind that each of our engineers is a person first, and not a resource.