39 pieces of unsolicited advice for Software Engineering Managers

Johannes Hansen is the Senior Director of Process Automation & Technology at Lufthansa, and a long-time Camunda user. You might have seen him presenting at CamundaCon Berlin 2019, or met him at one of our Meetups. His advice for Software Engineering Managers, whether they’ve been more than 20 years in the job, or are fresh out of university, is not to be missed:

Recently, I turned 39 during a global pandemic and had some time to reflect on what I learned during my time as a Software Engineering Manager (i.e. someone who manages a team of Software Engineers or even multiple teams). Much of it was acquired during the last 12 years and especially while building AVIATAR for Lufthansa.

The following are 39 pieces of completely unsolicited advice for Software Engineering Managers — present and aspiring. This post is inspired by the great Kevin Kelly.

Software Engineering

Software Engineering

(1) Add some slack for technical debt. Technical debt is real. If you don’t account for it, sooner or later you will be treading water (i.e. declaring technical bankruptcy). Have a fixed amount of work (e.g. 10% or 15% of capacity) dedicated to paying back technical debt during each iteration and adjust if necessary.

(2) Use release frequency to measure speed and productivity. Story points are not a good measure. Lines of code are even worse.

(3) Accelerate is a precious and helpful book. Read it.

(4) Create an environment where engineers get quick and visual feedback on their work.

(5) Introduce Trunk Based Development as it is probably the biggest lever to increase overall productivity.

(6) Make developers write their own tests. Tests should mainly be automated and run at every build. The time for testers is over.

(7) Employ (some) Software Engineers for operations. They are great at reducing tedious manual work by automation. Google calls it eliminating toil.

What to build / Product Management

(8) Build only what cannot realistically be purchased or used. Modern software engineering resembles orchestration more than actual building.

(9) Avoid the build trap and get as close to a problem as possible and try to deeply understand the nature of the problem. No one else will do this for you. Also, read the book.

(10) Use the scientific method in problem space/user research — everything is an assumption until proven right (or better yet, wrong).

(11) Never rewrite working software from scratch unless you have a really good reason to do so. Not being able to understand the code is not a good enough reason. Source

Organizational Structure

(12) Employ product-driven organizational design as it is the best choice despite its trade-offs.

(13) Use the concept of self-organization only in mature teams. Self-organizing teams are enabled by experience. A bunch of entry-level engineers need more guidance, process, and structure.

(14) Move tasks/scope not people between teams. This ensures team dynamics work in your favor. Credit to Will Larson’s An Elegant Puzzle. A fascinating read.

(15) Obey Conway’s Law, it is real. From time to time it makes sense to change the organizational structure just to avoid some of the main pitfalls.

(16) Adhere to the fundamental principle of DevOps: “You build it, you run it, you own it.” It aligns incentives. You develop differently during regular working hours if you might be called on Saturday to fix a problem.


(17) Use a textbook SCRUM process as the default. If a team has little cumulative experience it is certainly the best way forward and the easiest to implement. A team that knows what it is doing, can adjust the process accordingly.

(18) Use awards, belts, praise, leaderboards, or trophies for all kinds of things you want to incentivize that would not be implemented otherwise. Gamification is a powerful tool to incentivize common standards.

(19) Do not hate on Remote work. If your business is developing software, you already have all the tools to make it happen at your discretion. I was not convinced about this until I was forced to implement it.

(20) Use the Spotify Model as a helpful starting point for effective organizational design. It goes into great detail explaining the trade-off between autonomy and alignment.


(21) Use the Lindy Effect when evaluating technology. Things that have been around for some time, tend to stick around longer in the future.

(22) Use the labor market when evaluating technology. When you turn to the labor market you need supply. Niche technology might spell trouble later.

(23) Use a Benefit vs. Complexity analysis when evaluating technology, e.g. does introducing Kubernetes bring enough benefits to justify the effort to run it?

(24) Let Engineers choose their own tools. Technology standards should be enforced, but this does not include hardware, OS, and IDE’s. Developers are more productive when they can use what they know.

Software Architecture

