Skip to content

GitLab

Commit 8d09e495 authored by Jamie Tanna's avatar Jamie Tanna
Browse files
Options

Replace "replies" with posts 

It was noticed that these three event writeups weren't actually
"replies" as I'd originally said they were, but full posts which
happened to have an in-reply-to.

Closes #700.
parent b17409ed
Hide whitespace changes
Inline Side-by-side
Showing with 244 additions and 108 deletions
content/mf2/4d466773-c859-443a-b3eb-08a70dd9a25e.md deleted 100644 → 0
View file @ b17409ed
{
"properties": {
"name": [
"Women In Tech June 2019 - Negotiating For Fun And Profit"
],
"in-reply-to": [
"https://www.meetup.com/Women-In-Tech-Nottingham/events/261461207/"
],
"content": [
{
"value": "Ashley's talk was all about how to find out what you're really worth, and some top tips to make sure you're getting what you deserve.\n\nAshley spoke about how she runs a workshop all about helping negotiate for a better deal, and how difficult it can be finding your worth when comparing yourself against a London salary. Since running the workshop, she's had no one come back to say that they've had negative reactions to negotiation. But if you're in a company that you're worried it'll be held against you (asking for something reasonable) then maybe that says something about whether you should stay there.\n\nAshley's tweet the day before the event (https://twitter.com/TuffersTests/status/1136227900225708032) was used them to shape some of the talk, talking about the common worries people have with negotiation.\n\nAshley mentioned that only 20% of women attempt to negotiate salary, but the number of men is much higher. I personally have in the past, as an entitled white-ish man who's been advised in the past to try it where possible.\n\nInstead of \"trying to fix the women\", Ashley wants to fix the system - a much better idea. Ashley noted that it's been found that women will negotiate if it's *explicitly clear* that negotiation is an option.\n\nSometimes the company may just not be aware you need a raise, or some other compensation, such as pregnancy parking, because it's the first time they've been made aware of it.\n\nBecause it can be uncomfortable to talk about your performance, we had an uncomfortable activity to talk about a recent accomplishment. We learned to talk about ourselves some more - because *it's not bragging if it's a fact*! Prepping for the negotiation is important, taking notes and being ready to talk about your worth.\n\nFor the next activity, we were asked to write our salaries, and a generic job title (i.e. instead of Software Quality Engineer, I put automation tester) and threw them across the room.\n\nThis was a good exercise to make people think about how they feel about what they get paid - a few people refused to join in, and most felt very uncomfortable. I didn't share it on the night, but I was quite happy with it - as a white-ish male I already have a headstart in confidence, and I'm also very well compensated at Capital One so am fairly proud of what I earn.\n\nSome of the interesting responses were \"I need to learn to code!\" from some non-tech folks, and \"I don't want to share even with people I work with\".\n\nA number of comments were along the lines \"I'm not sure I'm worth what I'm paid\". One view was that the role is quite vague, so \"why am I being paid so much? What am I actually being paid for?\". And another comment was \"I'm not sure I should get paid that much, but other people doing the same job do, so why wouldn't I take it.\n\nIt was interesting to hear someone saying how they were happy with what they get paid, in isolation, but if they were to find that \"the guy next to me\" gets paid more, doing same role, why wouldn't that be a problem.\n\nAshley shared that in Nottingham, the average non-techn salary is £24500pa, but in tech it's £45000pa. This made a lot of people in the room be like \"oh wow, why am I being paid what I am?\" This again leads to the question - how do you know what you could get? It's all about keeping an eye on what market rate is by looking at online salary checkers, checking out jobs in your area, and asking friends, family and colleagues.\n\nWhen negotiating - remember not to panic! Take some time to think about the number, and _go away and think about it_. Do not immediately reply, and feel the urge to take whatever number it is.\n\nBut what if they say no when you negotiate? Ashley had a great tip:\n\n> Ask for the criteria that they use to make a decision\n\nThey will likely immediately panic and agree to the offer - yay! Because it was likely an opinion, lacking true reason so if they have to try and explain it they'll find it easier to rightfully buckle.\n\nBut if they still say no, you could seek a compromise, or really consider your options - is it actually just time to walk away if they won't give you what you deserve? Somewhere else will, so maybe it's worth going somewhere who will appreciate you better.\n\nAshley noted, on fear, that the physical manifestations of fear is very similar to excitement - so take it as a challenge and be excited by it!\n\nWhen having the conversation, be yourself, as the best way to convince someone you're an awesome person is to be that authentic, awesome person! It also really helps with confidence if you just be yourself.\n\nOne of the questions was \"what if it's in our contract that we can't talk about our salaries?\" Ashley replied that you need to query this with your HR department and find out what the harm would be if you discussed it. One of the ladies I sat next to spoke about how her company (in Derby) did not want her promoting any meetups because it may expose them to recruiters. Both these defences are short-sighted because if someone wants a better deal or to move on, they will.\n\nSpeaking about organisations where there are strict bands of compensation, where you aren't explicitly told you can negotiate, it's still worth a try. And if you're at the top of the band, try and find a role you can move into that has a bit more headroom.\n\nAnd obviously, money isn't everything - if you're enjoying the work, and able to live comfortably, that's the most important thing. *But* if you find out you've been underpaid for i.e. 5 years in that super enjoyable role, wouldn't you want to know? Wouldn't you want that money.\n\nThis was a great, interesting, funny, and thought provoking talk from Ashley, and I look forward to my next opportunity to negotiate!",
"html": ""
}
],
"published": [
"2019-06-08 10:56:52+0100"
],
"category": [
"events",
"wit-notts",
"negotiation"
]
},
"aliases": [
"/replies/4d466773-c859-443a-b3eb-08a70dd9a25e/",
"/mf2/4d466773-c859-443a-b3eb-08a70dd9a25e/"
],
"h": "h-entry",
"date": "2019-06-08T10:56:52+0100",
"tags": [
"events",
"wit-notts",
"negotiation"
],
"kind": "replies"
}
content/mf2/6dfae7bb-9561-439f-a4ce-18c4edff26f7.md deleted 100644 → 0
View file @ b17409ed
{
"properties": {
"name": [
".NET Notts May: Software Quality in the DevOps World"
],
"in-reply-to": [
"https://www.meetup.com/dotnetnotts/events/261020929/"
],
"content": [
{
"value": "Matteo kicked off the session by asking the audience some questions:\n\n> who has an automated build pipeline?\n\n> who quality control, that doesn't include manual steps?\n\n> what does your pipeline look like?\n\nTo this last one I mentioned about how in my team we've got a fully automated build + deployment pipeline with a number of system tests, including various key regression tests. Which seemed like a shock to most of the room, as they had mostly manual testing everywhere.\n\nBut then we started talking about \"what actually is quality\". We talked about how it's not just whether you've got all the test cases passing, or what code coverage percentage you have, but it's about whether the code is maintainable, or whether it follows good patterns. It's not just the testing, but the practices.\n\nAnd of course, we've all met people who say:\n\n> my code is perfect, it doesn't have any bugs\n\nTo which we can say that \"works != quality\".\n\nDevOps has been based upon the foundation of quality, ensuring that we can reduce cycle times and ship early and often, owning our products all the way to production. Automation is key to building the greatest value through maximum quality.\n\nWe need to be careful of what checks we do, as there is a difference between objective (i.e. cyclomatic complexity) and subjective (i.e. tabs/spaces) measures.\n\nMatteo spoke about \"two camps\" of quality:\n\n- industry standards i.e cyclomatic complexity, secure coding standards\n- team standards i.e. code style, coverage, patterns\n\nWe need to make sure that we apply quality in terms of the processes and practices, otherwise we are just adding gates that no one believes in.\n\nThis is different to i.e. fulfilling the spec, as a specification isn't just what you want. For instance, do you want something with a warranty of 1 year, or that (feels like) it's built to last a lifetime?\n\nRemember the quote:\n\n> even the best craftspeople need a helping hand\n\nInstead of thinking \"I can do it all myself\", realise that you're fallible, may have an off day, etc. Look to automating cruft and focussing on the important things.\n\nWe have a few ways to enable quality and raise the bar, with tools:\n\n- automated build pipelines\n- code quality gatherers\n- security vulnerability scanners\n - Dynamic Application Security Testing (DAST i.e. Zapp) - at runtime\n - Static Application Security Testing (SAST) - without running it\n- force your PRs to require a successful build before it can be accepted\n\nOr with practices:\n\n- peer review\n- bug bashes\n- Test Driven Development\n- secure development lifecycle\n- continuous integration (in the true sense of the term, not automated build pipelines)\n\nIt's very much recommended to embed quality checking with a tool like Sonarqube, as it provides all the goodness of linting and quality checking i.e. cyclomatic complexity. It's preferable to use SonarLint which means it is done client-side, instead of needing a connection to your server.\n\nUseful too is licensing scanning, i.e. to determine whether you're in risk of violating business rules, or at risk of violating GPL.\n\nYou should also look at security scanning, i.e. Whitesource, to help pick up on security issues in dependencies.\n\nIn the Java world, you can use Checkstyle, PMD and FindBugs which achieve similar, in the comfort of your own build process.\n\nWith Azure there are a tonne of other services to help secure your applications, such as security scanning your Azure templates to find out if you're doing anything insecure. There are also a number of other secvices in Azure you can use for locking down your security.\n\nMatteo's recommendation is:\n\n- use circuit breakers as a great way to isolate problems if i.e. a service is unexpectedly broken\n- add deployment gates, so you can only promote artefacts when they're ready\n- define patterns, and embed the quality mindsets, instead of it being a checklist that people are forced to go through",
"html": ""
}
],
"published": [
"2019-05-22 20:24:48+0100"
],
"category": [
"events",
"dotnet-notts",
"software-quality"
]
},
"aliases": [
"/replies/6dfae7bb-9561-439f-a4ce-18c4edff26f7/",
"/mf2/6dfae7bb-9561-439f-a4ce-18c4edff26f7/"
],
"h": "h-entry",
"date": "2019-05-22T20:24:48+0100",
"tags": [
"events",
"dotnet-notts",
"software-quality"
],
"kind": "replies"
}
content/mf2/e42361e4-cd9a-461a-a5f8-4175c3cdf37e.md deleted 100644 → 0
View file @ b17409ed
{
"properties": {
"name": [
"Cyber Nottingham May"
],
"in-reply-to": [
"https://www.meetup.com/Nottingham-Cyber-Capital-One/events/260280774/"
],
"content": [
{
"value": "This was the inaugural meetup for Cyber Nottingham, hosted by Capital One (my employers), but as I've always had a strong interest in Cybersecurity I definitely wanted to go.\n\nGraham Sutherland (https://twitter.com/gsuberland) took us through TLS 1.3, in terms of how we arrived here and what it brought to the table.\n\nAs a reviewer of crypto standards and an implementer of various crypto-related tools, Graham was a good person to talk through it.\n\nMost of the talk was over my head, and full of a number of acronyms and names of security attacks, but fortunately Graham also shared that there were many that he couldn't remember.\n\nGraham spoke about how in the past the community has decided that the solution for mitigating most attacks should be \"add an extension to TLS to resolve this issue\". This doesn't help because TLS is still the same overall version, and it makes it harder for others to implement libraries as they have a shifting target. Because this has mostly been tagged on, it means that there's a fair bit of tech debt associated with it that makes it much harder for maintainers.\n\nThe security community are moving to be much more forward thinking and preventative, rather playing \"whack a mole\".\n\nGraham noted that to make others adopt a new version of a thing, it has to be easy to adopt! Making it difficult means fewer people will jump at doing it - citing the Python 2/3 upgrade issues.\n\nTLS 1.3 has been planned to remove a lot of those issues; both accrued tech debt, unused features and unsafe / difficult to implement features. And as well as removing a lot of stuff, they also added more.\n\nFor instance, forward secrecy is now available for all, by default! This is because it makes key exchange ephemeral, which means that keys will be destroyed after each conversation, so unless you're _already_ actively MITMing traffic, you can't retroactively decrypt things.\n\nWe now have encrypted SNI and a few modes that will allow a Load Balancer to understand which virtual host a connection is being sent to, without having access to the underlying content of the message. In addition, certificate lookups are added, otherwise that could also leak which sites you're interacting with, even if using SNI.\n\nFinally we spoke a little about TLS Intercept Appliances (TIA) and how they're effectively broken for TLS 1.3, due to pieces like forward secrecy, as they have to do more work to keep up with it (it is possible, just much more difficult).\n\nLots of banks got together in 2016 to petition TLS 1.3 to re-add the ability to not run with forward secrecy but it was denied.\n\nThen, TIA vendors in 2018, but again got ignored, so they got together to create what they tried to call Enterprise TLS. This was blocked, so instead it is ETS, but so far has no adoption.\n\nJust a note that there are places where you would expect this to happen, as it makes it possible to perform deep packet inspection and determine if someone is trying to exfiltrate data out of your network, but can be something dangerous if that were to be attacked, as well as has privacy implications.\n\nThis was an interesting talk, although because I'm not hugely involved in the Cyber community I was definitely lacking some of the background knowledge.\n\n\n\nThe next talk from David Lodge (https://twitter.com/tautology0) was all about how we have smart locks that have been developed with dumb security, quoting the common saying:\n\n> there is no security if you have physical access\n\nDavid spoke about how we should threat model, as with other kinds of security; a lock has a sensor i.e. fingerprint/bluetooth, a charging port, the casing and a motor/mechanism, all of which can be attacked.\n\nWe went through different examples of how we could attack these locks:\n\nWhat material is it made of? Common lower-end smart locks are made of a material that has ~300 degrees melting temperature, whereas an average blowtorch burns at ~1500 degrees\n\nCan you screw the casing open?\n- can you push the locking mechanism back and unlock it?\n- can you attach a battery to the motor to unlock it?\n- are there any debug ports on the board for the device that you can attach to?\n\nIs there an Android app that we can de-obfuscate to work out any more details about how it unlocks the device?\n\nIs there an API that the lock talks to?\n- are there any ways we can sniff the traffic to pick up any helpful data i.e. the lock's key (this was a real example where sending a MAC address to the API returned a JSON response with details about the lock, including its key!!)\n- is the API suitably designed and protected i.e. with rate limiting\n\nIs there a vulnerability with the Bluetooth comms?\n- if you don't pair to the device, communications are in cleartext, so you can sniff someone else's comms\n- otherwise can you find any common patterns in the communication and see if you can interact with the lock yourself\n\nCould the charging port be attacked?\n\nCan you just break it open?\n- magnets\n- bolt cutters\n- washing machine vibrations\n\nAnd while researching this, a gem that a company responded with:\n\n> the lock is invincible to the people who do not have a screw driver\n\nThis talk pretty much confirmed my suspicions that smart locks were going to be less secure, although David mentioned that there are some vendors that are better than others, and you have to pay for quality.",
"html": ""
}
],
"published": [
"2019-05-19 16:35:24+0100"
],
"category": [
"events",
"cyber-nottingham",
"security"
]
},
"aliases": [
"/replies/e42361e4-cd9a-461a-a5f8-4175c3cdf37e/",
"/mf2/e42361e4-cd9a-461a-a5f8-4175c3cdf37e/"
],
"h": "h-entry",
"date": "2019-05-19T16:35:24+0100",
"tags": [
"events",
"cyber-nottingham",
"security"
],
"kind": "replies"
}
content/posts/2019-05-19-cyber-nottingham-may.md 0 → 100644
View file @ 8d09e495
---
title: Cyber Nottingham May
description: A writeup of the Cyber Nottingham meetup in May.
tags:
- events
- cyber-nottingham
- security
date: 2019-05-19T16:35:24+0100
license_prose: CC-BY-NC-SA-4.0
license_code: Apache-2.0
slug: cyber-nottingham-may
aliases:
- /replies/e42361e4-cd9a-461a-a5f8-4175c3cdf37e/
- /mf2/e42361e4-cd9a-461a-a5f8-4175c3cdf37e/
---
This is a writeup of <a href="https://www.meetup.com/Nottingham-Cyber-Capital-One/events/260280774/">the May Cyber Nottingham meetup</a>
This was the inaugural meetup for Cyber Nottingham, hosted by Capital One (my employers), but as I've always had a strong interest in Cybersecurity I definitely wanted to go.
# TLS 1.3
[Graham Sutherland](https://twitter.com/gsuberland) took us through TLS 1.3, in terms of how we arrived here and what it brought to the table.
As a reviewer of crypto standards and an implementer of various crypto-related tools, Graham was a good person to talk through it.
Most of the talk was over my head, and full of a number of acronyms and names of security attacks, but fortunately Graham also shared that there were many that he couldn't remember.
Graham spoke about how in the past the community has decided that the solution for mitigating most attacks should be "add an extension to TLS to resolve this issue". This doesn't help because TLS is still the same overall version, and it makes it harder for others to implement libraries as they have a shifting target. Because this has mostly been tagged on, it means that there's a fair bit of tech debt associated with it that makes it much harder for maintainers.
The security community are moving to be much more forward thinking and preventative, rather playing "whack a mole".
Graham noted that to make others adopt a new version of a thing, it has to be easy to adopt! Making it difficult means fewer people will jump at doing it - citing the Python 2/3 upgrade issues.
TLS 1.3 has been planned to remove a lot of those issues; both accrued tech debt, unused features and unsafe / difficult to implement features. And as well as removing a lot of stuff, they also added more.
For instance, forward secrecy is now available for all, by default! This is because it makes key exchange ephemeral, which means that keys will be destroyed after each conversation, so unless you're _already_ actively MITMing traffic, you can't retroactively decrypt things.
We now have encrypted SNI and a few modes that will allow a Load Balancer to understand which virtual host a connection is being sent to, without having access to the underlying content of the message. In addition, certificate lookups are added, otherwise that could also leak which sites you're interacting with, even if using SNI.
Finally we spoke a little about TLS Intercept Appliances (TIA) and how they're effectively broken for TLS 1.3, due to pieces like forward secrecy, as they have to do more work to keep up with it (it is possible, just much more difficult).
Lots of banks got together in 2016 to petition TLS 1.3 to re-add the ability to not run with forward secrecy but it was denied.
Then, TIA vendors in 2018, but again got ignored, so they got together to create what they tried to call Enterprise TLS. This was blocked, so instead it is ETS, but so far has no adoption.
Just a note that there are places where you would expect this to happen, as it makes it possible to perform deep packet inspection and determine if someone is trying to exfiltrate data out of your network, but can be something dangerous if that were to be attacked, as well as has privacy implications.
This was an interesting talk, although because I'm not hugely involved in the Cyber community I was definitely lacking some of the background knowledge.
# Smart Locks
The next talk from [David Lodge](https://twitter.com/tautology0) was all about how we have smart locks that have been developed with dumb security, quoting the common saying:
> there is no security if you have physical access
David spoke about how we should threat model, as with other kinds of security; a lock has a sensor i.e. fingerprint/bluetooth, a charging port, the casing and a motor/mechanism, all of which can be attacked.
We went through different examples of how we could attack these locks:
What material is it made of? Common lower-end smart locks are made of a material that has ~300 degrees melting temperature, whereas an average blowtorch burns at ~1500 degrees
Can you screw the casing open?
- can you push the locking mechanism back and unlock it?
- can you attach a battery to the motor to unlock it?
- are there any debug ports on the board for the device that you can attach to?
Is there an Android app that we can de-obfuscate to work out any more details about how it unlocks the device?
Is there an API that the lock talks to?
- are there any ways we can sniff the traffic to pick up any helpful data i.e. the lock's key (this was a real example where sending a MAC address to the API returned a JSON response with details about the lock, including its key!!)
- is the API suitably designed and protected i.e. with rate limiting
Is there a vulnerability with the Bluetooth comms?
- if you don't pair to the device, communications are in cleartext, so you can sniff someone else's comms
- otherwise can you find any common patterns in the communication and see if you can interact with the lock yourself
Could the charging port be attacked?
Can you just break it open?
- magnets
- bolt cutters
- washing machine vibrations
And while researching this, a gem that a company responded with:
> the lock is invincible to the people who do not have a screw driver
This talk pretty much confirmed my suspicions that smart locks were going to be less secure, although David mentioned that there are some vendors that are better than others, and you have to pay for quality.
content/posts/2019-05-22-software-quality-devops.md 0 → 100644
View file @ 8d09e495
---
title: '.NET Notts May: Software Quality in the DevOps World'
description: A writeup of Matteo's talk at .NET Notts about Software Quality and DevOps.
tags:
- events
- dotnet-notts
- software-quality
date: 2019-05-22T20:24:48+0100
license_prose: CC-BY-NC-SA-4.0
license_code: Apache-2.0
slug: software-quality-devops
aliases:
- /replies/6dfae7bb-9561-439f-a4ce-18c4edff26f7/
- /mf2/6dfae7bb-9561-439f-a4ce-18c4edff26f7/
---
This is a writeup of the <a href="https://www.meetup.com/dotnetnotts/events/261020929/" class="u-in-reply-to">.NET Notts May: Software Quality in the DevOps World</a>.
[Matteo](https://mattvsts.blogspot.com/) kicked off the session by asking the audience some questions:
> who has an automated build pipeline?
> who quality control, that doesn't include manual steps?
> what does your pipeline look like?
To this last one I mentioned about how in my team we've got a fully automated build + deployment pipeline with a number of system tests, including various key regression tests. Which seemed like a shock to most of the room, as they had mostly manual testing everywhere.
But then we started talking about "what actually is quality". We talked about how it's not just whether you've got all the test cases passing, or what code coverage percentage you have, but it's about whether the code is maintainable, or whether it follows good patterns. It's not just the testing, but the practices.
And of course, we've all met people who say:
> my code is perfect, it doesn't have any bugs
To which we can say that "works != quality".
DevOps has been based upon the foundation of quality, ensuring that we can reduce cycle times and ship early and often, owning our products all the way to production. Automation is key to building the greatest value through maximum quality.
We need to be careful of what checks we do, as there is a difference between objective (i.e. cyclomatic complexity) and subjective (i.e. tabs/spaces) measures.
Matteo spoke about "two camps" of quality:
- industry standards i.e cyclomatic complexity, secure coding standards
- team standards i.e. code style, coverage, patterns
We need to make sure that we apply quality in terms of the processes and practices, otherwise we are just adding gates that no one believes in.
This is different to i.e. fulfilling the spec, as a specification isn't just what you want. For instance, do you want something with a warranty of 1 year, or that (feels like) it's built to last a lifetime?
Remember the quote:
> even the best craftspeople need a helping hand
Instead of thinking "I can do it all myself", realise that you're fallible, may have an off day, etc. Look to automating cruft and focussing on the important things.
We have a few ways to enable quality and raise the bar, with tools:
- automated build pipelines
- code quality gatherers
- security vulnerability scanners
- Dynamic Application Security Testing (DAST i.e. Zapp) - at runtime
- Static Application Security Testing (SAST) - without running it
- force your PRs to require a successful build before it can be accepted
Or with practices:
- peer review
- bug bashes
- Test Driven Development
- secure development lifecycle
- continuous integration (in the true sense of the term, not automated build pipelines)
It's very much recommended to embed quality checking with a tool like Sonarqube, as it provides all the goodness of linting and quality checking i.e. cyclomatic complexity. It's preferable to use SonarLint which means it is done client-side, instead of needing a connection to your server.
Useful too is licensing scanning, i.e. to determine whether you're in risk of violating business rules, or at risk of violating GPL.
You should also look at security scanning, i.e. Whitesource, to help pick up on security issues in dependencies.
In the Java world, you can use Checkstyle, PMD and FindBugs which achieve similar, in the comfort of your own build process.
With Azure there are a tonne of other services to help secure your applications, such as security scanning your Azure templates to find out if you're doing anything insecure. There are also a number of other secvices in Azure you can use for locking down your security.
Matteo's recommendation is:
- use circuit breakers as a great way to isolate problems if i.e. a service is unexpectedly broken
- add deployment gates, so you can only promote artefacts when they're ready
- define patterns, and embed the quality mindsets, instead of it being a checklist that people are forced to go through
content/posts/2019-06-08-negotiating-fun-profit.md 0 → 100644
View file @ 8d09e495
---
title: Women In Tech June 2019 - Negotiating For Fun And Profit
description: A writeup of Ashley's talk at Women In Tech June about how to negotiate for a fairer deal.
tags:
- events
- wit-notts
- negotiation
date: 2019-06-08T10:56:52+0100
license_prose: CC-BY-NC-SA-4.0
license_code: Apache-2.0
slug: negotiating-fun-profit
aliases:
- /replies/4d466773-c859-443a-b3eb-08a70dd9a25e/
- /mf2/4d466773-c859-443a-b3eb-08a70dd9a25e/
---
This is a writeup of <a href="https://www.meetup.com/Women-In-Tech-Nottingham/events/261461207/" class="u-in-reply-to">Women In Tech June 2019 - Negotiating For Fun And Profit</a>.
[Ashley](https://twitter.com/TuffersTests)'s talk was all about how to find out what you're really worth, and some top tips to make sure you're getting what you deserve.
Ashley spoke about how she runs a workshop all about helping negotiate for a better deal, and how difficult it can be finding your worth when comparing yourself against a London salary. Since running the workshop, she's had no one come back to say that they've had negative reactions to negotiation. But if you're in a company that you're worried it'll be held against you (asking for something reasonable) then maybe that says something about whether you should stay there.
[Ashley's tweet the day before the event](https://twitter.com/TuffersTests/status/1136227900225708032) was used them to shape some of the talk, talking about the common worries people have with negotiation.
Ashley mentioned that only 20% of women attempt to negotiate salary, but the number of men is much higher. I personally have in the past, as an entitled white-ish man who's been advised in the past to try it where possible.
Instead of "trying to fix the women", Ashley wants to fix the system - a much better idea. Ashley noted that it's been found that women will negotiate if it's *explicitly clear* that negotiation is an option.
Sometimes the company may just not be aware you need a raise, or some other compensation, such as pregnancy parking, because it's the first time they've been made aware of it.
Because it can be uncomfortable to talk about your performance, we had an uncomfortable activity to talk about a recent accomplishment. We learned to talk about ourselves some more - because *it's not bragging if it's a fact*! Prepping for the negotiation is important, taking notes and being ready to talk about your worth.
For the next activity, we were asked to write our salaries, and a generic job title (i.e. instead of Software Quality Engineer, I put automation tester) and threw them across the room.
This was a good exercise to make people think about how they feel about what they get paid - a few people refused to join in, and most felt very uncomfortable. I didn't share it on the night, but I was quite happy with it - as a white-ish male I already have a headstart in confidence, and I'm also very well compensated at Capital One so am fairly proud of what I earn.
Some of the interesting responses were "I need to learn to code!" from some non-tech folks, and "I don't want to share even with people I work with".
A number of comments were along the lines "I'm not sure I'm worth what I'm paid". One view was that the role is quite vague, so "why am I being paid so much? What am I actually being paid for?". And another comment was "I'm not sure I should get paid that much, but other people doing the same job do, so why wouldn't I take it.
It was interesting to hear someone saying how they were happy with what they get paid, in isolation, but if they were to find that "the guy next to me" gets paid more, doing same role, why wouldn't that be a problem.
Ashley shared that in Nottingham, the average non-techn salary is £24500pa, but in tech it's £45000pa. This made a lot of people in the room be like "oh wow, why am I being paid what I am?" This again leads to the question - how do you know what you could get? It's all about keeping an eye on what market rate is by looking at online salary checkers, checking out jobs in your area, and asking friends, family and colleagues.
When negotiating - remember not to panic! Take some time to think about the number, and _go away and think about it_. Do not immediately reply, and feel the urge to take whatever number it is.
But what if they say no when you negotiate? Ashley had a great tip:
> Ask for the criteria that they use to make a decision
They will likely immediately panic and agree to the offer - yay! Because it was likely an opinion, lacking true reason so if they have to try and explain it they'll find it easier to rightfully buckle.
But if they still say no, you could seek a compromise, or really consider your options - is it actually just time to walk away if they won't give you what you deserve? Somewhere else will, so maybe it's worth going somewhere who will appreciate you better.
Ashley noted, on fear, that the physical manifestations of fear is very similar to excitement - so take it as a challenge and be excited by it!
When having the conversation, be yourself, as the best way to convince someone you're an awesome person is to be that authentic, awesome person! It also really helps with confidence if you just be yourself.
One of the questions was "what if it's in our contract that we can't talk about our salaries?" Ashley replied that you need to query this with your HR department and find out what the harm would be if you discussed it. One of the ladies I sat next to spoke about how her company (in Derby) did not want her promoting any meetups because it may expose them to recruiters. Both these defences are short-sighted because if someone wants a better deal or to move on, they will.
Speaking about organisations where there are strict bands of compensation, where you aren't explicitly told you can negotiate, it's still worth a try. And if you're at the top of the band, try and find a role you can move into that has a bit more headroom.
And obviously, money isn't everything - if you're enjoying the work, and able to live comfortably, that's the most important thing. *But* if you find out you've been underpaid for i.e. 5 years in that super enjoyable role, wouldn't you want to know? Wouldn't you want that money.
This was a great, interesting, funny, and thought provoking talk from Ashley, and I look forward to my next opportunity to negotiate!
permalinks.yml
View file @ 8d09e495
......@@ -24,10 +24,13 @@ posts:
- https://www.jvt.me/posts/2019/06/24/indieweb-talk-oggcamp/
- https://www.jvt.me/posts/2019/06/17/explain-networking-lego/
- https://www.jvt.me/posts/2019/06/13/pretty-printing-jwt-openssl/
- https://www.jvt.me/posts/2019/06/08/negotiating-fun-profit/
- https://www.jvt.me/posts/2019/05/31/url-decode-ruby-cli/
- https://www.jvt.me/posts/2019/05/26/why-wwwjvtme/
- https://www.jvt.me/posts/2019/05/26/hugo-render/
- https://www.jvt.me/posts/2019/05/22/software-quality-devops/
- https://www.jvt.me/posts/2019/05/22/ical-events-hugo/
- https://www.jvt.me/posts/2019/05/19/cyber-nottingham-may/
- https://www.jvt.me/posts/2019/05/19/html-toggle/
- https://www.jvt.me/posts/2019/05/17/now/
- https://www.jvt.me/posts/2019/05/12/implementing-hfeed-making-content-discoverable/
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment