When I started scribbling the first notes that would eventually condense in this series, the working title was: “Ten ideas I stole from software engineers.” What made me start scribbling was seeing software engineering teams at work and deftly tackle issues other types of knowledge workers have a lot of trouble with. Non-software engineers are of course just as smart, motivated and hard working… and yet some differences in the established habits and work methods are gigantic. In some cases, what people in other fields see as the solution gets attacked by software engineers as the core problem – and vice versa.

   As I collected and arranged observations, it gradually became clear to me software engineers have one big thing going for them. By the very nature of their jobs, they are confronted on a daily basis with complex systems and the accompanying bestiary of perplexing phenomena. They have been tackling system problems a lot longer than many other fields. Those are now increasingly confronted with complex behavior too – ironically in no small part because they are increasingly digitized! The opportunity for other knowledge workers to adopt learnings from software engineering is enormous.

   These concepts and ideas start where personal development ends. If you mastered the Seven Habits and know everything about Getting Things Done, but feel you don’t entirely understand the invisible system of work humming around you, this series is for you. We’ll analyze the cause of some frequently encountered problems and discuss what we can do to address them – ideally with your manager’s help if it’s available, but without if it’s not. If you are a managers yourself, so much the better. Most of my examples involve finance processes or professionals. It’s a group of knowledge workers present in any company and their challenges and misconceptions are representative for many others. Plus it’s a species I know well.

   The first idea we’ll steal from software engineers is simply the crucial importance of getting feedback.


