Inside Out

Notes on seeking wisdom and crafting software

Tactical steps

🧘 Philosophy
💼 Work
ℹ️ The text discusses the importance of long-term thinking in resourcing and architecture, especially when running a startup or established product. It highlights the need for understanding customers, industry positioning, and balancing tactical moves with strategic planning. The author also addresses concerns about investing in longer term Architecture and provides reasons against it, such as skillset limitations, tactical mindset, and resource constraints.

We tried to frame some of the obstacles to longer term thinking on resourcing in the last post. Architectural thinking is one of the those investments which triggered the post, however it seems to apply to other areas equally. For example, investing enough time to understand the customers, or to learn deeply about the industry and positioning of a product.

Resourcing conflicts can be easily resolved by moving over the effort to the burning problem at hand. I’d like to see them as tactical moves.

Tactics does not necessarily mean flying blind. You must know the immediate move or two. You must also know when to transition from the tactical steps to a more mature strategy.

If I am running a startup that doesn’t even have a business pivot yet, is it prudent to spend a senior developer on the Architecture? I’d rather use the experience of the senior developer to move fast. Experiment with twenty ideas and see what sticks.

On the other hand, if I am running a well established product with a predictable growth trajectory, I need to put money on thinking five or ten years ahead. Playing a tactical move in such situation will trap the team into a series of reactive moves. Urgency dictates the course of action and we lose the bigger picture.

Let me reproduce some reasons for not investing in longer term Architecture from last post.

If I were a Manager, these are the cases against resourcing.

  1. Architect is unable to define the experiments. He is incompetant.
  2. I don’t buy into the philosophy of long term investment. I’d have used the senior individual in Architect role in a much better way.
  3. Architect role has a higher chance of failure. 1-2 experiments succeed out of 10. There may not be much return.
  4. I’ve too many burning problems, and genuinely there are no resources.

1 is matter of skillset. It can be resolved with appropriate coaching and guidance.

2 and 3 show a tactical mindset. It is worth probing deeper to understand burning problems at hand. What is the true reason for push back? We should remember that Architecture is mostly a matter of luxury; we get there only when we have ensured that the basic aspects are covered (cf. Self Actualization in Maslow’s hierarchy). Are we missing certain aspects in the product which are prerequisites for the Architectural thinking? Have we closed on the scope of Architecture? Is there a consensus?

4 requires empathy. Have we setup the team for success? Are we burning out engineers? We cannot drive a successful product with a part of the team burning midnight oil and the other creating lofty diagrams for a future that can never materiliaze. Do we understand the strengths and weaknesses? How does our velocity look for the past few sprints? What does the sprintly retros indicate?

All of the questions are aspects of alignment within an organization.