Stewardship in Technology
I’ve been in the technology realm for over 15 years now. In every place I’ve worked, from brand new developer to architect, there is a common problem. The technology team tends to be very separated from the people who use what they create and support.
There are support representatives who take calls, emails or chats when something goes awry. Perhaps it is just a matter of educating the customer on proper use of the application. Perhaps it is actually a bug, in which case a ticket is created for the development team to fix. They fix the problem in the product, and work goes on.
This mindset has a hidden danger: a lack of stewardship. We see the problem with the product, but don’t really connect the dots and think about the people impacted by using the product. In fact, I can think of plenty of times where developers are actually annoyed someone found a problem. I’m included in that statistic.
It’s not a product. It’s a person.
The technology industry needs a big shift in mindset. If you touch code, you are a steward of the people who interact with it and the information it processes. If you build or maintain infrastructure, you are a steward to the people it services and the data it moves. If you are an administrator, you are a steward to the people who rely on the system to be secure and working, and the data that passes through and is housed in the infrastructure.
The application doesn’t care. It is a machine (or a bunch of machines). We, as the architects, administrators, developers, and engineers (and every other title that I didn’t write here) must care.
Unfortunately, carelessness lends itself to too many data breaches. How many of the recent breaches have been due to careless actions like having well-known default administrator logins (read up on the Equifax breach: this was part of it)? How many have been caused by making sensitive data stores public facing and wide open? What about deprecated API endpoints that haven’t been cleaned up and removed?
A lot of these things can be avoided by recognizing you aren’t just a developer creating an application. You aren’t just a database administrator making sure the database isn’t tipping over. You aren’t just a dev-ops genius making deployment magic. You aren’t just an architect designing the most robust, scalable, fault-tolerant infrastructure.
You are part of a team, creating and upholding solutions for fellow humans, who have entrusted you to provide them with a reliable, trustworthy service. Often they are trusting you to be a good steward of very personal and sensitive information. You service people, not a product.
I’m not suggesting that we can entirely avoid bad things happening. Software development and systems engineering is difficult. At least, if you want to do it right. We are human, we make mistakes. Not every breach is caused by carelessness, so please don’t hear that.
There are plenty of other factors, such as “bad players.” The people who make a living by stealing what we try to protect. Hardware fails. Networks go down.
What I am suggesting is this: If we genuinely care about the people we affect, directly or indirectly, by what we are part of creating, we are much less prone to making careless, simple mistakes which have disastrous impacts.
What you do matters. Whether you are a consultant, a small-business employee, or working for a large enterprise, it matters. The way you approach software development and architecture matters. The way we choose to approach our work has far-reaching consequences. Good and bad.
You may not see it directly. But it matters. Consider how you have been affected by technology and the work of other people. Consider both the good and bad.
Consider how you might be an agent for the good. You matter.