Search for a command to run...
How to Get Better Answers And Be A More Considerate Team Member
I'm a developer from Vancouver, BC who's had an interesting journey in tech starting from support, through cloud infrastructure and project management. Currently I work as an SRE at lightstep helping build and "operationalize" things that helps to guide others towards better o11y :)
No comments yet. Be the first to comment.
How a quotable movie from the 90's drove me to build our internal support & success tooling.
How Terraform's setunion() disregards ordering.
How using a table during the planning step could have saved a lot of headache.
A practical guide in using Bash to solve a real-world problem with examples.
This week I've been finishing up a task that involves updating our CI/CD pipeline to make use of a feature available in the newest release of the Open Telemetry Collector to validate configuration files. In doing so, I got a chance to get up close an...
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:
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.
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 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).
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.
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)
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.
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.
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.
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.
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.
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.
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.
Every interaction with another engineer occurs costs. For example:
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.
By focusing on the transition between these boundaries, you can become more efficient in your interactions with teammates.
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.
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.
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.
“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.
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
401error? 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:
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:
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.
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.
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
Con’s
If your message is ignored; I would then try to;
Same as above but with either a direct CC, direct @ tag or a deadline.
Pro’s
Same as before +
Con’s
Finally, if that doesn’t work;
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
Con’s
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:
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!
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.
