DEV Community

Niklas Engberg
Niklas Engberg

Posted on • Originally published at hackernoon.com on

Find your Circle of Competence — how to do well as a Software Architect

As a Software Architect you are the link between requirements and implementation. It’s an ongoing challenge to make decisions that have a solid ground, decisions that enables future features to fit into an existing ecosystem that well aligns with good software principles such as SOLID, DRY, YAGNI to name a few.

Building software requires constant improvement work. New type of technologies bubbles up every day and it is hard to keep you updated with everything that is happening. The more you learn, the more you realize how little you know, as the famous Socrates said. My experience of roughly 3–4 years as a Software Architect (by title, not if you ask me in person ;) has taught me to delimit myself into specific areas instead of jumping on everything that at first glance seems awesome and hot.

The Circle of Competence

I recently read about something called the Circle of Competence. The Circle of Competence comes from one of the best investors, Warren Buffet, and is the subject area that matches a person’s skill or expertise. This principle originates from investing money within areas that you have a solid understanding in.

The reason I’m mentioning the principle and why it caught my focus is that this kind of principle does not only apply to financial decisions, but really to everything. Including Software Development, and I’ve applied it.

The more experienced you get, you realize that you can’t do everything well. I don’t think this is anything new or spectacular but to zoom out and evaluate yourself and how you are doing is important. How do you stay focused on the things that matters to you? I would love to hear!

The Circle of Competence applied

In October last year I took the opportunity to join the financial industry as an architect / developer for a global bank. I previously worked in a similar role but in another industry so this was something completely new for me, business and company size-wise.

My former job and company were ahead in many technical areas, but rarely had those challenging projects that enabled us techies to use our toolbox fully. That was one of the reasons I left. Anyway, that’s not the point here. :)

The point is that when signing this new job, I knew that there’s going to be a lot of challenges such as:

  • define visions and standards within the software area
  • set coding standards and best practices

Those challenges are quite wide and requires a lot of decisions to be made. How do you make sure you can accomplish those? I knew that I could benefit from my experience that worked out for us in my previous work to some extent but some kind of system would be great.

Why not see how to use the principle Circle of Competence to my situation.

Okay, so this is a picture of how the circle looks:

But I think it is more accurate like this:

Split what you know into your comfort zone and what you don’t outside the zone.

Comfortable in

  • Well, to start with I have mainly been focusing to back-end development and especially the .NET platform.
  • I advocate test (TDD), have been working hard to apply clean code and good software principles etc. So within my Circle of Competence I can add this.
  • I have experience in configuration build pipelines and continuous deployment.
  • I am also quite good at communication and to transfer technical terms to non-technical people verbally. So to communicate those things should be doable.

Not comfortable in

  • What about networking, VIPs, bastion, firewall rules, DMZ and all this? Nah, I’m not really comfortable there.
  • Core Banking Solutions? No.
  • UX and front-end
  • What about bank regulation and laws? Noo, not really, shivers…

Okay, so that’s it. I’ve now divided what I know and what I don’t. This is roughly an overview and examples just to give you a hint of how I split things up. The list in reality is much longer and complex.

By doing this little exercise I can then look back at the two challenges mentioned above and answer the question:

How can I define visions and standards within the software area and to set coding standards and best practices given what I know and where I can contribute?

If I look at the perspectives of the challenges with my confident zone in mind the probability that I will make good decisions increases than if I should start focusing on aspects outside the circle.

Outside the circle, which are the areas you do know you are not an expert in, invite others to help you out, and accept that. Let them be the experts teaching you. This will help you expand your circle and hopefully you can expand others’. That is one of the philosophies I’m living after. It keeps me focused on the areas that I know I am good at.

Note that this has nothing to do with what you want to learn but rather a method to keep you focused in the areas you know you can do well in.

How do you stay focused as a Software Architect?

Did you like this article? You know what to do! 👏

Top comments (0)