About me

Hi, I am Uwe Friedrichsen.

I started software development in 1981. In 1982, I did my first freelance software development assignment. In my professional career, I worked in many roles in and around IT, including development, architecture, requirements engineering, quality assurance, operations, support, technology and strategic consulting, project and line management (both traditional and agile). I often performed a mix of all these roles and used the associated skills to achieve the respective goals, despite my role lacking clear definition.

Many times, a big part of it was what I call architectural work 1, often without naming it this way to avoid entanglement with widespread preconceptions regarding the role of an architect in IT.

I started sharing my insights and ideas in 2005, writing articles. Since 2009, I have additionally shared my ideas as a public speaker. At the resources page, I added pointers to some of my publicly available slide decks, talk recordings, etc.

Currently, I work as CTO at codecentric. I also support clients of codecentric, often as a strategic advisor. If you are interested in my services, contact me.

Career stages

  • 2008 - today – codecentric AG. CTO, people lead, architect, project manager, product owner, consultant, pre-sales, developer, community ambassador.
  • 2012 - 2013 – CenterDevice GmbH (Startup spin-off of codecentric AG). Lead architect, developer.
  • 2002 - 2008 – Softlab GmbH/Cirquent GmbH. People lead, architect, project manager, consultant, pre-sales, developer, requirements engineer, test manager.
  • 2001 - 2002 – Heyde AG. Architect, project manager, consultant, pre-sales, developer.
  • 1996 - 2001 – Alldata SDV GmbH. Architect, project manager, consultant, pre-sales, developer, requirements engineer, test manager.
  • 1994 - 1996 – GFTA mbH. Head of Operations, SRE team lead (“SRE” did not yet exist as a term, but same responsibilities), architect, developer.
  • 1993 - 1994 – Assoware GmbH. Consultant, developer.
  • 1985 - 1992 – University of Karlsruhe, Germany (today Karlsruhe Institute of Technology), Computer Science, Diploma.
  • 1982 - 1993 – Various freelance software development projects.

Complementing activities

  • 2005 - today – Writer, speaker, trainer, member of conference advisory boards.
  • 2013 - today – Member of iSAQB.
  • 2014 - 2019 – Assessor of iSAQB CSPA-A examination.
  • 2018 - today – Editor of “IT Spektrum” (German IT journal).

Particular features

I do not think a regular CV is very useful for forming an impression of a person 2. You need to have at least a longer conversation with a person. While this page cannot replace a conversation, I try to add a few more (hopefully useful) traits of myself, in case you are interested in this information.

A good starting point is the brief biography I use for conference talks:

Uwe Friedrichsen. IT veteran. Dot connector. Problem solver. Value tracker. AI navigator. Cartographer. Librarian. Translator. Polymath. System design. Resilience. Effectiveness. Simplification. Sustainability. Curious. Dislikes long bios. Tries to make IT a (bit) better place.

