Do Your Job

Photo by LinkedIn Sales Solutions on Unsplash

Ooh, the title I wanted was: Do your job, and only your job, and expect others to do theirs. But that seemed obnoxious even for me, so I started the article with it in the first sentence instead. I’ll add: don’t do my job or tell me how to do it, and if you are a leader don’t do your team’s job or tell them how to do it. It is necessary for your teammates to own what they own—to be accountable for what is in their job jars and how those jars interact with all the other jars that touch theirs or rely on them. Let’s face it: Systems Engineering is tough enough as it is. It is even tougher if people have no idea what glop is in their job jars, and impossible if there aren’t jars and all the glops just mix and mingle on the floor, with little footprints marking our paths. Here is my monumental offering in this article: let’s be good at what we do and expect others to do the same. Sometimes I surprise even myself by my stunning genius.

Competence as a Requirement

“You must have confidence in your competence.” – Elijah Cummings

One thing I have observed about my experiences in engineering and technical leadership is that competence is generally prized above who you know and even how you act, though both are also important. Networking and establishing healthy relationships will certainly help and is necessary for any endeavor (and for human sanity), but these are eclipsed if you don’t contribute value, and annihilated if you are a perpetual energy vampire for others. In addition, individuals who demonstrate technical competence but are bad for the team are generally tolerated by other engineers, even though they might even go so far as to be culture killers. I do not bring this up as a positive, but it is an illustration that engineers place a premium on folks who know their jobs and get them done. It is important and should be.

“Jean is absolutely floundering on getting our contracts rolling and communicating status to the rest of the team. 50% of my components and parts are long-lead and I am about two weeks away from getting on critical path. There is no way I can do her job and mine because I just don’t have time, but our subsystem relies on competent, timely supply chain management. We are failing and I need your help.” When this issue boiled up to my level, I saw it as an absolute emergency that required immediate intervention and management. We had a member of the integrated product team who was either not competent or was not communicating, or both; either are a significant risk to successful subsystems and systems engineering. But poor communication is a quick fix, while building competency is a long game.

As an aside, let’s acknowledge that the word “incompetent” is most often values-neutral. I am incompetent about a poop-ton of things; I become irate if I must spend more than a few minutes thinking about how the tax code applies to me, and I am paralyzed if my wife asks me “what’s wrong with the car?” When I took on my current role, I was incompetent. I was asked to lead a team who had decades of experience designing and integrating radios onto satellites but did not have these decades under my belt myself. The team I was joining was also an unknown, with many unique and strong personalities (which I am grateful for every day, seriously). While I understood the basic technologies and had many related experiences, and while I understood the need to assimilate into the team and build new relationships, my level of competence on day one was poor. This is acceptable, and we all should appreciate and support a learning curve. The example in the preceding paragraph was not this; the incompetence in the example was not values-neutral. Competence is a requirement, and the training period should be over ASAP.

Cylinders of Excellence

“Excellence is the gradual result of always striving to do better.” – Pat Riley

Let me say that I love silos or, as I have heard them called, “cylinders (or pillars) of excellence.” The idea that we should establish and maintain cylinders of excellence is, however, justifiably unpopular with individuals and crowds who have been bit by silos that were unconcerned with collaboration and/or interfaces.

General #1: We know how to vertically integrate but need to horizontally integrate.

General #2: What the hell does that mean?

General #1: Basically we need to share information early and often between our silos—good collaboration and communication so we don’t mess up the endgame.

General #2: OK, I can buy that, though I don’t like the buzzwords.

General #3: You know, what we really need is diagonal integration.

General #1: <<Stares silently>>

General #2: <<Throws arms in air>> Now you’re just messing with us!

While it is buzz-wordy, the terms “vertical” and “horizontal” integration are telling and useful. Our team must be damn good at what we are supposed to do, and we must be accountable for the technical performance of our subsystems and their interfaces – vertical integration. We have requirements and verification flow-downs, as well as assembly and integration flows that attempt to incorporate our working subsystem on to a larger platform. But as good as we are at what is in our vertical job jar, there are also a thousand things we can decide and do that mess up other subsystems or the system as a whole, and there are ten thousand things others can decide and do that will make our great subsystem not work with the rest of the vehicle. To make this positive—nothing up my sleeve—on a positive note, there are also ways we can make others’ work easier by working together. So we must bring others into our silo, poke holes in them when needed, build pipes from one to the other, and try like hell to avoid catapulting flaming balls from one pipe to another at the eleventh hour. At no point will we diagonally integrate, though, because that is squishy nonsense. In any case, I can’t think of a way to make the pipe unnecessary so I must lead its establishment and maintain it.

From a leadership perspective, then, it is on us to build an environment, processes, and controls (when needed) to ensure we are vertically and horizontally integrated. Building a silo requires training, mentorship, experience. At times we need to duct tape one engineer to another, set up peer reviews, review and approve work; in other times we need to throw an engineer into the fire by providing a growth opportunity with support only when he or she requests it. To be vertically integrated means we understand what we are accountable for and we are willing to own it; furthermore, we share lessons learned about how to be better at our core competency area and are focused on growing together as a team. Horizontal integration, on the other hand, requires understanding of what others are accountable for and how that job jar either complements or overlaps with our own. It requires relationships and the “systems” part of systems engineering.

