Welcome back! Last time we left off with our Solutions Architects discussing how best to set responsibilities and expectations of this role early on a new project. I have found amongst many projects that another important responsibility of a Project Manager is to evaluate meeting time. How many meetings, how many hours, how effective or productive? This is something I will be covering with all of my future role interviews as well, but let’s focus on our architects right now, because this one can result in some grey area.
PM: Of the amount of meetings we have in any given week, when it comes to project specific meetings, what type of project related meetings to you find is important as an Architect?
SA1: I agree there are several meetings that the SA does not need to attend. It is far more valuable to spend my time doing the work that helps move the team forward. Consider standups, for example; this is a very important meeting, but in a given week could be on average two and a half hours each week. As a SA, I want to help everyone get their work done, so my daily status is generic “I’m helping the team” or “touch base with me if you need assistance on how to implement the task you are working on”. This is an important role of an SA, but doesn’t require daily standup attendance and this use of hours. Client facing meetings, I think the SA should have a strong presence with the client because he/she is responsible for making a lot of the decisions around problem solving and as you are trying to solve problems, you need to be able to take these options back to the client to talk through pros/cons. The SA should be able to stand ahead of the development team to assist in pushing back on the client if needed due to technical reasons.
SA2: Anything technical. Anything infrastructure related. From the very beginning. The 10,000 foot view of all the parts and pieces. If I’m not the one doing the infrastructure work, I need to know how its set up and where the overlap will be between infrastructure team and architect.
SA3: Often SA’s are not quite involved enough with client facing interactions. It’s important we are invested in the project and this also means with the client interactions. It is important to be aware of time waste for a SA; for example budget status would not be sufficient for an SA to sit through a meeting for, though should be aware of general budgetary risks if needed. Meetings like standups depend on the scope and full development team. SA has good opportunity with a good team to have check-ins with dev leads and check-ins with the full team, not necessarily required to attend daily standups.
PM: Let’s talk about setting the foundation of a trusting and communicative relationship amongst project leads. How do you prefer this is setup when engaging in a new project?
SA1: I have a chat setup with just the project leaders (PM, EM, SA) and also including a dev lead or offshore lead (as applicable). This is a place where we can have team planning discussions, where we can have more high level discussions that the team doing the work on a daily basis don’t need to be a part of, but will later impact them. Topics may be resourcing, risks, etc. This chat has proved to be very important and helpful. For me, building a personal connection with everyone on the team goes a long way to making a project be more successful (all roles, onshore and offshore). If you feel comfortable talking to people then it makes having good or bad conversations a lot easier. I find all of these connections valuable, so it should be up to all project leaders to harbor this connection, not only the PM.
PM: What project decisions should we rely on a Solutions Architect to make?
SA1: As an architect, I would make decisions on pipelines, repositories, where the code lives. Ultimately, most decisions are collaborative. Everyone should play to the strengths of their role on the project. As the SA, I would NOT expect to make decisions on things like backlog board structure, or anything scrum related.
SA2: As the architect, I want to understand the scope, purpose and objectives of the project at hand. My job is how, so I will guide the decisions on how the scope is implemented.
SA3: Should the development team use docker? Technical decisions such as this. PM’s should be aware of these decisions, but not making them. There are plenty of cases where SA and PM should make decisions together like where resource time should be spent and when.
Thank you to the solutions architects that took the time to sit down and talk with me on this topic. As project managers, we have the opportunity to really embrace the expertise of those on our teams. Taking the time to understand who to rely on for what is only the first step. We must also build the trust, the working relationship and the expectations early and check in often. Visit again soon in the next part of the series as we dive into another role of a technical project team.
