It's all about culture
Disclaimer: This blog post has been completely written without the help of AI :)
I have worked the past two years at JPMC. Don’t worry, nothing I write in this blog post is directly related to my work at JPMC. I am merely sharing some general learnings, for once, to remind me in a few years time, and second, because it might help others.
I am leaving JPMC
It’s time to move on but this blog post isn't about that. This blog post is about company and engineering culture.
So why do I feel I know something that other's don't?
People usually think I don’t have much work experience since I am a mid level engineer. I worked for 3 years in the blockchain space, then changed industry to work with cloud native infrastructure. I was a Developer Advocate for open source projects for 5 years and a Platform Engineer for 3.
Now that we have established that I might have more work experience than people think – the reason why I am sharing this blog is because I had the chance to work at lots of different companies over the past years – and many seem to still have lots of room for improvement when we are talking about company culture.
In this blog post, I am sharing my non-technical learnings from the past years. I am sure I could have expanded the list but then you would likely not have the time to read it all. Enjoy.
To the leaders and managers
If you don’t listen and act, people will leave.
The best people will voice their disagreement or discomfort long before they decide to take opportunities elsewhere. It is your job to listen and act. This doesn’t mean that it is your responsibility to fix whatever people are in disagreement with. However, it is your job to provide people with a path forward to improve their work environment.
Similarly, if you are an individual contributor inside a larger team who doesn’t like certain ways of working: Take initiative. Propose solutions. Usually, once people provide a starting point and suggestions others will feel empowered to contribute and help to improve the status quo.
Hire people who set examples
The top leaders, principal engineers, team leads and senior engineers have to embody the culture that you want others to live by. If you don’t set examples, some people will do whatever they interpret to be the easiest or best approach, which will often not align with the goals you have in mind.
This is similar when building open source communities. You cannot expect everyone in the community, new and old, to automatically align with the mission of your project. Instead, you build a close circle of super contributors/community champions who showcase what the project is all about and rally others around those shared goals.
The larger the team, the more difficult it is to align everyone around shared practices. This is a given. In smaller teams, you take extra caution during the hiring process (or so I hope) to hire people who support practices you deem objectively “good”. An example would be, “we want to hire people who take initiative to mentor others and build a collaborative work environment” as opposed to hiring people who only work for their interest.
In comparison, larger teams require more planning. Work practices and culture branch into different directions if no direction is set. Thus, you need to set guidelines and write those down. An example of the things you should agree on is how teams will collaborate with each other and what expectations are set within individual teams.
On the technical side – you cannot implement models and frameworks half way and expect results
I have come across some really interesting frameworks and models for collaborating and working together. Many of those have been shared with me over the past years. On paper, they sound great, they make sense, the cause and effect is analysed, goals are set, and people know what they should aim for when implementing either of those strategies.
Usually, models want to enforce standards and set expectations. The issue is if these are not communicated clearly, people will fill the gaps between what is expected and what is done to make the model work for their situation or use case. Half implemented frameworks don’t work properly, cause frustration, lead to unclear expectations and create friction between teams.
The following quote summaries what I am trying to tell you:
"A task half-done is a task not done at all."
What works at large, praised orgs doesn’t automatically work in your team
I think I have developed a grudge against the process of someone being hired from a large FAANG and thinking “oh, xyz worked so well here at `Meta`, let’s implement the same thing at this new place” without giving much thought on the current structure and issues at this `new` place. This is a very short sighted attitude.
Large FAANGs, and other well structured large companies, have usually invested years or even decades in building a certain work culture. I have never worked at AWS but my husband is a Principle Engineer at AWS and I am 99% certain that no matter how good the work practices of docs writing are at AWS, you cannot set the same expectation and expect the same outcomes at other organisations. Instead, you have to put in the work first to shift or align the culture with new expectations.
Let me give you the following example: Promotions that are given based on promotion documents that showcase results of one’s work and actions. This sounds great in practice. However, if I tell you the team does not have a unified way of measuring anything, how do you take someone’s explanations on the impact of their work at face value? You cannot. You will interpret how important someone’s initiative was based on how important you, the manager or person in the promotion committee, think they were. This is not necessarily representative of how impactful someone’s work actually was.
So without you implementing ways to measure input, process, and result, you cannot implement processes that build upon having those systems in place.
Of course, this is very counter intuitive for those who come over from a FAANG and have to implement improvements and showcase their value. However, I stop here, you likely get the gist of it and this topic can become its own blog post.
To the colleagues
Know when to speak up and know when to be quite
I am a woman in tech. I don’t make my persona about that. However, we have to acknowledge that the majority of people I work with are men – and I had the chance to work with some amazing men who supported my career growth. So, let me start with, no one says “it’s all men”. However, the behaviour described below is genuinely more likely to be linked to men.
Know when to speak up. There are multiple situations that are completely valid to speak up and try your best to be heard – such as when you disagree with a technical implementation, you have security concerns or just want to voice and discuss alternative implementation. Great, speak up and have a healthy discussion.
To provide another example, when you see a colleague or more junior engineer do something that can be improved, I totally expect you to start a conversation. You are an engineer, you are not a machine, you are expected to collaborate and mentor others.
The sad thing is that as a woman, many men are often too worried to point out areas for improvement in our work because they don’t want to come across as rude or mansplaining the topic. (Or maybe many senior engineers just don’t care enough to put in the effort to mentor women but let’s focus on the former assumption.) There is nothing wrong with going over to your colleague to say “Hey, I have seen your PR on XYZ. Could you please walk me through it to better understand your reasoning? I might have a few suggestions to improve it and would like to walk you through them.”
You are in a team, you are expected to collaborate. There is nothing rude about going over to your colleague to offer your support. First, you are giving them a chance to explain, then you set your intentions, you tell them upfront that you would like to make suggestions to HELP them to improve THEIR work and you intend to explain to them why and how.
Know when to be quiet
There are situations when you have to practice to just be patient, to wait and listen before jumping in with whatever you think is best. This can be during a meeting. Assume the best case scenario and your colleague who is leading the meeting has come prepared. Maybe a question that you would like to have answered is on your colleagues list to ask later. Don’t jump in and steal the show just because you think you can. If your question is not being answered or something needs clarification during the current discussion, respectfully say “If I may add” or “great explanation, we also want to make sure we consider XYZ”. This shows that you don’t devalue their work but you add to their efforts.
Other times you might be asked a technical question from someone else or your manager on a topic that you haven't directly worked on. I am sure you can provide a great answer. However, what many people don’t realise is that they are stealing an opportunity to showcase competency from someone else by answering for them. Instead, just say that it is not your current area of focus and that you are sure person XYZ can answer. Alternatively, in a discussion, you may say that you have your thoughts and ideas but you would like to hear from person XYZ first. This gives others an opportunity to speak up and be seen.
If you are concerned about your own credibility and the way you portray your own knowledge, you can always add that you are happy to contribute if any concerns or questions are left open.
To other women in Platform Engineering
My direct team has always been men. My team lead was always a man. I never worked directly with senior engineers who were also women. That’s the norm in tech. I wish more men would help upskill women. I wish more (structured) opportunities would be given to the women in the team like going to workshops and conferences. (If you wonder why, one basic reason is that men access far more unstructured opportunities such as mentorship from peers. At least for structured upskilling and similar opportunities women in the team should be considered first. Unless you are 1000% sure that women have been offered exactly the same or more opportunities, a team lead should always approach the women in the team first on structured learning.)
So my advice to you is: Speak up. Ask to be assigned a mentor. If you cannot collaborate with that mentor for whatever reason, ask for another mentor. Ask people for input whenever you can but keep your expectations low as most people are too busy with their own work to provide you with valuable feedback. When someone is mansplaining to you, interrupt them and make it clear you already well know what they are trying to explain and point them to the part you are less sure about or you would like their support with.
Document everything.
Even when I documented all my delivered tasks at previous roles, I was still questioned by managers over my work and the value I provide. I haven't seen similar scrutiny on male colleagues. If you don’t have anything documented, you don’t have any data points to go by when you ask for promotions (or to justify your value in the company).
Say no to glue work
Glue work is expected of women – it is usually not work that gets promoted but work that you are expected to do over your male peers. Men are more likely to access promotions without contributing to documentation, culture, planning or similar – even though it is work I would completely expect any capable senior engineer to contribute to. So my advice is to be very intentional on the type and the amount of glue work you take on.
Be loud
Repeat the work you have been doing and you are doing – show off. Some people won’t like it but they will remember you for it.
Women are more likely to be measured against the work already done than their potential to perform certain tasks. At least make sure everyone knows how much you have already delivered.
Remember – women are heard but they are often not listened to. You need to find ways to make the others in your team listen.
Above all -- keep learning. Look up whatever you are unsure about or you don’t understand. There is no reason not to learn something you come across at your work. My advice is to selfishly take the time to keep learning.
Final Thoughts
A lot of the concepts shared here seem to be a given. You think that people know how to handle these situations, how to lead and add value to a team, organisation and their colleagues. However, a lot of these scenarios require a level of self awareness and reflection that many don’t proactively practice. Thus, you can never point it out enough.
