3.2 Training in the job

Undertaking a major IT development project involves numerous assumptions that guide your planning. The true nature of the project becomes apparent later. Projects could have avoided failure if they had possessed the knowledge gained later. However, We can tilt the odds in our favor by ensuring that we, as architects, development teams, and our company, learn from our mistakes. Learning is crucial to our growth and the key to improving our future projects.

Architects learn through a blend of experience, collaboration, and continuous study. We are not infallible beings, immune to mistakes. Our best tools are experimenting with technologies, prototyping, and proof-of-concepting solutions before full commitment. It’s crucial to include these in our plans and proposals. Reflecting with others after implementations on how to enhance our work and technical solutions is also a practice we should always uphold. By doing so, we set an example and foster a culture of learning and collaboration in our teams and the broader company.

An architect should never be afraid to say, “I don’t know, but I will figure this out if you just help me.” Those are the best opportunities to coach the others around you, and others may also coach you. If you do this often enough, you will build a network of other architects, stakeholders, and communities to get support from when needed. “We used to do X wrong, but then we figured out how to do this from now on” is an inspiring story for everyone around you.

The development teams will have a more technical point of view, but they will do the same. You don’t even have to force it. Most good software developers are, in essence, problem solvers. They are not there to translate your requirements into code. They are there to determine the best way to implement customers’ needs. Solving complex issues is the most rewarding thing for them! So, when things go south, all you have to do is to ask, “What do you think went wrong?” and listen.

Collaboration between the product owners and developers creates positive feedback loops where the more technical personnel learn about the business, the more the business personnel learn about the technology. Starting the dialogue will be hard at first and will never work if the primary communication tool with the developers is a definition document or a ticket. You need to set up short workshops where the team focuses on solving an apparent problem.

The business side often has somewhat different views, especially in large environments. Before stuffing your version down their throats, it should never hurt to ask and listen. Their concerns and observations are fundamental pain points, and you should take them seriously. They often lack the tools to propose solutions that affect the root causes. That’s where you will have an honest dialogue to ensure everyone figures things out.

It’s always worth training the business stakeholders before significant projects. Something like a product owner certificate, project management training, or training on how to run effective steering groups will make your work so much easier. Train them before your major initiatives start. During the initiatives, consider booking recurring sparring sessions. Consider proposing that the steering group get a special IT management consultant, guaranteed to be partial.

When faced with something you don’t know or a significant issue, here’s what you do. Be methodical. Break the problem into smaller, more manageable parts—research, prototype, and iterate. Discuss your findings with the others around you. You don’t have to know everything. Others with different expertise may offer you fresh perspectives. You will likely find several alternate solutions. Another thing is sharing your whole process and the results with the stakeholders: building rapport.

Vendors will help you, especially if they know you require assistance. They can assign new personnel with the needed skills to the project but will not do that by reading your mind. Working with vendors is an exercise in dialogue. You establish strong connections by working with the vendors and get more access to information by simply asking. However, you should evaluate vendors’ fitness if they can’t provide what you need and act accordingly.

Making decisions is not just about the decision itself but also about the rationale behind it. It’s vital to document our learned lessons effectively. Without this, it’s challenging to institutionalize learning. By externalizing the process, we ensure that knowledge does not reside only in the architect’s mind. We want everyone to understand why we made the pivotal decisions so they can reflect on and learn from them.

It’s usually a good practice to assign someone to own the necessary change, track the progress, and document the process. Remember to run the decisions by steering groups where stakeholders may assign extra conditions based on their concerns and observations. You need that part of the process to ensure you have complete leadership support for your decision.

When you, the development team, the vendor, or your company has succeeded in something, remember to celebrate it. When lessons learned lead to acknowledged improvements, the people involved will be far more likely to support you in the future and value continuous learning. Having an all-hands meeting where you say, “We set to do this, and we succeeded by the actions of everyone involved. Thank you, good work!” is so simple to organize and is a very valuable tool.

You must always externalize the lessons learned. Retro meetups’ true purpose is not to review a sprint’s activities. The purpose is to review what assumptions changed and what we learned. Every development team member probably learned something new and should tell others about it. When externalized, others understand the nuances and will make sure they think of similar issues and solutions in the future.

Architects are not walking living encyclopedias. You don’t know everything. You are a problem solver committed to life-long learning. You approach problems with humility because it builds trust. You focus on solving the issues piece by piece and reach goals step by step. Coming up with well-thought-out solutions is more critical than not bumping into problems in the first place. You will also steer how your work environment learns from successes and failures.