April 2020 - Edition 12, Mentorship

Introduction

If there’s one subtle change all of this isolation has caused (discounting all of the not subtle changes) it is the lack of any concept of time. Weekday, weekend, month, time of day…It’s all the same. I’ve been working from home for a while, so I didn’t think that the social isolation would feel any different, but the regularity of life – shuttling the kids to school, going to work out, getting groceries – the regular rhythm of life is gone and all we have left is a continuum. There’s something deep in there, but I can’t be bothered to think about it any harder. I just want some mindless blather, so time for another installment of an Engineer’s Perspective!

I couldn’t be bothered to think too hard about a technical topic because my brain is mush from coding (see below) so I’ll cover something dear to my heart – mentoring project teams.

Demetri's Corner

The last month has had me holed up at my computer writing the project analysis program I discussed in the previous newsletter. Progress has been good, but probably much slower than it needed to be, as my syntax discipline is poor, and I have travelled down more dead ends than throughways. But it is running now and almost met all of my objectives for the initial prototype. That is accounting for the internal scope creep of the project which has resulted in more complex output and input flexibility than previously envisioned. I’ve documented the progress so far in a white paper on the website (http://sigmaexpertsolutions.com/design-concepts/pma/) and am soliciting any comments on what’s been done to date. If you know me well, you will know that no comment meant in earnest will offend me (part of the topic covered below). If you’re interested, check it out. I wouldn’t say it’s a fun read, but you can skim most of it and look at the pictures if you’re into that sort of thing. I’m hoping there’s some interest in the work, and at a minimum I learned something that I can use to help others in the future when planning complex projects that require integrated risk and uncertainty analyses.

Now that I got the self-promotion out of the way, it’s time for today’s topic.

Today's Subject - Collaborative Mentorship of Project Teams

The term here needs some definition. Most would define the subject of this newsletter as “Leadership of Project Teams”. In essence that is the topic, but the terminology “Collaborative Mentorship” has a purpose, other than just to muddy the waters.

At my last job, the primary reason I got up in the morning and went to work (figuratively since I worked remotely) was for the opportunity to improve the functioning of a project team. I was blessed with access to tremendous talent and people. I was honored to guide them in a direction that led to the success they deserved. It is what I miss most about my previous work and hope to be able to grow successful teams in the future. Through that entire process, I usually held the title of project manager (or program manager), and that generally implies “leader”. I was a “leader” in the Navy, but in this case I was a mentor, empowering people smarter than me to grow and be self-sufficient. This does not mean shrugging off the responsibility of leadership. Instead it means protecting the team from the burden of those responsibilities while letting them execute the work, working with the team to determine how I could ensure they had the resources and support needed. That is why I considered my role not at the “Project Leader”, but as the “Collaborative Mentor”.

Leading by Example

To be a successful mentor, you need to have leadership skills so you can guide a high functioning team to success. Only by exhibiting these skills daily will you model them properly. It also sets the expectation for behaviors throughout the project team. Leading by example doesn’t mean staying there the longest, knowing the most, being the sole idea generator, etc. It means exhibiting the attributes necessary to make a high functioning team tick and get the project done – respect for each other, care about the work, transparency, and curiosity. While reading the details on each area below, consider that you cannot expect your team to hold itself to a higher standard than the one you set for yourself.

Respect is critical to all team environments and the glue that holds a team together. Without mutual respect, it’s not a team, but a group of people doing work led by a boss. Establishing mutual respect can be difficult. It is not something you can demand – it must be an individual decision by each team member to give respect. For this reason, personal exhibition of mutual respect is the only tool available to a mentor.

The quality and creativity of problem solving is directly proportional to how much the team cares about the problem. I’ve covered this in a previous newsletter, but the essence is that people that don’t care about the problem will not be as efficient, engaged, creative, or generally thoughtful when solving that problem. When doing engineering work (which at its core is problem solving) the inability to be the best possible problem solver is detrimental.

Transparency ensures that information is available where needed and provides an avenue for team support. As the figurehead for the team, you will have the greatest access to information external to the team that can affect their performance. This includes technical information, client expectations, and management challenges. It’s your job to know all of these details and direct action when necessary, but not your job to sequester them as your own problem from an engaged team where they may be able to collaborate with you on solutions.

Curiosity well managed leads to comprehension of the bigger picture and insights not otherwise available. Curiosity poorly managed leads to distraction. It’s important to model the behavior of constructive curiosity. This includes curiosity on what others or working on, curiosity on alternative solutions to a current problem, and curiosity on process improvements for the team.

The sections below talk about other functions that are part of being a team mentor, but you will not be successful in any of them if you do not provide a model of good leadership for others to follow and emulate.

Protect the Team

The Collaborative Mentor is there to support the team. And if there is one area where a high functioning team needs support, it’s in clearing the path of obstacles. Not the technical or project related obstacles – clearing those away is the team’s job – I’m talking about the obstacles that can derail a project or create unnecessary churn.

These obstacles take many forms, and they are all annoying to deal with. Whether it’s contract issues, personality conflicts external to the team, constantly changing requirements, etc. These all distract the team from accomplishing their mission and have no place beyond the “shield” the mentor erects to protect their team. This doesn’t mean that only the mentor is aware of these obstacles (see above about transparency). Instead the mentor must treat each of these challenges as their own personal part of the project to complete, often depending on the collaborative power of the team for resolution, but without shrugging off the responsibility for their completion.

Sometimes the team needs to be protected from internal operators. The inability to resolve these issues impacts the concept of mutual respect. A team member that is poisoning the mission with frequent personality clashes or inability to work out differences can be just as harmful as a malicious external entity. Care is required in properly diagnosing the situation. Is this just an instance of technical disagreement where an open and thorough understanding of concerns will lead to a more informed solution, or is this a lack of respect by a team member that poisons the collaborative environment? Resolution of this obstacle requires sensitivity as you cannot sacrifice respect for expediency. In some cases, respectful disagreement by the mentor and removal of the person from the team is the only approach available to properly support the team.

Provide and Expect Respectful Criticism

Every person deserves respect. Not every idea deserves respect. Including yours or mine. It is a hard distinction, and one that has been lost in today’s age of trolling and being offended by simple critiques of performance. The ability to give and receive constructive criticism is based on the initial establishment and ongoing maintenance of mutual respect. On this foundation, constructive criticism can be provided with little fear of ruining the team dynamic. For a team mentor, that means there should be no expectation that everyone is going to respect every idea you have. If that was the case, they are either mindless “yes” people, uselessly uninterested, or exactly like you. Assuming you followed previous guidance, this is not the team you have at your disposal, so as a mentor it is your job to foster an environment where criticism of your ideas (harsh at times) is welcome without taking it personally.

What does this look like in practice? Is it saying “excuse me”, or, “sorry”, or “no offense, but…”. It’s none of those things, rather a sincere attempt to attack the ideas and not the person or their standing with others. A strong critique where any concerns about an idea are laid out bare in private is showing a great deal of respect. A short quip in a group meeting picking on a minor detail or typo in a presentation is disrespect.

It’s an age-old adage that you should criticize in private and praise in public. That is good guidance and should be a starting point. As the team grows more cohesive and maintains a high level of mutual respect, public criticism no longer has an attached stigma of disgrace and can foster innovative conversations and solutions. The more the mentor normalizes respect of person and attack of ideas, the more comfortable all team members will be to contribute ideas without fearing the inevitable attack. Some may even welcome the criticism as a means to learn faster and get better. We all have bad ideas, but even those poor ideas can lead us down a path to a better solution. It would be a pity to lose out on that opportunity because someone is afraid of having their feelings hurt.

Keep Them Empowered

Empowerment comes in all forms. Most think of empowerment as providing some leadership authority over others. That can come in the form as a technical lead for some part of the project, a subject matter expert, etc. In the sense of mentorship, empowerment is giving the team members the opportunity to provide the greatest possible impact to the project.

Keeping everyone informed is the most powerful empowerment tool. This doesn’t mean continuous meetings or tons of status reports. But it does mean that the mentor is constantly providing information. The use of “push” communication is often valuable, and the team will pay attention to what they need. It also provides an avenue for forceful backup, which was covered in a previous newsletter. As an added bonus, monitoring the responses to the information provided provides a window into how much team members “care” and inform future decisions on lines of authority. Assume that at any moment you will be hit by a bus. If you were hoarding project critical knowledge, you failed to empower others to make the project a success.

Even with all of that knowledge, nobody will feel empowered if they cannot affect change with what they’ve learned. The path to change starts with the ability to comment on that knowledge, regardless of their position on the team. This goes with the concept of respectful criticism in the previous section. In that section we were focused on technical ideas, but the concept extends to management policies, external drivers, project priorities, etc.

Beyond these basic steps required to foster empowerment, the mentor also establishes lines of authority within a team. Selecting positions of authority must weigh many factors, including the level of oversight, the amount of experience, the need for training, and interest by the team member. There is no magic formula, but the best guidance is to make that decision based on what is best for the team, then what is best for the individuals, in that order. This goes back to the discussion of “if you were hit by a bus, who would you want in charge and are they ready?” If you are uncomfortable providing justification for your decision on lines of authority in an open setting, it is probably prudent to review the decision.

Be Available

The term “open door” policy is misleading. In a team, there should be no doors (figuratively), so it’s a pointless sentiment. Previous sections already talked about the open methods of criticism and knowledge dispersed for empowerment. This section is about all of the other things that have to be said, but generally in private. What being available really means is being approachable. It is the mentor’s responsibility to provide the space for a conversation, whether it’s a concern about an idea, personnel conflict, technical difficulty, or personal issue. In that space it is the responsibility of the mentor to set aside the time, be respectful, and care about the problem being presented. Some will be better than others at this task, but any mentor that meets these responsibilities faithfully will provide the support needed.

Servant Leadership

I want to take a quick moment to talk about the concept of Servant Leadership. In principle, I’m completely in agreement with the concept. Everything discussed in this newsletter aligns (I believe) with the intent. The leader (called a mentor here) is primarily there to make sure the team has what they need and is shielded from unnecessary distractions, allowing them to reach their full potential and grow. I will express some concern about using it as a label to define a leadership style as that puts it in a box and somehow implies it is different than “good leadership”. I also don’t like the term “servant” or “leader” in the name.

“Servant” implies that the leader is subject to the whims and fancies of the team. That is not the place of a mentor. The mentor provides what the team needs, which is often distinct from what they want and models collaborative behavior, which is not servitude but modeling. “Leader” implies the person that makes decisions, defines vision, and directs all of the work. That has a place in some situations, but in most high functioning teams, a “leader” in the classical sense will not delegate enough authority to team members, limiting the tools available for empowerment.

Your Dose of Aphorisms

Today’s quip came to me while writing one of the sections above. In a collaborative team, a lot of ideas will be generated. We often hear that there is no such thing as a bad idea, but that is frankly wrong. There are lots and lots of bad ideas. That doesn’t mean that they aren’t useful, even if it’s to highlight the worst possible solution. In other words, we need to be aware of all ideas – even the bad ones – if we are going to make informed choices.

There are bad ideas, but that doesn’t mean they shouldn’t be heard.

Explanation of Fields in the SMARRT form submission

Reference Scenario Inputs:


Number of People Infected – How many potential members of the gathering are infectious. The simulation starts when they enter (time=0).

Type of Activity – Impacts the number of particles spread as aerosols per respiration. More strenuous activities result in more viroid particles being released.

Air Changes per Hour – This is the air exchange rate with fresh air for the volume of air being breathed by the gathering. If you use forced air exchange, you can calculate the number of air changes per hour for your specific situation.

Space Floor Area and Ceiling Height – These are used to calculate the total space volume.

Duration Infectious Person is Present – This is how long the infectious person stays in the space after their initial entry. For the reference scenario, this defines the end of the simulation.

Gathering Scenario Inputs:

See the reference scenario for all inputs up to Time of space entry.

Time of space entry and exit – These values represent when you enter and leave the space referenced to the infectious person. For example, if you show up fifteen minutes late, but stay an hour after the end of a one hour party, the Duration Infectious Person is Present is 60 minutes, the Time of Space Entry 15 minutes, and the Time of Space Exit 120 minutes