On Competence Centers in the Modern World

I’ve built a lot of personal projects. I’ve taken part in a lot of group projects. When one does so many projects, one tends to learn a lot about how projects are done. This blog post will discuss a concept I’ve recognized called “competence centers” that I’ve found to be essential when doing projects. In this blog post, I’ll discuss my idea of competence centers, what they mean, what’s important about them, and how I notice them changing.

A competence center is something like a skill, but I wouldn’t map it on directly to a skill. A skill may be “is able to operate a specific model of a CNC machine”, while the comparable competence center may be “is able to learn to work with different cutting machines quickly”. I’ve found that people can be generally grouped into different “competence centers” and that essentially everyone I’ve met has a competence center, even though they might not have specific skills yet. From this, I’ve found that learning and combining different people’s competence centers is one of the core goals of leadership. People with starkly different competence centers generally don’t like mixing and may find it hard to understand and work with others – but this is precisely what every project needs.

I define “project” in this post specifically as an organized human endeavor that attempts to accomplish a goal. This can be starting a company, making a short film, or recording a song. All of these require people with different skills working together towards a goal. It’s very likely that none of those people individually could do all of the tasks required, but by combining their skills, they can accomplish the goal. In this context, competence centers are relevant because no project starts with the same material conditions as another – sometimes you have a lot of time, but not a lot of tools. Sometimes you have a lot of tools, but very little time. Sometimes you have neither, sometimes you have both, and every time you have external circumstances that unexpectedly lead to issues. The point of a competence center is that people who are vaguely competent at a field can quickly learn to adapt to work with the resources that they are given.

Many people say that the complexity of modern projects is increasing – demands are higher, time is lower, and everyone is expected to do more with less. This, naturally, leads to burnout and people quitting the idea of doing things in general. If you can’t win – why play? As someone who’s been doing a lot of projects, I have a different perspective. Modern tools increase productivity by a lot, and I believe that this matches the time demands quite well. If something now takes half the time, but the productivity of you with your tools is doubled, then nothing has changed in the end from the perspective of the project. However, behind this, in my opinion, the true change is hiding. I claim that projects these days aren’t more difficult in terms of effort, but that they require a fundamental redistribution of competence centers in the direction of abstraction. 

What does this mean? Essentially, as modern tools are more automated, more efficient, and more affordable, we are able to accomplish more complex tasks in a faster way. As the easy tasks are now gone, modern projects involve a greater focus on abstract tasks that are not a priority in simpler ones – planning, documenting, evaluating, and similar disciplines that do not directly accomplish the goal, but help in allowing people to accomplish it and help in creating a snowballing effect where each subsequent project builds on experience from the previous one. This, like in many other fields in the modern world, allows for teams that are good to keep getting better, while others get stuck at the beginning and cannot proceed.

Additionally, this means that the competence centers are shifting quickly. Many jobs or roles that were essential in the past are now becoming obsolete through automation. A single person is able to do the jobs of many others, but now that single person needs to use multiple competence centers to accomplish this. To use an example, I built myself a smart bench DC power supply for my electronics projects. In a few days, I designed the circuit, simulated it, built it, tested it, put it on a PCB, ordered the PCB, assembled the PCB, designed an enclosure, 3D printed the enclosure, and then assembled all of the parts. Though an electronics hobbyist 50 years ago would also have been able to build a DC power supply, the complexity of what I’ve done would require an entire team at a lab. Instead of a couple of components drilled into a plank of wood, this is an entire system with safety, self-testing, relatively high precision, thought-out mechanical design, wireless communication, a display, and standardized components and connectors. This involves many more competence centers, and above all, the ability to look for and find information. 

This last thing is something that I’ve noticed becoming more and more important. Instead of knowing one thing very well and being able to apply it over and over, the skill of being able to find information and abstract away the specifics is becoming more relevant. In job postings, the depth of skills gets shallower, while the breadth gets wider. Interestingly, I feel like this drastically accelerated with programming, but that for the past years, most job positions (and industries) have been following the patterns set by the software industry. It’s not uncommon for software developer jobs to desire one person to be capable in 10-20 different technologies (e.g. “HTML + CSS + JavaScript + React + Bootstrap + SQL + Docker + Kubernetes + Nginx + Ansible + Linux + Git + CI/CD + Jira + Scrum”). In addition, these technologies are by themselves so immensely broad and change quickly, that without the ability to constantly look up new information, learning specific skills makes you obsolete in a year or two.

Unfortunately, this is leaving a class of competence centers behind – this time, people who like to go in depth and people who like work that is more manual. Additionally, whole new fields of meta-competence are opening up – how to manage existing knowledge, how to teach people to learn quickly, how to teach people to look up up-to-date information, how to write documentation, how to reflect on and evaluate existing work, how to research, how to manage global supply chains and global teams, and many more skills that have been much more niche so far. Educational systems are absolutely incompetent in teaching these meta-competence skills, since teachers themselves are strictly regimented and not allowed to apply any meta-competence themselves (partly due to political and partly due to practical reasons). This is leaving behind huge groups of people both young and old, who have competence centers that are automated or planned away, while young people feel more disillusioned with education that is preparing them for the last century. 

