Better Communications With Your Team as a Junior Engineer

As an Engineer or Knowledge Worker - our roles require the extraction, synthesis, or modification of information to complete our work and get to the finish line.

But rarely do we do this in isolation. This almost always requires communicating with other humans to get to the finish line.

As a Junior Software Engineer (or any member within a team of knowledge workers) - the Interpersonal Communication skills employed when working within an Engineering Team helps you learn and grow. As a Senior Engineer, these skills become crucial in operating across organizational boundaries.

Below are a couple of thoughts and tips compiled through my journey from support to engineering, and as a Junior and onwards. This is knowledge that was hard earned over years and challenging interactions - and I hope it will be helpful to anyone that is starting out as a New or Junior Engineer

---

This was originally a more concise Twitter thread that can be found here:

---

New Junior Engineer - Welcome!

Welcome and congratulations on your new role! As a Junior Engineer, it’s an exciting, stressful and maybe even intimidating time in your career! There’s a seemingly unending waterhose of information to ingest, countless new problems to solve and so. SO. many things to build.

The world’s your oyster and after spending years on learning how to sail, you got yourself into a canoe!

And thankfully, it’s not just you. You’ve got a whole TEAM to learn and build with. Whether it’s just one other engineer or maybe a large pizza team - your teammates will be a huge part of your experience.

But while your team exists to work together, it’s important to understand that everyone on it, is their own unique person. All of them posessing different strengths, areas of improvement and most importantly, constraints.

Interpersonal Constraints - Knowledge & Space

As humans, it’s in our nature to immediately start asessing new people, groups and surroundings for certain indicators. In early days, it helped keep us alive - and even today, it helps us determine if we are in danger. Outside of basic survival - in group settings we will also start trying to determine heirarchy, structure and try to make groupings based on different criteria.

In your induction to your team, I would suggest you asess your peers and frame your relationship to them against 2 constraints:

Relevant Functional Knowledge & Space.

Relevant Functional Knowledge

Relevant Functional Knowledge includes the knowledge, skills and experience revolving around the technical areas you work in. For example, the understanding of what makes up a relational database including what makes it ACID compliant is knowledge. Being able to then log into a MySQL database and then using that knowledge to execute a database migration is a skill. Remembering to take a snapshot AND backup before starting the whole operation is experience (often, hard-won).

Space

Sometimes referred to as “capacity” or “bandwidth”, space is the time and energy that is available for tasks.

If we were thinking mathematically - Space is a function of Time multiplied by Energy.

Space = Time * Energy

If someone has a lot of energy but not enough time in their day to do something, they don’t have a lot of space. Conversely, someone that has a lot of time but not a lot of energy is also lackingspace.

Communication & Organizational Boundaries

Boundaries exist in any organization, and they’re not always bad. Boundaries are helpful because they clearly mark a line of change. For example, in computer networking, information is altered to be sent through network(s) according to the constraints of each of those networks and layers. I like the OSI network model - because there’s a concept of layers, and especially lower and higher networks.

Peeling back the skin on this example quite heavily: In networking - you can split communications between local networks (like a home WiFi network) and a wide area network (like the Internet). Communications within a local network are treated differently than in a wider area network. For example on a local network, clients send frames to a switch - whereas WAN networking requires packets transitting through and from routers.

Using this example, think of yourself as localhost, your team as the home WiFi network, and the rest of the org as as the Wide Area Network (like the Internet)

Interpersonal Boundary

Inside The Boundary

As a Junior Engineer, you might not have a lot of Relevant Functional Knowledge — but you do have a lot of Space to learn. As a Junior - there is slack explicitly built into the deadlines accounting for learning. This is done in exchange for the implicit expectation that you will be working hard to learn. TL:DR - You’re given a lot of space to learn.

Between you and your team is your Interpersonal Boundary.

This is the first “organizational boundary” you will learn to cross and work around as an Engineer.

Outside the Boundary

