How to build your training plan and grow your practice of software architecture (part 1 of 3)

Brian Loomis
9 min readDec 26, 2024

--

Yesterday you said today

Just like everything in software architecture, the only constant is change. We may move jobs and the new team practices agile differently than the last team, we may be on a new project that involves wholly new technologies (or much newer versions or patterns than previously), or we may be asked to broaden what we do in architecture into documenting systems of systems, creating guidance for an information schema or building test plans — perhaps areas our previous team had “people” for this and now it’s the architect’s responsibility.

I wrote this article first for the manager of architects on how to build team maturity through training plans and found that this was also starting to speak to the individual practicing architects as well, building out their plan. We’ll talk first about the individual training plan for technical architects, then about where to look for cheap sources of training, and finally about how to plan the team’s training, through mentoring or coaching.

TL: DR If you want to skip down below to the description of the methods, feel free to do so — you can come back to this introduction and context for the architecture manager later.

Back in the day, I was in a team at Microsoft where we had an annual personal objective of taking 200 hours of training. It was self-directed, but if you did not demonstrate meeting your quota, you would not get top marks on your performance review. If you’re in an organization like most nowadays, this type of forced maturity model is probably foreign; in fact, you may find that training is something that we pay a lot of lip service to but don’t make commitments around, much less dedicate time away from the “rest of our day job” to actually doing.

The case for having an individual training plan is most important for retaining employees in the organization — if the organization feels that the individual is going to be there for the long term, then maturity is an important step in building organizational culture, ability to change roles, and the ability to take on new business challenges and initiatives. On the opposite side, if the organization does not see individuals changing (they are in short-lived positions or fixed positions with no career pathing), then this investment is likely not justified.

To point out some of the challenges architects face, I’ll just list three that my team and I have faced in the last two weeks:

  • Building a test plan for a set of small products to which I had previously not been assigned, and did not have a clear customer journey or tooling
  • Develop a complete design for a bolt-on application for a larger tool which was in a deprecated programming language, requiring me to learn the new language plus the old one for extracting requirements and domain expertise
  • Developing a scale strategy in phases for a Kubernetes application in a cloud environment which could be simply implemented by a team with low DevOps familiarity, and which would provide a legal service level to customers, in a month

I’m going to go out on a limb here and say that it doesn’t matter if the organization has a training group, or HR function, to develop training plans for individuals. The individual software architect must develop their own plan so that they can own it (commit to it, see value in the items on the plan), and follow through on it. You know your growth plan better than anyone else you work with. There may be some required training — for example, compliance — which the organization asks you to complete but this rarely helps you in the bigger context of your personal career moves, role maturity (developer to architect specifically), or project demands.

Make your personal training plan (process)

To build a personal training plan, you will need to identify goals for your training, identify specific sources of training that support the goals ,and then put them on the calendar. It’s that simple.

To develop your training goals, a simple statement about where you want to get to realistically in a year is adequate. I usually follow with a gap analysis (I know, sounds kind of geeky in an architecture way) to find the most interesting areas for me as an individual and have a conversation with my manager about what the organization finds most useful for my growth — not always the same thing, but where they overlap, you’ll obviously have support. And then we write up a plan.

Defining training goals

You only need 1–3 statements, and they do not need to be deep analyses — the statements will guide you. They also should be aligned with what you really want — not what your manager wants (or you think s/he wants) and not a compound list (eliminate AND from the statements, that’s exactly like reducing the font on your resume to make it fit on a page). It’s really more than 3 goals and your ability to focus/execute on a list of ten items is much worse than 1 item. I had a friend from the military once tell me that, “If you have a plan B, you never really expected plan A to work.”

Some sample statements from training plans I’ve worked with people on (my interpretation in parentheses after):

  • “Become CTO of the product line, focusing on technology selection” (leadership, platform engineering)
  • “Be able to design applications in Rust” (architecture and language skills)
  • “Learn enough of GitHub Actions to move off of Jenkins” (technology transformation, develop business case)
  • “Understand telemetry and reporting systems for enterprise systems” (recent technology, user experience)

Gap analysis to find strengths and areas to develop

Gap analysis may point out areas you are strong in (and may be able to mentor others) as well as areas of perceived immaturity — things you may not have ever done or do infrequently, and areas that the “business” may be expecting you to do more frequently or in a new domain/priority area.