Based on this, my advice would be to train these competence centers yourself. Due to my personal interests, I had a huge head-start, and this has taken me quite far. You can train and practice these competence centers through doing more advanced, more abstract projects and applying the aforementioned meta-competences. For example, I’ve been trying to more and more formalize my design processes. If I’m building a smart bench DC power supply, I’ll do it like this:

1. Create a new Git repository on GitHub.
2. Clone it locally. Create the standard directory structure: /Hardware, /Firmware, /Docs, /Fabrication.   
3. Initialize the /Docs folder as a new Obsidian Vault.   
4. Inside Obsidian, create Project_Requirements.md and Traceability_Matrix.md.
5. Define a requirement (e.g., R.1.0: “Must provide 3.3V power from a 9V input”). Add it to a Requirements Matrix.   
6. Create a GitHub Issue for the first task: “Issue #1: Design and layout power block”.

For designing, I’ll apply a simplified version of the V-model. This would look something like this (as an example, I’ll use the power block of the smart DC power supply):

1. In KiCad, design the power block schematic, following all readability rules (logical flow, symbolic pins).
2. At the same time, in Obsidian, update the Traceability_Matrix.md for R.1.0:
   1. Design Artifact: Hardware/project.kicad_sch p.1
   2. V&V Phase: Unit Test
   3. Test Case ID: T.UNIT.1.0
   4. Test Case: “Apply 9-12V. Measure Vout. Pass if 3.3V +-5%.”
3. Layout the PCB, using the DFM rules from your chosen manufacturer.
4. Commit your work: git commit -m “Feat(HW): Add schematic and layout for power block. Refs #1”.

For fabrication, I’d do this:

1. Write a full DFM checklist (e.g. is the board 10cm x 5cm, is the right thickness specified…).
2. Run the full DFM checklist.   
3. Add the revision v1.0 to the silkscreen layer.   
4. Export Gerbers to /Fabrication/v1.0/.
5. Export the BOM and import it into InvenTree to check stock.   
6. Commit the fabrication files: git commit -m “Release: Files for v1.0 fabrication.”
7. Tag this commit: git tag -a v1.0-fab -m “Release v1.0 sent to fab”. Send for manufacturing.   

For validation, I’d do this:

1. PCBs arrive. Assemble only the “Power Block” components (Unit Testing).
2. Execute test T.UNIT.1.0 (from the Test Plan/Matrix). It fails. $V_{out}$ is 0V.
3. Bug Found: Create Issue #2: “v1.0 Power block dead on arrival, 0V out”.
4. Investigate: A visual inspection reveals a forgotten solder joint on the LDO.
5. Fix: Solder the joint. Re-run T.UNIT.1.0. It Passes.
6. Update Traceability_Matrix.md: Test Status: Pass.
7. Update Issue #2 with a comment: “Fixed. Soldering error on U1. Board OK.” and close it.
8. Proceed to assemble and test the rest of the board (Integration, System tests).

To iterate on the project, I’d do this:

1. During System Testing, a new bug appears: Issue #3: “Device resets when battery drops below 50%.”
2. Investigate: The LDO (U1) has too high a dropout voltage. A different part is needed. This is a design flaw.
3. Formal Change: Create Docs/ECN/ECN-001.md.
4. Reason: Bug found in System Test (Issue #3).
5. Affected: project.kicad_sch, project.kicad_pcb, BOM.csv.
6. Change: “Replacing U1 (Part-A) with new LDO (Part-B) with lower dropout.”
7. Make the fix: Update the KiCad files.
8. Commit all changes: git commit -a -m “Fix(HW): Replace LDO U1 for low-dropout. See ECN-001. Closes #3”.   
9. Run the process again.

This might seem excessive, and for small projects it is, but for larger projects, following a process like this means that you essentially linearize the time it takes for your project – instead of a project getting totally unmanageable when it gets more complex, the complexity is chunked into small, defined processes that you can use as a gym for your systems-brain. This kind of thinking has helped me get into much more advanced projects and build and learn things that I couldn’t have done had I continued with the idea that I’ll keep everything in my mind. You can play around with this idea – for example, I’ve found that I don’t like typing lots of small notes all the time, so I use voice memos with NotebookLM to do some of the keeping track. What’s important is to follow the idea of meta-competences and to focus on shifting your competence center towards being competent at building competence centers. This is difficult, this is impractical, this takes a lot of time, and this takes a lot of energy. I acknowledge that. But I believe that (and I’ve read enough educational science books to know that) only through that kind of rigorous, structured training that involves lots of feedback and iteration can you get ahead of others in the current day.