On the other side of this bounary is your immediate team.

A good exercise here is to examine the areas of the team’s “Knowledge vs Space” box compared to yours.

• Relevant Functional Knowledge: By time-in alone, your peers will probably have more functional knowledge — or at least organization specific context.
• Space: Because every member of your team is their own person, with their own goals, deadlines and constraints - the space that they have available you only exists to a certain limit.

Put more succinctly, your team will have more knowledge than you do - however by also possessing their own constraints, your team (and anyone else) will have less space for you than you have for yourself.

Each member will also occupy their own position within the plot.

Each position will change based on the person and organization.

Engineering Managers

One unique position on the plot is your Engineering Manager (EM).

On the vertical (X) axis, they are placed on a scale because EM’s can posess a varying level of functional knowledge. Some EM’s are more technical, some less.

However, the important note is their close proximity to you on the horizontal axis representing space.

EM’s should have the most time, or at-least space for you.

As people managers, EM’s trade functional tech work for space to lead and develop their people which includes you!

Their role includes providing (strategic) leadership, coaching, and help brokering relationships.

• If you’re stuck, they can help coach you to figure things out.
• If you’re blocked, they can use their levers to get you free - or provide you the resources to do so.
• If you don’t know what to do next, they can help you figure it out or at least point you to someone else.

Your EM is very important member of the team to keep in mind, and fostering a relationship with them is crucial for not only your daily success, but advancement as well.

Teammates - Only Have A Certain Amount of Space For You

The rest of your team will land vertically based on experience and knowledge. The time available for you usually decreases with seniority due to their workloads.

The more senior the teammates, the more knowledge they will have. However, an unfortunate, but understandable, side-effect of having more relevant functional knowledge is also a larger scope of work. A larger scope of work means less free space for you 😟

This isn’t personal, this is just a output versus capacity limit.

Even IF you had the most considerate and approachable Senior Engineer that is explicitly assigned to you as a mentor - there will come a limit to the space they can extend to you without risking an impact to their other duties and responsibilities.

Does this mean Juniors shouldn’t interact with Senior Engineers? On the flip side, does this mean that the more senior you are - the less approachable you’re allowed to be?

No!

Seniors, EM’s and organizations must MAKE formal space for Junior Engineers. In fact that is the mark, and a necessity, for any successful engineering organization in the long-term.

As a Junior though, it does mean that:

No one has to help you. They should** but in the absence of the ability to demand help, you’re workign purely on good-will. Which means it’s on you to do the leg-work to make it as easy as possible to be helped.

You should be more considerate in how you communicate with other members of your team - especially by factoring in the Relevant Functional Knowledge vs Space available.

How Does This Help Me As A Junior Engineer?

At some engineering organizations - Junior Engineers don’t have to worry about formal task scoping or grooming, and simply only need to grab a card and “take it to the finish line” after all of that planing work has already been done by more senior members.

You want to get to the finish line.

But - it’s “never a straight line to the finish”, and (especially as a Junior) it will rarely be a solo effort. You will need to work with your teammates in order to gain the answers and knowledge necessary ot complete your task.

In fact, this is one of the most common ways you will learn as a Junior Engineer.

And like any method, there are ways you can do this better.

Interaction Cost

Every interaction with another engineer occurs costs. For example:

• Time: How much time is spent not working on their original tasks.
• Context Switching: At the best case scenario: The effort needed to save and dump state before reacquiring new state to help you. Or most commonly - the cost of reacquring lost state when switching back to the original task.

And it’s true that the reality is: these costs will always exist.

An implicit agreement of team membership is accepting that interactions are necessary & encouraged.

HOWEVER - becoming a good engineer is understanding constraints and optimizing accordingly. Similarly, being a good teammate is about doing the same by being efficient in your interactions.

Efficiently Crossing the Interpersonal Boundary

By focusing on the transition between these boundaries, you can become more efficient in your interactions with teammates.

1. Do your DUE DILLIENCE

