The year of focus

Are you embarrassed by your screen time report?

Thoughts on focus

I hate scatter-brained approaches to work. I often refer to “science projects” as something I consider a red flag 🚩 and avoid myself.

Why? So many of us today are plagued by an inability to focus. As a Solution Architect, science projects are an easy way to indulge our short attention spans while not delivering the less exciting projects with the follow-through they require.

Science projects are fun. Spiking a new idea is exciting and fast-moving. Documenting, testing, maintaining, training, follow-ups - all of these are required to make any solution work in an enterprise, but they are much less exciting in the moment. And we’re less likely to be heroes in that moment.

Books on the subject

I’ve read a few books that have touched on this over the past year, including The Comfort Crisis by Michael Easter and The Coddling of the American Mind, by Greg Lukianoff and Jonathan Haidt. I also read a couple books that aimed squarely at the problem, namely Digital Minimalism by Cal Newport and, finally, Stolen Focus by Johann Hari.

My takeaways are no surprise: our focus is being hacked by big tech, the answer should be both from individuals and society at large, etc. For me, the fight against losing focus is a personal, on-going, and never-ending committment. Much like fitness.

Science project vs individual learning

Here’s a challenge in my current job. I often have to experiment with something hands-on in order to learn. This learning allows me to teach the field of SE’s, stay ahead of customer challenges, and contribute value alongside Product Management. Those are 3 pillars, in my view, of the role of a Solution Architect.

I’ll define “science project” broadly as: an individual exercise that is undertaken to learn or deliver something, but is also fun, exciting, or impressive. It may or may not be core to your job role, and the value to the individual is greater than the value (if any) to the organization.

So here’s how I personally ensure that my work doesn’t fall into the “science project” category:

• document. This includes internal documentation on SharePoint, or for me, this blog site.
• share. Present on an internal call, at a conference, to your own team. If the knowledge and learning stays with you only, it’s a science project.
• make repeatable. Github repo, instructions, fully delivered software. You need a deliverable of some kind, even if it’s a recorded presentation.
• tie back to customer value. During the work and it’s presentation, outline why this matters for customers.

Conclusion

I’ve jotted down these thoughts partly because I think they are important for the organization, but partly as a personal policy in order to hold myself accountable. As we enter 2026 I’m continuing to hold the line of discipline against the hacks on our focus.