If you hang out with software engineers, it won’t be long before you hear the term ‘agile’ thrown around a lot. The Agile Manifesto is a set of values and principles published in 2001 by a group of developers intent on improving software engineering practices. Since then, a lot of ink (and beer, I would imagine) has been spilled in those circles thinking, writing and talking about Agile: the pros and cons, various refinements and sub-branches, and what have you. But the basic ideas in the manifesto are an equally interesting read for non-software engineers. It’s short, too.

   The first principle in the manifesto is: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The authors drew inspiration from lean manufacturing, pioneered by Toyota in the 1970s, where value is defined as: “Everything that your customer is willing to pay for.” By contrast anything the customer is not willing to pay for is considered waste. The great software engineers I know are customer-obsessed and value-focused.  

    This theoretical classification of value and waste is simple enough, but a lot more nuanced in practice. Customers experience their value in an integrated, holistic matter, not in some piece by piece, broken down form. Furthermore if you ask a customer, they will not always be able to articulate what specifically they attach value to. You could argue, for example, that the way an Apple product is packaged and the resulting experience of unwrapping it is part of the overall customer value. Most companies consider product packaging as a necessary evil and waste they try to reduce. Apple on the other hand invests in the design and presentation of their packaging. Nevertheless, an Apple customer will have a hard time saying how much value they attach to this. Most would probably say their willingness to pay for it is zero.

    Likewise there’s more to “waste” than first meets the eye. Does any customer really want to pay for activities such as internal controls or the quality department in the companies they buy from? And yet, these activities are necessary to deliver the end product’s value. For that reason this is sometimes referred to as “necessary waste”, as opposed to pure waste which literally adds no value.

    Simplified to the extreme, the business of software engineers is writing code. Code which customers are willing to pay for is valuable; code customers won’t pay for is waste. The software production process does not  resemble a traditional linear manufacturing process: it is a highly creative, but complex workflow. To understand, analyze and improve all the steps from idea to final product, software engineers apply approaches such as value stream mapping. We won’t discuss these in detail, but it involves determining how the right bits of information are communicated to the people in the production workflow that need to know them. Software engineers have no choice but to deeply care about this information flow. Whether they like it or not, they will get a lot of customer input on what’s valuable. Even if they don’t do much customer research, there will be bug reports and feature requests. If they don’t get this information channeled to the right teams and coders, there can’t be any value creation or completion of a project. For software running as an online service, the feedback loop is usually even shorter. As soon as the service goes down, every customer is simultaneously impacted and the pressure to restore the service is immediate.

    All of this is not exactly how things work in your average finance department. Finance as a profession is of course a house with many rooms, covering a wide variety of specializations and activities. Just like software engineering, financial workflows are complicated. It is difficult for any single individual to have an end to end view of an entire workflow. Often these workflows have all sorts of interdependencies. However unlike software engineering, the workflows aren’t creative. The majority of the work doesn’t involve building something new, but repeatedly executing something new. As a result, it is less obvious for the finance professionals inside this system to think in terms of customers and value. When asked, many would probably classify their work as “necessary waste”.

   Timely publication of accurate accounting records, the execution of a smoothly running accounts receivables process, providing insightful financial analysis to managers, filing tax returns correctly and timely… It’s all necessary, a business wouldn’t survive very long without these activities. But at the level of individual roles and tasks, the value question may sound meaningless. “This is not a matter of creating value, we have no choice, we are obliged to do this thing.” Perhaps so. Still, it’s workflows consuming resource inputs and producing result outputs. And these outputs are valued – in a literal sense: they are paid for, in the form of salaries. If you, as a participant in this workflow, want to be valued more – in the form of recognition, promotion or a higher salary – you should borrow a page from the software engineering playbook and become customer-obsessed and value-focused. “What is the product I create? Where does my output go next? Who’s operating downstream from me in the workflow? Who is the customer at the end of the line, what do they value, how do I contribute to that and does my work perhaps get distorted on its way to delivery?”

   Regardless of your role or place in the hierarchy, it’s never wrong to understand why you do the things you do. To better understand the value of your work, the next step in the workflow is a good place to start if you don’t know who your ultimate end customer is. It should be relatively easy to figure which team or person uses your output as their input. We’re simplifying a little, of course. Many roles involve a variety of workflows, tasks and output. But the principle is the same. You may think the next step is your manager, but that is usually not the case. For a business analyst producing reports and recommendations, for example, what we’re looking for is somebody taking actual decisions and action based on the report. If no such decisions are ever taken, the report has no impact and the analyst’s work is not valued. That’s a career dead end, the analyst should either stop spending time on the report or find another role! There’s this wonderful anecdote by Scott Adams, he of ‘Dilbert’ fame, where one of his readers once ended a report writing: “In conclusion, I hate you all” and never receiving any comment on it. The anecdote was meant as an illustration of the bureaucratic stupidity at some company. But if the author didn’t immediately get a new job, it’s also a proof point of professional lethargy. Why would you want to stay around doing something nobody cares about? Another red flag is a manager keeping our example analyst in the dark on internal customer and use of the report. A good manager would freely share such information, and possibly also add value with advice, coaching or validation. But not everybody is a good manager, and once again the only right action is to leave and go work for somebody else.

   Once you figured out who your direct customer is, you must develop a deeper understanding of what they value. The fastest way to do that is getting feedback: information on what does and does not work well from the customer point of view. The majority of finance teams I’ve seen simply don’t do this. They carry out their tasks as they interpret them and essentially self-evaluate their performance. I call this “grading your own homework”. Usually the conclusion of this self-evaluation by a team or their manager is they do a pretty good job. How surprising. By contrast it may sound scary to invite a form of criticism of your work by others, but there is no need to fear feedback or take it personal. You’re merely asking how you can better help somebody. Most professionals will react constructively to such a question. Some of the greatest fun to be had at work is thinking from somebody else’s perspective and trying out new ideas together with them.

   Be critical though and insist on the right kind of feedback. Don’t accept vague statements, such as a request for faster delivery, if nobody can tell you what the positive impact of such an improvement would be. Keep in mind that your next-step-customer may not be the end customer. A great piece of feedback to ask the next in the chain is what their customer values. (By the way: if you depend on output produced by another team, how often have you been asked for your feedback on their output? If the answer is “never”, doesn’t that begin to strike you as a little odd…?) The most valuable forms of feedback you can get are not verbal at all. People don’t always say what they mean, or mean what they think. Actions speak louder than words, so you want to take stated preferences with a grain of salt and try to observe the revealed preferences. McDonald’s customer surveys may indicate people want more salads, but actual orders prove in reality they want burgers. There’s a reason software engineers, website designers and marketing analysts conduct A/B testing or similar real world trials whenever they can, and perhaps there’s ways to conduct little experiments in your field too. The ultimate form of revealed preference is, of course, people voting with their wallet – the very definition of value.


   In summary, creating an information feedback loop is a great way to understand what is valuable in the workflows you participate in. It’s your path towards creating more value and being valued more – or alternatively, discovering that there’s better places to invest your time and effort. It is entirely possible you discover your work is necessary waste. In that case, increased value can come from increased efficiency and reduced cost in your role or the entire workflow. This can work for a while to upgrade your career, but it’s not infinite. Even worse, you may discover the majority of your work is pure waste. That is confrontational and not fun to find out, but it’s always better to have your eyes wide open to reality and start taking action. You can of course also decide to simply stay where you are, not worry about all this customer and value stuff and just keep getting paid for your activities. That’s fine, but be aware you’re then effectively outsourcing your career decisions and somebody somewhere will take them for you. For everybody else, who likes to be in charge of their own destiny: stop grading your own homework.

(First published: March 2022. )

Download in PDF format.

Leave a Reply