Unlearning Lessons

5 Lessons I learned the hard way from 10+ years as a software engineer?is a post by Gourav Khanijoe, about his journey and relatable lessons for aspiring engineering leaders. Here's a quick breakdown of what stood out to me:

1. Self-Driven Growth: Taking charge and creating visibility, especially in leadership circles, is a valuable approach to personal growth.
2. Trust Over Talent: A focus on building trust and transparent communication rather than raw technical ability. A distinction is made between a "10x engineer" and one who communicates and meets expectations as a practical example for new leaders.
3. Consistency and Adaptability: Leadership is not just about big wins but also about showing up, being consistent, and adjusting to new environments. These qualities help lay a solid foundation.
4. Courage in Leadership: Speaking up when necessary, even in high-stakes situations, is a bold takeaway. Challenging a complex design decision and offering an alternative approach with humility shows importance of assertiveness tempered with respect.
5. Managing Challenges with Pragmatism: "Progress over perfection" is a timeless reminder. Balancing long-term goals with immediate needs is complex; breaking down work into manageable steps and documenting key decisions are essential for navigating project complexity.

Here I would also like to add - well put. However, I see "breaking down work into manageable steps" as a challenge in itself. A massive challenge given that it is a skill left up to leaders.

This skill of dividing a problem into subproblems should be something all engineers must be able to do and, yet, it is not. In practice, it is left up to leaders to "manage".

Why? It is a simple-enough process to grasp.

Take a problem, A, and subdivide into N number of subproblems A1, A2, A3, ..., AN-1, AN then take each subproblem Ax and subdivide into M sub-subproblems Ax1, Ax2, Ax3, ..., AxM - 1, AxM then take each sub-subproblem Axy and continue subdividing in this vein until the full problem space is broken down into individually manageable problems that can each be tackled in turn.

From there it takes a little bit of creativity to assign requirements to each problem and almost none to load those onto a backlog, then prioritise items on the backlog. Creating a plan to meet requirements on the backlog is based on cost estimation for each item.

Once it is put in place - follow the plan by tackling one sub-subproblem at a time; evaluate the result for each in turn, and, if solved, move to the next set of requirements, or, otherwise add new-found problems' requirements to the backlog and refine again. Repeat until all requirements are resolved (or deprioritised such that they will never be met because the system has been delivered and, in so doing, solving all the highest priority problems required to solve the big problem - whichever comes first for a set of requirements).

This is simple enough to grasp in theory. In practice, people start talking about business process workflows while other people start talking about database schemas and the conversation about subdividing the problem quickly goes nowhere. Why? Because people who want to talk about database schemas have skipped a step. That step being - define the problem 'A' (so that it can be subdivided etc etc and so on and so forth see above).

That definition does not take form of a lengthy BRS/BDS/FDS document with pages and pages of paragraphs and sections and subsections. That is not a problem statement. That is laundry list of requirements that?should?begin with a problem statement and, if it does not, an engineering inquiry into this (and minimal due diligence) would be "what is the problem statement?" or perhaps "I don't understand the problem statement".

A problem statement does not begin with "we are building a software system to automate a process (that follows at length over the next 30 pages)". That is a statement of intent and it does not explain how the automation of the process solves the problem. Nor does it stipulate what problem we are trying to address with automation. A problem statement must begin with "we wish to address the following business/customer issue in order to increase revenue and/or increase market share and/or decrease risk and/or decrease cost".

With that out of the way we can begin to dissect and subdivide the problem into subproblems. For example, problem A could be stated as: we are trying to address the customer issue of failing to log in, in order to boost customer engagement with all downstream processes hidden behind login which are not getting traffic when users fail to log in and, as a result, abandons other sales funnel processes before they can commence. Notice I did not state "we are going to fix our login system in order to blah blah blah" nor did I state "we need to change our login procedure so that it would be easier to yaddah, yaddah, yaddah" because those are not problem statements. Those are solution proposals based on preconceived assumptions of where the problem lies and what the problem is, masquerading as problem statements.

The difference between such things and an actual problem statement is that solution proposals based on preconceived assumptions do not define a problem and, so, cannot be subdivided into subproblems. They could be subdivided into subsolutions but the question remains - for which problem?

A problem cannot be subdivided unless it is first understood what the problem is. And a problem cannot be understood unless it is first defined. And it cannot be defined by posing a solution based on preconceived notions of understanding with no definition in place (that other collaborators agree with and demonstrably understand).

That much is certain. What is undetermined is who takes ownership of the problem statement? Why the project manager, of course. Who takes responsibility for creating the correct problem statement? Product owners, that's who. And the business analysts. And the system designers. It's a collective effort. How is it that the project manager owns something they do not produce? In answering that let me ask a question in response - how is it that the project manager governs delivery of any artefacts they do not produce and, yet, own? By managing, of course. The project manager needs to be able to vet for accuracy, validity and correctness of the problem statement and, if accepted, manage subdividing the agreed-upon problem definition further (just like the project manager needs to be able to vet accuracy, validity and correctness of acceptance criteria for any feature of a software system in order to effectively manage the delivery of said feature).

This process is not painful as long as adults enter into a conversation in good faith and with the intent of producing an actual problem statement as the goal result of their discussion(s).

Once the problem statement is agreed upon, the subdividing discussion needs to take place with technical subject matter experts included in the conversation. Between them, the business analyst and the system designer a set of problem divisions needs to be presented to the project manager and business owner for approval.

Once approved, technical subject matter experts need to, on their own, subdivide each high-level problem chunks each into technically executable tasks to create and maintain working software which automates data processing and forms part of the solution to problem A.

Why is all of this so difficult to execute? Because nobody wants to do this work. Everyone wants to be either assigned clearly defined tasks or assign the task of task definition to someone else. As a result, adults are not entering a conversation in good faith and the problem statement discussion degenerates to a debate about whose job is to assign which non-existent task to whom (the loser is whoever ends up doing work).

In such environments, problem statements are a non-starter foregone conclusion; an afterthought to a set of engineering practices long forgotten and cast aside in favour of nonsensical processes that govern software delivery based on biases, prejudice and assumptions; all in the name of cost saving that lead to penny wise, pound foolish "solutions" to non-existent problems and automation of tactical placeholder inefficient processes which, in turn, amplify their inefficiency once automated.

It is unfortunate but I have a proposal that I think might make a difference. Are you ready for it? Here it goes - stop doing that.

Just stop.

Please.