(25) Do not architect for multiple cloud providers. Multi-cloud is a narrative created for corporate IT departments. Choose your cloud provider carefully, but then go all-in on their offering.

(26) Try to build a simple machine. What does not exist, cannot fail. Credit to Stefan Richter.

(27) Invest in monitoring. Your monitoring system might be more important than your test suite. Source

(28) Build complex and reliable architectures out of very stable primitives. Source

(29) Avoid being the largest user of a certain piece of technology. You want other people to run into scaling issues before you and ensure a decent margin of safety.

(30) Implement microservices when you scale to multiple teams. They are kind of technical debt, but necessary to retain productivity at scale.

(31) If you do not plan to scale your team much, just build a monolith. The meaning of this being: Every engineer has a complete overview of the whole codebase. It can also be majestic and saves you some overhead. Source

(32) Reduce your time to restore. This is often more valuable than adding tests to prevent errors in the first place. Source

(33) Try to test in production, if possible. There are surprisingly many situations where this is feasible. Source A coworker jokingly called it: “Only cowards test in staging”.

(34) Do not spend valuable engineering time on moving cloud workloads to your own datacenters. Cloud costs are nowadays table stakes. Source


(35) Be a servant leader. Servant Leadership is not modern or new or fashionable, it is simply effective and the best way to manage a software organization. Start with the original Greenleaf article.

(36) Provide psychological safety for your team. No one should fear harm when stating their opinion or being who they are at work. This seems obvious, but in reality, it rarely is.

(37) Measure things important to you. “What gets measured gets managed, what gets managed gets done.” Peter F. Drucker. Also, his book is a classic on management.

(38) Read High Output Management. It is the most effective starting point when you want to learn the best practices of day-to-day management.

(39) Hire the best people you can. Not necessarily the best people in the world, but spent an enormous amount of blood, sweat, and tears in getting (and retaining) the best people possible. It pays off handsomely in the long run. Source

Johannes Hansen is the Senior Director of Process Automation & Technology at Lufthansa. This post was republished with his permission and you can read the original here and follow Johannes on Medium.

Plus, if you’d like to read more content like this, specially for developers, why not subscribe to our Developer Community Newsletter? Find out what the community has been up to each month, from new extensions to conference presentations, and see how you can get involved.

  • Traceable Test Coverage for all process stakeholders

    Dominik Horn is Co-Founder of FlowSquad — specialists in process automation and individual software development. You may know Dominik through his COVID-19 pandemic work, where FlowSquad teamed up with RemedyMatch, to implement Camunda as the backend of its logistics solution, quickly and accurately matching thousands of protective items with the people who need them each day. In this guest post, Dominik explains why FlowSquad has developed a platform that ensures traceability for all stakeholders and seamless integration into your CI/CD infrastructure: In software development, test coverage is an essential indicator of the quality of an application. Only through comprehensive and systematic testing can errors be detected and fixed early on. For this reason, there are numerous test libraries for almost...

    Read more
  • Publishing “Practical Process Automation”

    A Book about Orchestration and Integration in Microservices and Cloud-Native Architectures In today’s IT architectures, microservices and serverless functions play an increasingly important role. But how can you create meaningful, comprehensive, and connected business solutions if the individual components are decoupled and independent by design? How does this all affect business processes and process automation? I’ve been thinking about this question for a long time now, and I discussed it with many customers in real-life scenarios. This resulted in many blog posts, conference talks and articles. This again led to countless discussions, that showed one thing clearly: We need guidance. Today I am thrilled to announce that I’ve condensed my experience (and of course the whole Camunda team’s to some extent) in...

    Read more
  • Highlights from the Summer Hackdays 2020

    The Camuda hackdays are a wonderful time of year where the people in the company who like to code spend about three days working on their own fun passion projects, either in a team or by themselves. These projects have often become the catalyst for new features and community extensions. This year we had more people than ever joining for the hackdays and of course for the first time we did it fully remote! Supported by a lovely care package from the wonderful Camunda backoffice team. Hence all the lovely hats in the pictures below!  More than 20 teams gathered together. At the end of the three days we got to watch each team present their project. The kinds of...

    Read more