In the legal world, due dilligence refers to:

Reasonable steps taken by a person in order to satify a legal requirement, especially in buying or selling something.

While there might not be a legal requirement when interacting with buying- you are effectively trading information for time - the least you can do is everything in your power to ensure that the interaction is as efficient as possible.

Doing your due dilligence for an interaction is task specific, and is something you’ll get better at over time. However, here are 3 suggestions which are widely applicable to most interactions.

And remember - one of the benefits of doing this before you cross the teammate is that you have as much space as you need to work the problem. You haven’t bugged anyone yet so there is no time pressure.

Take your time. And if you feel that time is running out - work with your leadership to ask for more to figure it out.

1. 🦆 DEBUG WITH A RUBBER DUCK.

Ref: https://en.wikipedia.org/wiki/Rubber_duck_debugging

Before you run for help, go through your code / your problem - line by line, premise-by-premise. You’d be surprise how much this approach might catch something you missed, or unearth nuggets to get you unblocked.

2. 📖 Read The Freakin’ Manual (RTFM)

Something that gets old quick when you help other people - is if they keep leaning on you without trying to help themselves first. As a knowledge worker, your job is solely focused on interacting with information until it can be used / modified to be useful.

One perk of being a knowledge worker is that you are usually provided with a link to the Internet. Make sure you make good use of it. Do the leg work to do your research before asking your question (as much as you can) instead of relying on your helper to do it for you.

3. ✍️ REFINE your Ask - Organize Your Thoughts In Logical Order & Prep Question

“Even if you’re an engineer, you’re still in sales.”

You’re selling an opportunity to get helped, and you want to make sure you do everything you can in your interaction for your recipient to “buy” the opportunity to help you.

You do this by making sure your sales pitch is tight as it can be.

• Is your pitch in logical order? For someone that might be doing something completely different when you’re asking them - does your question / story / quest flow from point to point? Make sure to tighten it up.
• Do you provide an easy on-ramp to sync understanding? When you’ve been working for a long time on a specific problem, it’s easy to get “in the weeds” and forget how much context you’ve built up. When pitching to someone, it’s important to focus on providing an “on-ramp” to go from 0 → 1. Start by providing information that is generalized and simple before moving → to more specific and complex.
• Can you execute your pitch in one-go? HAVE YOU PRACTISED? If you’re selling door-to-door, it’s show-time as soon as you ring that doorbell. Similarly, the moment you send that message - you’re on. Practice your pitch thoroughly so as to reduce the time spent clarifying things on the call.

As an example:

I need help! I can’t figure out how to deploy to Staging

is not as great as:

Hey can you help me figure out why I can’t deploy this to Staging? I read the doc on CI/CD [Ref: Link] and kicked off the pipeline but I seem to be getting this weird 401 error? I read up on that error and it looks like it might be a permissions issue? Do I need to get access to something else?

More on this in “Crafting your Message” later on.

---

Once you’ve done your Due Dilligence, it’s time to:

Determine Recipient(s) & Method of Delivery

Who Do I Talk To? Decision Math

Hey the Tech Lead wrote the CI/CD pipelines right? Can’t I just go to them with this question?

Sure, but by that logic - they probably also have knowledge about most things on the team.

What happens if everyone goes to the Tech Lead all the time? That’s not sustainable.

A considerate team member takes into consideration the impact on others in relation to the time sensitive and urgency of their requests. Just because you can DM someone that probably knows the answer, doesn’t mean you should. Especially in the presence of other options.

Instead, this is where it’s important to do some Decision Math in determining who you talk to.

To make this decision, you should factor in 3 considerations:

• Least Impact - Your should aim to pick the person on your team that will be the least impacted by your interruption; But
• Best Answer - You should also aim to pick someone that’s probably going to have knowledge on the relevant subject matter. However, at the end of the day;
• Quickest Resolution - You need to ensure you ask someone that will be able to give you a timely excuse

