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

(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.

Process

(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.

Technology

(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

Leadership/Management

(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.