Let me unpack this biography:

  • IT veteran – I have worked in IT for my whole professional career and held many roles in that time.
  • Dot Connector – I am good at uncovering relations, forces, and influences between IT topics and sometimes also non-IT topics. This helps me to put things into perspective, to assess novel developments better and to anticipate evolutions in IT.
  • Problem solver – I am strong at solving complex problems and navigating uncertain situations.
  • Value tracker – Many people only look at output, how much work is done. I look at the business value created. Work accomplished is worthless if nobody wants it or needs it.
  • AI navigator – AI currently disrupts IT, like it or not. Just using AI to speed up software production will only reinforce the existing problems. I help people leverage the new options AI gives us in better ways.
  • Cartographer – I am not a pioneer who only thrives in bleeding-edge land. While I also like being in uncharted territory, more often I hold the role of an early settler. I take the findings of the pioneers, work through them, organize them, put them into context and make them comprehensible for all the other people working inside and often outside of IT.
  • Librarian – In our compulsive urge to be “innovative” whatever the cost, we often despise anything “old”. Unfortunately, because of this idiosyncrasy, we also regularly throw away timeless wisdom carelessly and need to rediscover knowledge, long known, every few years. I try to preserve some of the timeless wisdom of our domain and share it with other people so that they do not need to rediscover that wisdom again and again.
  • Translator – Having held many roles in IT and always being curious what other people do helped me to learn how to communicate with lots of different people in their language, ranging from the “engine room” like developers, testers or system administrators over business departments, finance, marketing, sales, controlling, compliance, etc. up to the “penthouse”, i.e., higher management and C-level.
  • Polymath – Being a lifelong learner, I built knowledge and experience in a lot of topics inside and outside of IT. As the old saying goes: “Jack of all trades is master of none, but oftentimes better than a master of one.” In my personal experience, being a “Jack of all trades” is almost always better than being a “master of one”.
  • System design – Most of the time my job is to find sensible solutions for a set of needs, demands, and constraints that often need to be uncovered before the solution design can start. As I usually work in the domain of custom software development, the solutions I design are often IT systems and IT system landscapes.
  • Resilience. Effectiveness. Simplification. Sustainability – I am convinced that these are probably the most important challenges we as IT need to address in the upcoming years. Explaining this would be a longer story. If you are interested, I invite you to scan through my blog posts. A good starting point is “Responsible IT”, a short, two-post blog series that provides an introduction to the topic.
  • Curious – I am always curious about novel developments inside and outside of IT. My long-standing experience helps me to put things into perspective if needed.
  • Dislikes long bios – This page is probably the most I have written about myself in a long time. I prefer to talk about my work, not about myself.
  • Tries to make IT a (bit) better place – IT is a strange place. While it is a magical place on the one hand, it is also a toxic and inhumane place keeping people in a rat race towards burnout for totally pointless reasons. I try to take some of that unnecessary pressure off the people I meet and work with and create more humane environments in my proximity. I am not always successful, but I keep at it.

A few more traits, not covered by my brief biography, are worth mentioning:

  • Systems thinker – I think in systems: the driving forces, the mutual influences between parts, and the feedback loops. The aforementioned dot connector trait is a side effect of my systems thinking trait.
  • Model builder – I am good at understanding complex situations and distilling useful models that help in reasoning about options for action without losing sight of the overarching problem. This way, I support people in making quicker and better decisions.
  • Bias towards action – I prefer working towards a solution over endlessly analyzing and debating it. I use my systems thinking and model-building skills to analyze a situation just long enough to derive a sensible local action. Then I execute, observe, and learn.
  • Dislikes company politics – I know them. I understand them. I accept they are a part of human nature. I can play them if needed. However, people’s egoistic motives, such as increasing power and status, cause politics. They do not solve problems and never drive business value. Therefore, I dislike them.
  • Empathic – I strongly believe empathy is a crucial foundation of any successful collaboration.

While this still does not replace a personal conversation, I hope this list provides a few useful insights. My blog posts provide some deeper insights into my professional thinking. If that should not be enough, let us have a chat over a nice cup of coffee or whatever your favorite conversation drink is.

  1. For me, architectural work comprises four core activities: First, understand the problem holistically, i.e., in all dimensions, taking all stakeholder groups into account. Second, find possible solution options (there is always more than one option). Third, identify their trade-offs with respect to the problem and the context. Fourth, support the different stakeholder groups in making the best possible decisions in their context by giving them the information they usually do not have in their local contexts (very often, architects do not decide, even if they think they do). Of course, these four activities unfold into a huge tree of derived skills and activities, some required, some optional to implement the four core activities. Also, the question what to do when is a non-trivial question which is highly context-dependent (see, e.g., my slide deck discussing architectural thinking for a few more details). ↩︎

  2. I know that the average hiring process still starts with a CV as a first filter. Based on my experience recruiting people, this is okay if you are looking for average people. Recruiting above-average persons or “high potentials” will fail if you use this approach. You never find high potentials by looking at CVs. You only find them by having a longer conversation with them. Side note: I am also not a friend of those 5, 6 or 8 stage hiring processes you often see these days. Seeing them, I always ask myself when people lost their ability to form a sound impression of a person in a longer conversation. If you trust your own judgment so little, maybe you should stop hiring. ↩︎