For example, if you have a quesiton about your CI/CD pipeline the Decision Math could go like this:

The problem is around CI/CD pipelines.

• Best Answer: This is a problem that the whole team has dealt with. (So anyone could answer this - but you should pick the peer engineer because they are the next lowest level available)
• Time Sensitivity: You need to figure this out so that you can deploy the changes to finish your card. But this isn’t due till end of week and it’s a Monday.
• Least Impact: Based on the two details above - I can speak to any of the engineers on my team. However I know that my peer engineer is busy pairing with the Tech Lead right now so they’re both busy.

Therefore: I’ll ask my Senior Engineer so that it’s the least disruptive to the team, probably going to give me the right answer and in the fastest manner.

HOWEVER if you have a dedicated resource (i.e. a “technical mentor” or “big-sib” or “new-hire buddy” go to them first. They are primed and are known to expect you.

For all this talk about who to talk to though, I suggest the following options in escalating up to the next level if one isn’t successful.

1. Ask in the Team Chat

The team chat is the hub that all members work around. In teams with healthy communication cultures - this chatroom should be very active.

Messaging in the chat room has the benefits of getting more eyes and ears on the question / request and information contained within. Even if it doesn’t help you or the reader directly at that moment - makes it available for querying and recall by the broader group. It also increases communication and collaboration.

Want an easy way to reduce knowledge silo-ing and single points of failure?

Leave more breadcrumbs in an easily accessible and frequently monitored space.

Pro’s

1. Best Effort, Help Invited- Not tagging anyone specifically means that whomever has the answer, guidance or suggestions can help you based on their constraints (time, energy).
2. Knowledge Sharing - Putting it in the team chat means that knowledge is shared. DM's are death.

Con’s

1. Not tagging a specific recipient means that there is a lower pressure to respond. If your team does not have a respecful communications / collaboration culture - your question might be ignored.
2. The open arena for communications might lead to more drawn out conversations. (Bike-shedding, yak-shaving).

If your message is ignored; I would then try to;

2. Ask in the Team Chat - With Targeting or Time Pressure

Same as above but with either a direct CC, direct @ tag or a deadline.

Pro’s

Same as before +

1. Might get a response from someone that missed the message earlier.
2. Encourages people to respond

Con’s

1. Doing this excessively could annoy your teammates and lose the good-will / patience to help you.

Finally, if that doesn’t work;

3. Ask an Expert Directly via DM

If time is of the essence, go direct to someone. Someone who's guaranteed to know the answer. OR - if the right person isn't clear, ask your EM.

Pro’s

• Fastest response.

Con’s

• “Death by DM’s” - Communications energy drain for the recipient having to check on a channel that they weren’t already monitoring.
• “Death in DM’s” - Information is now siloed between you and the requestor.

---

3. Craft Your Message

Now that you know where / who you’re going to interact with for your question & help - it’s time to craft your message. Remember, this is your sales pitch where you’re selling your teammates on the chance to help you - make it as tight as possible.

Some things to consider when crafting your message:

1. What are their constraints?
   1. How much time do they have for me?
      1. How much information can I strip out (without losing message integrity)
   2. How much knowledge / context do they have about the questions I’m inquiring about? (Is this something they work in daily?)
      1. How much information do I need to fill them in on?
2. What sort of follow-up questions might they ask?
   1. Can I incorporate these into the question so that they don’t need to ask them?

This is where I recommend reading more into a previous post I’ve included around the “5 Step Question”: https://tratnayake.dev/asking-better-questions-as-a-junior

After you’ve done all that - you’re good to send!

---

Conclusion

If you do all of this, your journey might look like this:

If you take the care to understand the Interpersonal Boundary and what it takes to be deliberate, considerate and efficient in your transitions going to your team - you’ll get better answers, be less of a burden on your team and more importantly - practice the skills and habits that will be essential further on in your career as a more senior engineer, when you will need to cross multiple organizational boundaries.