Stay in Your Lane

We need you. The best version of you. You're here for a reason, and we can't wait to see what that is. Stay in your lane. Run that race. – Grace Gealey

This may not be shocking after what I have written so far, but I might have received feedback a few times in my career that I am “parochial” and that I “protect my rice bowl.” Based on my previous posts about establishing relationships for collaboration, this seems out of character; however, I have brought up several times that we need diversity of ideas and division of labor. In technical endeavors we must hire specialists to divide the labor, because we need a level of depth of which a team of generalists would be incapable. It’s that competence word we started the article with, and it requires dedication and deliberation. So if we have a way to vertically and horizontally integrate, we then need to ensure we and others stay in their lanes to allow us the ability to efficiently do our jobs.

It is common for systems engineers to mess this division of labor up, and either end up micromanaging teams or paralyzing them by trying to have everyone understand everything about the big picture. As leaders, therefore, it is necessary to ensure there are solid (read written-down) definitions of roles, responsibilities, overlaps, and boundaries. Even overlaps are not bad if understood as opportunities to collaborate and coordinate decision timing to ensure all necessary points of view are considered. The boundaries piece is particularly important based on my experience, and it generally provides relief to others to know they are not accountable for x, and that another team feels acute responsibility for it. We need to be careful to not repeat these processes in execution, planning, and even hiring.

One problem I see is a growing call for hiring player/coaches, meaning hiring individuals who are to lead the rest of the team while still being accountable for the same tactical deliverables—he or she is meant to be a leader who is also expected to be an individual contributor on the same level as those he or she is leading. Ever wonder why this trend has diminished over time in professional sports? Because it was discovered that people were generally not capable of doing both jobs well at the same time. It’s a different skillset. So staying in your lane applies to this—if you are in charge of setting vision, managing changes, developing people, enhancing teamwork, streamlining processes, and improving efficiency and effectiveness of the entire operation, then what the heck are you doing taking time away from that? Why are you doing what you hired better people to do? Help them, make the team better, buffer between senior leadership and them. Do your job. I get that the best bosses are often those who were excellent individual contributors and were then promoted to leadership positions. Even then, that person’s team needs to rely on him or her to LEAD.

“Buster why do you have that RFIC Design Book,” Rick asked me. Rick is one of the smartest technical experts on my team, and routinely mentors the rest of the team on technical matters, including me. “Well,” I replied, “I am in the middle of an RF Engineering Certificate Program at X University.” I can see his puzzled face and I say, “look, I just want to be more technically credible as I try to fulfill my roles and responsibilities for the team. I’d like to be able to talk more comfortably about the technologies.” Then I see it…the “if you ever try to lead a project as a technician without significant training wheels, I am going to kill you” look. I chuckle. “Rick, if I try to be an engineering lead on a project, treat me as a new hire and make sure I get the right level of mentoring and leadership. But honestly, I don’t have time for that. I may do a few analyses so I can grow myself here and there and we’ll work together on it. More than likely it will just be a redundant analysis so I can see how it stacks up. I won’t do anything on my own. Deal?” This is met with a sigh of relief. I am after knowing more about the language my team uses and the enabling technologies behind our subsystem, and anyway RF engineering is somewhat black magic, so it appeals to my inherent elitism. I know implicitly I cannot and should not do what they do as a job. Player/coach would be a disaster because I could do neither job well if I tried to do both; I believe it would be exceedingly rare for someone to do these jobs well simultaneously.

One clarification note: if you want to branch out, learn, grow, expand your knowledge, then do it. I don’t mean “stay in your lane” like: “When people are used to you doing something, they want you to stay in that lane.” - Kevin Durant. If you want to grow, become good at that, do that, and kick butt.

“If everyone does what they are supposed to do…we win…do your job” - Bill Belichik

The idea that we should do our jobs, do them well, and avoid doing jobs we can’t do well seems intuitive, and yet is a root cause of many team failures on technical endeavors. It is a singularly challenging aspect of systems engineering, and I spend a good part of my professional life trying to help refine and define roles, responsibilities, boundaries, and overlaps to avoid current or future conflict, mistakes, misses, and even major failures. Sometimes there are overt attempts to eliminate silos based on some well-meaning philosophy that a blob of glop means better collaboration; if true, then teamwork will be amazing, and the end product will not work. More often, however, this gets messed up as engineers fail to adopt their own roles and understand their own boundaries, or if they are undefined in the first place. So we leaders can help define and enforce them—it’s not rocket science or RF Engineering.

Feel free to re-read this article, entitled: Do your job and only your job, expect others to do theirs, don’t do my job or tell me how to do it, and if you are a leader don’t do your team’s job or tell them how to do it.