Here are some of the areas I look at when performing the gap analysis:

  • What do I know about the business my organization is in? How do we make money and what % comes from which products? How do my customers perceive value in our solutions? What competitors do we have for my products?
  • What do I know about the applications I work with? Does my team have a single application with algorithms I want to learn more about? Are there some applications in the portfolio I may be assigned to one day?
  • What technologies are used in my group? And which are being considered on the horizon (either for our group, groups we work with, or in the industry at large)? What personal technology interests do I have (one of mine is home automation, not super-aligned with the business but may come in handy someday)? Current technology maturity may be more of a focus for developer training plans, whereas horizon technologies may be more for architects.
  • What code/data patterns does my team use or want to evaluate? Could be CQRS, resilience,microservices, LLM or “buzzword of the week,” where the organization does not have a conceptual knowledge but has not yet defined how to implement in next-gen products.
  • What architecture skills do I need to grow? Developing designs, diagrams, text writeups and analyses (maybe story and epic writing), maybe estimation or alternative analyses… This may be a focus area for developers wanting to move into architecture roles or as you grow your own practice of architecture through new projects.
  • What leadership and “soft skills” am I missing or do I think I’m very good at? If you’re a skilled presenter at conferences, can you mentor a peer? If you have never done an executive/board-level presentation, who could coach you? How easy is writing for you — practice makes perfect! How do you give and receive feedback? How do you socialize design with your team?

To the manager: Work with each architect on their growth plan; compare plans to each other and share best approaches, making sure the organization’s interests are covered.

The “dream sheet” conversation

If you are a manager of architects, this may be accomplished by having reviews with each architect on their goals (I call this a “dream sheet” review) and then aligning organizational goals. Architects generally have their own personal areas of interest, have organizational coverage areas — which applications they design for (for example) — and organizational growth areas (trends and future needs may be specified by a CTO or inferred from a roadmap).

For our team, each architect should be maturing to the following organizational goals:

  • Have one major cloud architecture or DevOps certificate
  • Have senior developer proficiency in one or two language frameworks (for example, Golang, customary libraries, common patterns, build processes, and quality measurements) to be able to coach scrum teams
  • Manage domain model, requirements, and design activities for up to 3 products in the portfolio
  • Have a standard set of architecture skills to be able to execute SAFe responsibilities like other architects (ability to operate independently in the process with other stakeholders outside of engineering)

A couple of example dream sheets:

Dream sheet conversation notes

Building a plan and writing it down

In the next post, we will look at some common sources of training in more detail, but first I wanted to show what a real plan would look like. Typically, this is written up in a meeting with your manager and then the responsibility for doing the items in the plan (execution) is up to the individual architect.

The training plan is concise, just like the dream sheet — it’s a proposal of activities that the architect will take on with when in the year they occur. Below is one from a senior architect that shows when the training action needs to be done, what the organizational (manager-represented) and the architect’s personal priority for the item may be, what the item is, and how it supports the individual’s growth and organizational alignment. Junior architects should generally only have 1 action item per quarter.

Sample personal training plan

From the organizational perspective, we may have resource time and cost constraints on training activities. The manager may discuss the blend of modalities — types and ways to get training (shown in the training plan above in the action item column in parentheses) — with the individual within these constraints:

  1. Formal training like conferences (including speaking at the conference) of experts or an in-person training class in Bali or a certification exam; often this is the most expensive and focused (several days offsite)
  2. Online, tool-based, or book learning — self-enablement where you find a reference work that describes the topic, and you can work at your own pace; limited cost of materials — maybe a compiler license or courses in a subscription the organization may already have
  3. Informal peer-based training — seeing others inside your organization, or in Meetups externally — demonstrate a technology or approach
  4. Mentored training — having a peer guide you as you take on a project, maybe providing feedback on a design you are doing, or “red-teaming” a proposal; usually outside the normal project structure since your peer may not be on the team in a formal role or could be a senior architect mentoring a junior one in an area they are taking on for the first time and bringing an example
  5. Experiential training — or “on-the-job assignments” — to learn practically. Maybe it is to write up a test plan for the project you’re working on or to develop a prototype on the side.

Organizations will naturally favor items down the list because they are low-cost or free, and they are directly applicable to work you may be assigned in your current role. My rule of thumb is about 80% in categories 4 and 5, 15% in categories 2 and 3, and one item in category 1 per year. Your blend of types may vary.

Send me your thoughts on this (brian@princetondigitaladvisors.com) and stay tuned for the next post, where I’ll write about where to look for cheap/free training in the areas commonly of interest to aspiring architects.

NOTE: ChatGPT condensed this post over on LinkedIn at https://www.linkedin.com/posts/brianwloomis_how-to-build-your-training-plan-and-enhance-activity-7273799791317327874-UzaL?utm_source=share&utm_medium=member_desktop, compare the different versions and let me know your thoughts.

--

--

Brian Loomis
Brian Loomis

Written by Brian Loomis

S/w architect at www.princetondigitaladvisors.com, a consultancy focused on digital transformation in demanding biz and CX scenarios. CTO & EVP s/w engr

No responses yet