I will refrain from passing judgment on the decision itself, but given the project’s architecture, I suspect it is a costly one. Here are some reasons why:
- It severely hampers my ability to debug, troubleshoot, reverse-engineer, scope, reproduce, and isolate issues—essential functions in QE. - Additional layers of communication are now required to manage shared resources, which translates into time wasted asking developers to check things in the codebase. - Given our continuous integration pipeline, testing pull requests will now necessitate either competing for limited resources or sinking thousands of dollars annually into securing my own dedicated testing environment. - Front-end deployments take about 10 minutes; the back-end, 40 minutes. - When our CI pipeline breaks down, there are no backup methods for testing.
Thus, the question arises: why would a company, explicitly aiming to reduce expenses, introduce what seems like an arbitrary increase in operational costs? I don't believe they would, at least not without reason. Below are some additional breadcrumbs that might help in contextualizing this decision. To maintain confidentiality for both myself and the company, I’ve deliberately omitted identifying details, though it would likely be transparent to any colleague who reads this. This is not driven by any malicious intent, nor do I believe anything expressed here is defamatory. On the contrary, my aim is to clarify the situation, assess my understanding, and solicit broader input to better inform my decisions and prepare for possible outcomes. I acknowledge that, by omitting certain specifics, I may risk an incomplete representation of the scenario—but for now, it should suffice to provide enough of a framework for discussion.
{MOVED TO COMMENTS}
The question remains: Why was this decision made? Is it:
A. A misguided perception on my part—this is standard procedure and nothing unusual. B. A decision made by someone lacking technical knowledge. C. An early sign the company is preparing to let me go. D. A precaution because the company perceives me as a cybersecurity risk. E. Some combination of the above. F. Another reason entirely.
Any and all thoughts, suggestions, and comments are welcome and greatly appreciated.
From the details you do provide, I can see how a non-tech person would interpret many of your actions as "concerning".
But the key issue remains: Do you have a technically competent CTO you directly report to? If so, that person should be responsible for resolving your issue. On the other hand, if you have a tech team without a competent technical manager overseeing operations, then things are likely to get screwy from time to time. Misguided attempts at cost saving being just one of many.
I view it vastly more likely that this isn't anything personal, it's just a new corporate decision to limit who has access to the code. If someone's job is a bit more complicated, but they can still do their work, while the company is far more protected, that is a good trade-off for lots of folks.
Also, your company "looking to reduce expenses" doesn't mean anything. Every company is. You will hear that, in some form or another, in almost any organization. If they have to increase spend for cybersecurity, they will.
TL;DR If due to policy changes and my concerns are valid, do I pursue raising my concerns to leadership?
When I do a release as a dev, I don't do it myself: someone in another country presses the buttons I ask them to press, type the linux commands I ask them to type, and accept my answer when I say it looks good. Because I am, and all my colleagues are, considered a security risk, and it's better we dictate everything to someone who has no idea what we're releasing, for security reason. We call that segregation in duty, instead of "complete waste of time".
1. I’ve been asked to keep my camera on in most meetings. 2. Like many in the tech world, I generally prefer to keep it off. 3. I was pulled aside over concerns that my LinkedIn profile "looked suspicious." 4. Admittedly, my LinkedIn does look suspicious to anyone who doesn’t communicate with me regularly or hasn't met me recently. 5. As with many developers, I place a premium on privacy, and some of my actions to safeguard it might appear suspect. 6. I’m involved in the cybersecurity community, participating in conferences and learning platforms. 7. The individual who asked me to remove the repository is non-technical. 8. The company I work for is not a tech company. 9. My direct supervisors and decision-makers are also non-technical. 10. I maintain strong relationships with technical team members. 11. I’ve had difficulties navigating remote work dynamics with non-technical colleagues. 12. I speak up less than I used to—this could be interpreted as disengagement. 13. In the past, I struggled to make measurable progress or explain setbacks, which hasn’t reflected well on me. 14. I’ve made no secret of the fact that Quality Engineering is not my passion, preferring development work instead—a comment that’s occasionally thrown back at me: "I know you’d rather be doing X, but..." 15. I have fewer than 10 years of experience in the industry and appear quite young. 16. I’ve been with the company for several years. 17. I work remotely. 18. I attempted to explain our CI/CD pipelines, the importance of QE, and why I believe I need access to the repo.
People don't realise quite how much communication is done through body language.
OP - what privacy concerns do you have using a webcam with colleagues? Functionality like blurring backgrounds and having "wallpaper" via software is very good these days.
I'd say that yes - video gives more info and context. But that additional info is not required for effective communication. And it can really lag people with slower internet connections, which makes it more difficult for the conversations to go smoothly. I'd rather have a lag-free voice conversation any day.
Your point about body language is well-taken, but it’s crucial to recognize that much of human communication is rooted in biological signals that webcams simply cannot capture. These include oscillatory patterns in our nervous systems, pheromones, and pupil dilation—subtle cues that are crucial for face-to-face interactions but are lost in digital communication. If we find ourselves overly concerned about body language in pixelated, compressed, and inherently artificial digital formats, we might need to reconsider if remote work is suitable for us.
Moreover, it’s important to acknowledge that not everyone interprets social cues in the same way. Neurodivergent individuals, for example, may struggle more with deciphering body language, suggesting that the capacity to do so is not universal but rather a privilege.
Have you had a chance to watch We Live in Public? This documentary delves into an early internet experiment where constant surveillance led to significant stress and self-censorship among participants. Though not a direct analogue to virtual meetings, the film highlights the psychological toll of persistent observation—a toll that does not necessarily foster better communication or collaboration.
In my own experience, I've worked with several developers who prefer to keep their cameras off, and I've observed no detrimental impact on the quality of their work or on team dynamics. If you've noticed that developers who disable their cameras tend to be problematic, it might be worth revisiting hiring practices to ensure they align more closely with the diverse preferences and needs of tech talent.
As for my personal preference to keep the camera off, I prefer not to share too many details, but I've included links to several studies that discuss the broader implications of webcam use along with a more recent study about a potential camera alternative, biosignal data.
- https://ieeexplore.ieee.org/document/10599432 - https://psycnet.apa.org/buy/2021-77825-003 - https://tmb.apaopen.org/pub/nonverbal-overload/release/2 - https://www.tandfonline.com/doi/full/10.1080/13678868.2022.2... - https://www.mdpi.com/2673-8104/3/1/10
They knew I have different skills on electronics and hacking. I'm sure they looked for mics and cameras literally everywhere. Once I took care of a stalker that called my wife by hacking a political reporter's email and planting his phone number, so I didn't waste time with the police. Telling stories doesn't help, it's better to hide certain skills.
"It's better to hide certain skills."
This perspective hadn't occurred to me, and it's likely a more pragmatic approach than my own, which is to sing my interests from the rooftops and scribble them in chalk, hoping to find other like-minded individuals. A paradoxical approach, driven by the harsh effects of loneliness on well-being, one that might need reconsideration.
They think you're a poor performer in your assigned role and it's because you're too interested in the code. They assume you can do the job if they remove the distraction.
Or:
Your manager knows you want to go over to software engineering and if you appear to know and understand the codebase you could be poached to the other team.
Either way it looks like your manager wants you to fit the role you have been given and to stay there. The anxiety about linkedin points to this. You expressed preferences to be doing something else. You're a flight risk and they are trying to limit your options.
Edit in some unsolicited advice:
You don't need to quit over this but you should quit your job if it's not leading you to where you want your career to be, which it obviously isn't. The first 10 years of experience sets you up for your career beyond that and if it's going in a direction you don't enjoy you're going to be miserable in your job. Find a development job if that's where you want your career to go, there is no time to waste.
If you can trace it to a particular unusual customer, be vocal about the consequences. If it is due to regulations, sorry, there is nothing you can do. Otherwise, if there is no external reason for the "security" tightening, complain to the person who made this wrong decision and to his manager.
In any case, giving you the tools that are necessary for your work (and by "work", I mean not just being a glorified messenger), like a separate test environment, must be a priority for your manager, even if those tools cost 100000 USD.
Who does a QE like you report to - the same EM as for SWEs or a separate Manager for QE?
At first glance, I'd assume they most likely want to restrict code access only to those who directly make code changes. This is a common hardening tactic after Snowflake's meltdown due to QEs in Ukraine getting hacked, and then moving laterally into customer environments.
It's likely they have some processes working their way through their system(s) now to terminate you. :(
Might be a good idea to contact your own legal counsel, and/or an employment law specialist, (etc) and definitely start heavily looking for employment elsewhere (depending on your savings and personal runway).
The idea of having them around for help with severance negotiations sounds potentially worthwhile too. That hadn't occurred to me. :)
Not as a complain but to genuinely ask why these things may have happened and how it is making your job challenging, furthermore how it is also making you feel that you are being siloed.
You aren't going to get a solid answer here, but only from the people you work for.
Hope all goes well, sometimes management make strange decisions without discussing it with people