Hi, I am Uwe Friedrichsen. In 1981, I fell in love with programming. In 1982, I created software the first time for money. Consequently, I studied computer sciences (diploma) and have been working in IT ever since.

Professional career

In my professional career, I worked in many roles in and around IT, like development, architecture, requirements engineering, quality assurance, operations, support, project and line management (both traditional and agile). Often, my role was not clearly defined. Instead, there was just a goal and I did what was needed to achieve a successful result – which typically was a context-dependent blend of multiple skills and roles.

In many cases, 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 additionally share 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. Additionally, I support selected clients in different roles. If you are interested in my services, feel free to contact me.

Career stages

Here are my career stages as you would find them on a regular CV. Personally, I do not think those lists tell a lot about a person. Still, they might add a few shards to the picture.

  • 2008 - today – codecentric AG, working as CTO, unit lead, architect, consultant, pre-sales consultant, developer, product owner, community ambassador, project manager
  • 2012 - 2013 – CenterDevice GmbH, working as architect and developer (CenterDevice is a spin-off of codecentric, I worked for during my time at codecentric)
  • 2002 - 2008 – Softlab GmbH / Cirquent GmbH, working as architect, project manager, consultant, developer, requirements engineer, test manager, pre-sales consultant, unit lead
  • 2001 - 2002 – Heyde AG, working as architect, project manager, consultant, developer, pre-sales consultant
  • 1996 - 2001 – Alldata SDV GmbH, working as architect, project manager, consultant, developer, requirements engineer, test manager, pre-sales consultant, support employee
  • 1994 - 1996 – GFTA mbH, working as developer, architect, head of operations, SRE team lead (it was not exactly SRE and the term did not exist back then, but the job of the team was a lot like what is called “SRE” today)
  • 1993 - 1994 – Assoware GmbH, working as developer and consultant
  • 1985 - 1992 – University of Karlsruhe, Germany (today Karlsruhe Institute of Technology), Computer Science, Diploma
  • 1982 - 1993 – Several freelance software development projects

Complementing activities

  • 2005 - today – Writer, speaker, trainer, member of several 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

As I wrote before, I do not think a regular CV is particularly useful to form an impression of a person 2. You need to have a longer conversation with a person at least to form a reliable impression. While this page cannot replace a conversation, I can try to give you a few more hopefully useful hints, in case you are interested in this information.

A good starting point is probably the short biography, I often use for conference talks:

Uwe Friedrichsen. Longtime traveler in the world of IT. Dot Connector. Cartographer of uncharted territory. Keeper of timeless wisdom. Translator between floors. System design. Resilience. Sustainability. Simplification. Dislikes long bios. Tries to make IT a (bit) better place.

Let me unpack this a bit cryptic biography:

  • Longtime traveler in the world of IT – I work in IT for my whole professional career and have held many different 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 and to anticipate evolutions in IT.
  • Cartographer of uncharted territory – I would not call myself a pioneer who only thrives in bleeding-edge land. While I also like being in that uncharted territory, more often I hold the role of an early settler. I take the findings of the pioneers, work though them, organize them, put them into context and make them comprehensible for all the other people working in IT.
  • Keeper of timeless wisdom – In our compulsive urge to be “innovative” whatever the cost, we tend to despise anything “old”. Unfortunately, we also tend to carelessly throw away timeless wisdom due to this idiosyncrasy and need to rediscover long known knowledge 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 between floors – 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.
  • System design – Most of the time my job is to find sensible solutions for a set of needs, demands and constraints that often needs to be uncovered before the solution design can start. As I usually work in the domain of custom software development, the solution I need to design quite often is an IT system.
  • Resilience. Sustainability. Simplification – I am convinced that these are probably the most important challenges, we as IT need to address in the upcoming years, together with resisting the deeply ingrained urge to improve efficiency and focus on effectiveness instead because this is the actual lever towards higher productivity. Explaining this in detail would be a longer story. If you are interested, I invite you to scan through my blog posts. You will find a lot more about these topics and more in there.
  • Dislikes long bios – This page is probably the most I wrote about myself in a long time. I prefer to talk about content, not so much 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 also is a toxic and inhumane place on the other hand, 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.

While the unpacked biography already provides some ideas about my professional traits and preferences, there are a few more I think are worth mentioning. Thus, let me add those additional shards to the picture:

  • Systems thinker – I do not have a formal education in systems thinking (even if I read a lot about it), but I always was more interested in the connections between things than most other people I have met. As a consequence, I cannot but see the forces, the influences, the feedback loops, wherever I look. The aforementioned dot connecting is a side effect of my systems thinking trait.
  • Model builder – I am good at understanding complex situations and distilling useful models that help 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 holistically just long enough to derive a sensible local action. Then I prefer to execute, observe and learn. Complex problems need a probe-sense-act approach anyway and analyzing and debating them to death does not lead to better results.
  • Dislikes company politics – I know politics. I understand politics. I accept they are a part of human nature. I can play them – at least to a certain degree. But I basically dislike them because based on my experience more than 99% of all company politics games are based on purely egoistic motives (status and power), poorly disguised as company concerns which only serve the players and harm the company.
  • Empathy – I strongly believe in empathy being a crucial foundation of any successful collaboration. However, being a very rational thinker, it sometimes is not easy for me to be empathic with people who I think are on the wrong track for the wrong reasons. But I am definitely working on it.
  • Impatient change agent – I am not a particular patient person if change is urgently needed and people hesitate to move – which makes me an average change agent at best. I am good at (figuratively speaking) showing doors, explaining what lies behind and why it makes sense to go through the door. But I am not the person who motivates people to go through that door over and over again or even pushes them through if they do not want to.

Of course, all this still hardly represents 5% of who I am and how I think and act at a professional level. My blog posts provide some deeper insights in my professional thinking. And maybe, at some point we will chat about some other topics over a nice cup of coffee or whatever your favorite drink for a relaxed conversation is. But that will be then … ;)

Overall, I simply try to be a mostly nice person and make the world around me a little bit less messed-up place. I know that I sometimes fail being that person, but I am getting better.


  1. For me, architectural work consists of 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 given problem and the context. Fourth, support the different stakeholder groups to make 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 make the decisions 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. However, based on my experience this is okay if you are looking for average persons. If you are looking for non-average persons or even “high potentials” as most companies claim they do, this approach is doomed to fail. You never find high potentials by looking at their CVs. ↩︎