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.
- Architect is unable to define the experiments. He is incompetant.
- 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.
- Architect role has a higher chance of failure. 1-2 experiments succeed out of 10. There may not be much return.
- 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.