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 product management (both traditional and agile) and line management. Often, my roles lack a clear definition. Then, I combine roles and skills as needed to achieve the required goals.

Many times, an essential part of my work was what I call architectural work 1, increasingly expanding into more general strategical and tactical problem-solving in terms of finding solution options for a given problem and picking (and implementing) the best option after evaluating trade-offs.

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 AG. I also support clients of codecentric AG, often as a strategic advisor. You can find a full list of the services I currently offer at my services page.

Career stages

  • 2008 - today – codecentric AG. CTO, line manager, architect, project manager, product manager, coach, consultant, pre-sales, community ambassador.
  • 2012 - 2013 – CenterDevice GmbH (Startup spin-off of codecentric AG). Lead architect, developer.
  • 2002 - 2008 – Softlab GmbH/Cirquent GmbH. Line manager, architect, engineering manager, consultant, pre-sales, developer, requirements engineer.
  • 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 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, i.e., how much work is done. I look at the business value created. Work accomplished is worthless unless the users want it.
  • AI navigator – AI currently disrupts IT. Just using AI to speed up software production will only reinforce the existing problems. I help people to leverage AI in better ways.
  • Cartographer – 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 other people.
  • Librarian – Due to our urge to be “innovative” in IT, we regularly throw away timeless wisdom carelessly. Then, we need to rediscover it, over and over. I try to preserve some of the timeless wisdom of our domain and share it with other people.
  • Translator – Having held many roles in IT helped me to learn how to communicate with lots of different people in their language, ranging from the “engine room” to the “penthouse”, inside and outside of IT.
  • Polymath – Being a lifelong learner, I built knowledge and experience in a lot of topics inside and outside of IT. This gives me a wide range of tools, approaches and options which I use and combine as needed to achieve the best possible results.
  • System design – Most of the time my job is to find sensible solutions for a set of needs, demands, and constraints. Often, this set needs to be uncovered before the solution design can start. Working in custom software development most of the time, 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.
  • 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 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, resulting in 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, learn, and move on.
  • Dislikes company politics – I know them. I understand them. I accept they are a part of human nature. I can play them. However, they do not solve problems and never drive business value. Therefore, I dislike them.
  • Empathic – I strongly believe empathy, meaning the ability to look at a situation from another person’s perspective, 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 of 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. ↩︎