For everyone who thinks technology is about hardware and operative systems and virtualization and containers and databases and networks and APIs and all …

If you focus on the systems and software (or the money even) so much that you have less sight of the people involved, your users and your engineers, you’re doing technology wrong.

Technology is supposed to help us, and needs to be just as much about good development experiences and operational procedures and production readiness as it is about the languages and frameworks and cloud resources and architecture used to deliver those helpful features.

My ask of all engineering leaders – PLEASE:
1. Strike the parts of recognition systems that reinforce heroism and speed at the expense of teamwork and quality & security and living a good life.
2. Make more space for your teams to call out and work together to address high-risk trouble spots.
3. Better protect your users and engineers by reinforcing more the why behind those practices and focusing less on the what—especially the parts of “the what” that don’t in fact help much. And continuing on point 1 above to come full circle here, recognize the value in and reward this “other technical work” just as much.

P.S. If you are in engineering, you are an engineering leader. Do what you can to push for the right balance of technical and procedural focus, and help make the procedural work as effective as it can be instead of leaving it just to a few to pick up. Glue work is everyone’s responsibility.

Two quick considerations to systemically balance technology and people efforts better:
1. When capturing or reviewing the impact of engineers’ work, the time and costs saved, customers attracted or retained, or other common business impact made by the activity they did, also look for negative impact or tradeoffs made to get that work done. And if the work they’ve done doesn’t make direct, measurable impact in those areas, look deeper: consider the potential impact of *not* having that work done. Similar to triaging work by assessing the likelihood of occurrence and number of users affected and recovery efforts, use those same scales to assign impact of operational work performed, or to account for the unrealized impact of them not performing that work if that’s the case. If all of the work done feeds only the obvious impact areas, also have a real conversation about if and how it robs opportunities from colleagues, builds up risk for customers, or damages the organization’s brand by ignoring the teamwork, quality, and security aspects.
2. Periodically review the health of your teams and services. This doesn’t need to be extensive or fancy, but consistent. Note that if you only use known engineering measurements to do this, you will miss incredibly valuable, unquantifiable signal from long-term maintainers, product, and support partners. Use a simple self-reported assessment scale to build a heat map, not to unjustifiably draw attention to groups that might be mistaken as underperforming, but to surface where there’s an excess of toil and risk that can be alleviated with additional investment. Looking at that self-assessment along with the measured assessments plus the business’s desired state of the team or system gives a clear picture across an organization on where attention is needed to avoid squeezing team members and turning away customers.

Focusing more on the tech than the people in it or using it risks exploiting those people, and forgetting what tech is ultimately about in the first place, which is to make our lives better. The world needs more people-focused perspective, so take time away from tech once in a while to make that easier to keep up.