Cyberweekly #186 - Managing people is our job
Published on Sunday, February 27, 2022
I'm going to start this week by explaining why I'm not talking about the situation unfolding in Ukraine.
Everybody on the internet has shifted from an expert in microbiology into an expert on foreign policy in the last few days, and quite frankly, you don't need yet another amateur analyst giving his opinion on the Ukraine conflict. If you are after updates, you can visit one of the many other sites for this, such as the Institute for the study of war, Foreign Policy magazine, or capable threat intelligence companies like Recorded Future or vetted open source investigators like Bellingcat.
Just remember that in the rush to appear relevant, to drive interest in their stories, falsehoods, mistakes and assumptions can travel far faster than vetted facts can. If your organisation is in crisis mode attempting to respond to the slew of new reports and threat intel via twitter, then as Jake Williams says: "causing a self-inflicted outage responding to FUD is a bigger risk than a Russian government cyberattack"
So, what am I going to talk about this week?
In both digital, technology and security, career development through the ranks tends to come through the increased capability within a specific technical skill set. A really good analyst can be promoted to senior analyst by their ability to read, analyse and write reports. A great software engineer will become senior and even principle simply through their ability to write good code.
But when it comes to leading teams, to running projects, often the skills needed to be successful at that job are massively under-invested in until you take a senior management role. Suddenly you are being asked about spending hundreds of thousands of pounds, of investing months or years of effort, and to make decisions based on incomplete information.
This is hugely detrimental to our organisations because it means that people who get to practice the skill and art of "delivering through others", project managers, policy advisors and so on end up in all of the senior positions and we end up with some highly technical organisations and teams being led by people who do not understand the domain. Without senior leaders with an individual contributor background in the room, decisions can be made that are obviously wrong to anyone with enough technical background to tell them apart.
Of course, part of the problem is that computers are sufficiently advanced that it's really hard for non-technical people to tell the difference between the easy and the impossible. This XKCD makes that point, but interestingly, the problem given is far less of a problem today than it was when it was written!
Anyway, one of the key things that we need to do is recognise that when someone moves from individual contributor to engineering manager, CTO or cyber director, that their delivery is now focused on delivering a team that can do stuff. Sure, they care about the output of the team, and might want to set the strategy, and make product decisions, but in reality, they have to let go of a lot of that stuff, and recognise that managing the people, the budget and creating the environment for their team to be successful is now their job.
This can be extremely uncomfortable for the unprepared. We need to mentor young technologists more to make them aware of this, and we need to ensure that people go into the role prepared, eyes open, and with good mentorship to help them adjust and be successful at the role.
Of course, to bring this back full circle, this also means learning how to manage people through a crisis. That means being the stabilising force, empathising with the team, acknowledging the impact it has on them and taking action that provides stability and reassurance for them.
Our goal in all of this is to manage our people and look after them. If you do that, the products will look after themselves.
If you keep thinking of the code as “yours” after moving into management, you’ll prevent others on the team from taking ownership of it. This will be extremely demoralizing and frustrating for your team, as anyone who’s had a micromanaging boss can tell you. Igor Khoroshilov , VP of Engineering at SOCi, told me that the solution is to think differently about your role: “Your product as a manager is people. Your main goal is to scale through developing your team and setting them up for success when solving problems.”
But for many engineers, it’s not easy to make this mental shift. Making technical decisions is interesting, fun, and (for many) comfortable. Sitting back and allowing other engineers to make changes to the code that you might think are inferior to the changes you would make isn’t comfortable, but it is necessary.
If you take a management role and it turns out that it’s not for you, don’t worry. I’ve known many engineers who moved into management and then back into individual contributor roles without much resistance.
“Anyone can be a leader, even without the title,” Jefford told me. Informal leaders might be just as important to a team’s success as the manager. There are also hybrid roles (e.g., “ lead engineer ” or “ team lead ”) at many companies that come with a mix of management and hands-on responsibilities.
On the other hand, maybe you just need more mentorship, training, or coaching. Assuming there are aspects of your management role that you enjoy and feel confident in, it might be worth talking through your challenges with somebody, whether that’s a professional coach, a mentor, or just a friend with a fresh perspective.
If you’re at a large organization, you might have access to in-house management training or mentorship programs, but it’s also helpful to have objective outside resources as well. “You need someone outside of the company to talk to,” Nierenberg told me. “You have blind spots, and a coach can be a side-mirror.”
It took me at least a year to feel comfortable in my first management role, but I’m glad I stuck it out. Stepping into a management role has allowed me to make a larger impact on my company and team. Helping other engineers develop in their careers is easily as rewarding as checking in a few hundred new lines of code, and it’s opened up whole new career opportunities as well.
Good advice in here for individual contributors considering taking their first management role, or new managers realising that their life has fundamentally changed.
This complete change from the product of your work being the code or the system, to considering the product to be your team is a tough one for individual contributors to get. We don’t, in technical teams, often get a chance to experience this until someone moves into senior management, whereas for people in project management understand that they deliver through others far more readily and at far more junior levels.
If you hate it, do remember that you can move back
Throughout my career, the biggest mistake I see engineers make is doing too much work on their own before looping in others.
I’ve experienced this mistake as both an IC and a manager. As an IC, it’s a mistake I made many, many times early in my own career. As a manager, I made the mistake of not recognizing and fixing it in the engineers I’ve managed.
Correcting this habit is the most common feedback I now give, so I thought it might be good to write out how it happens and how it can be avoided.
The curse of individual contributors is that we often value the output of highly capable individuals, rather than the ability to work well with others and deliver as part of a team.
I’ve worked with some world class 20x engineers, who are amazing individual contributors. I’ve also worked with some amazing teams, where there were individual engineers who could enable everyone on the team to work like a 10x engineer.
Both have value, but we tend to reward and recognise the former far more than the latter.
Here are 3 easy steps for dealing with a crisis: Empathise – During a crisis, people will feel stressed. They will be emotional. They will be uncertain. Many will worry about what it means for them, for their job, and more. A good first step for dealing with a crisis is to recognise and show empathy for how people are feeling. Not sure how people are feeling? Ask them. Use 1-1s, email or messages in group chats to sense what the general mood is. Make sure you explicitly acknowledge how people are feeling by giving these a name. Acknowledge – The first step with dealing with a the panic people feel is to share facts. Focus on facts rather than opinions because everyone has an opinion during a crisis. They’re also often very wrong. Too many opinions conflict with each other as people pretend they are an expert. Focus on gathering facts from the source and acknowledge the source. If it’s an external event, look for an official research or scientific body. Be wary of newspapers or media, who often amplify “newsworthy” titles. Many do not fact-check. For internal events (like an incident), redirect people to dashboards or metrics that stay neutral. Be careful not to let your opinion or perspective influence this. Take Action – During a crisis, everyone asks the same questions: What happens next? What does this mean? What does this mean * _for me_ *** ? Your role as a leader is to build a clear action plan to establish some certainty. Build a credible plan with input from others (don’t do it in isolation). Communicate the plan in simple, easy to understand language. More importantly, show visible progress on the plan.
This is good advice, regardless of whether the crisis is something huge and external, or whether it’s a new strategic direction, new leadership or even just a critical person leaving the team.
After winning a story writing contest in high school, Sanderson decided to pursue the goal of becoming a professional novelist. He ended up writing thirteen novels in a row before he sold one. Looking back, he describes this as a bad goal as it was something he could not directly impact through his actions. A better focus would have been on completing a certain number of novels, each one better than the last, regardless of whether or not they sold or made him famous.
“Make goals that you have control over,” he explains.
Readers of Deep Work might recognize a similar theme in my discussion of the 4DX methodology , and its emphasis, in particular, on tracking lead instead of lag indicators. Your goal, for example, shouldn’t be to get your next academic paper accepted into a better journal, as it doesn’t specify a concrete action you can schedule and execute. A better approach might be to focus on banking 15 hours of deep work on your paper per week: this you can control, and it’s likely to influence your overall objective.
He goes on to reveal that he wishes that he had been given a more detailed roadmap when he first set out to be a writer. The experienced novelists that he asked for advice would just tell him to “write.” Better advice, he noted, would have been to setup a practice regime, centered on writing a certain number of complete manuscripts, each of expanding size and ambition, all aimed at developing his chops to the point that he’d be ready to produce something sellable.
I’m a big fan of Brandon Sanderson’s work, and he’s one of my favourite fantasy authors. But as Cal Newport points out here, he’s also a fantastically productive writer, and he has a distinct method about how he goes about it.
This focus on setting goals, and breaking them down into small chunks, each of which is executable, and each of which has some value of it’s own is the key to a productive and effective plan for life.
It doesn’t matter whether you are the most junior person in a team, or you are the chief executive, this advice on how to set realistic and actionable goals and break them down is worth picking up and giving a try
The Trimodal Nature of Software Engineering Salaries in the Netherlands and Europe - The Pragmatic Engineer
#1: Companies _only benchmarking against _their local competition and non-tech companies, competing with their local competitors. Most of these places call engineering as IT, and often view it as a cost center. Technology is not treated - or compensated - as a core competency at these companies.
#2: Companies benchmarking against _all_ local companies , even if they are not direct competitors. In the Netherlands, examples of these companies would be eBay classifieds, Adyen, Nike, Disney Streaming, and well-funded, high-growth startups like Catawiki, FindHotel, Miro, MessageBird, TripActions would also be in this category.
#3: Big Tech: companies benchmarking against _all_ regional or global companies. In Europe, this means competing against all other major EU companies, and often recruiting people from London, Berlin, Barcelona, and outside the EU. Examples of companies in this space are Uber, Booking.com, Databricks, Amazon, Flexport, Plaid, Redis Labs, Stripe, Elastic, GitLab, GitHub, Datadog, Apple, or Netflix. Trading companies like IMC Financial, Optiver, Flow Traders or Jump Trading are in this group as well. Brexit should bring a lot more positions to the Netherlands for trading firms.
Most companies tend to assume they are a tier higher than they actually are - because they have little data points that prove otherwise. Candidates keep accepting their current offers, that have not changed significantly the past years, and attrition remains as usual. However, many of these companies will be in for a surprise the coming years as the #3 category of companies hires the best talent away from #2. In turn, this will push #2 to increase compensation and equity allocation, and hire the best people from #2 and #1. And companies in #2 who do not offer meaningful equity for software engineers on top of a competitive salary will struggle to recruit anyone from #3.
This is a fascinating analysis of engineering salaries, and well worth a read if you are an engineering manager or want to hire engineers. If you work in Government, it will probably be a bit of a depressing read, as you’ll have to accept that Government is never going to give you freedom to complete with Tier 3 companies and in many cases, still considers engineering to be a cost center putting them in Tier 1
[Note: This is from July 2021]
At Dropbox, we strive to be a great place for all engineers to grow and be recognized for that growth. Our Engineering Career Framework helps keep us accountable there and is viewable by anyone within the company. Today, we are also making it viewable by anyone outside the company. Our goal in doing so is to be transparent externally on how we think about leveling and career progression on the Engineering team at Dropbox. It also enables others to adapt and apply it to their own organizations.
In early 2020, we completed a major revision to the framework. Our focus was to be more explicit about the “what” (i.e. business impact made) and create better representation for all the different crafts within engineering that make Dropbox successful. After a year of running this current version through several promotion cycles, we are satisfied that it is moving our culture in the right direction.
Dropbox’s Engineering Career Framework describes what’s expected for our engineers at each of our career levels. Along with helping managers set expectations and hold teams accountable for their work, this resource empowers engineers to achieve greater impact in their role and grow in their careers.
Transparency in the career pathway helps outsiders orient themselves, it helps people inside the organisation appropriately set feedback in the right context and it should help ensure that challenges around discrimination and bias can be clearly set against standardised and well understood central definitions.
More companies should publish this kind of framework
This is a good thread by a smart thinker, and one that I agree with a lot. Platform Engineering is the new hotness, and it’s an opportunity for security to get in on the ground floor and ensure that sensible and useful security defaults are embedded in the way things work.
But, and this is critical, the threat points out that developer experience has to win out over all the other considerations every time. The platform has to be adopted, used and liked by your developers otherwise they won’t adopt it, and the security practices embedded in it. So make the security features usable first, and secure enough second
Sometimes, though, your bets are more qualitative; you are choosing a direction that aligns with your company’s values or positions you for future success. At Netflix, we call these “strategy bets.” Here’s an example from the company’s 2018 annual report:
…self-produce and create more of [our] own content rather than license or procure it from third parties.
This formulation explicitly acknowledges two alternatives: Produce content (movies and TV shows) in-house versus buying them from outside studios. Both are reasonable, defensible choices, and it’s easy to imagine a healthy debate on this strategy.
When you’re stating a strategy, spelling out the alternatives has a couple of benefits. First, if you realize one of them is nonsense, then you know you haven’t made a decision. Suppose your strategy is “make a profit.” No one will oppose that as a business goal if the alternative is “lose money.” But if you want to dig deeper, you might say “aim to show a profit every quarter versus invest consistently in new product development.” That’s a bet worth debating. What’s more, it calls for a decision, because it fundamentally influences how a company will allocate its resources.
Lovely description of "Even over" goals that I talked about a few months back.
There's some really good points further down, in particular talking about how this kind of articulation really helps with the "disagree and commit" philosophy. It helps acknowledge that there were viewpoints, that they were good arguments, but that you've made a strategic bet and everybody needs to accept that and get with it.
Study after study continue to tout the benefits of mentorship programs.
A CNBC/SurveyMonkey Workplace Happiness Survey found that 90% of workers who have a career mentor are happy in their job. A study by Sun Microsystems found that mentees were promoted 5 times more than those who didn’t have mentors, and the benefits were even greater for the mentors — who were promoted 6 times more often than others. A Randstad study found a 49% reduction in turnover for employees who participated in mentorship. It’s impossible to deny the many benefits of mentorship.
But not all mentorships work. And one of the keys to a good mentor/mentee relationship is having consistent touchpoints.
[...] Once you’ve outlined the purpose, create an agenda with specific items to cover.
Unless otherwise discussed, it’s typically the mentee’s responsibility to put together the agenda for the meeting. Ryan Carruthers of Together Platform explains:
“Mentees need to own the relationship. Don’t expect the mentor to come to a meeting without any context and be able to deliver value to you. Consider what you want to discuss ahead of time. Send your mentor anything they need to know about the goal or idea you’d like to discuss at least 1 day—preferably 2-3 days—before you meet. This will give the mentor a chance to think it through and show up prepared.”
This is great advice on how to get the best out of a mentee/mentor relationship, and also should be good reading for those becoming mentors. Push the work to the mentee, let them decide what they want to cover, but prepare a few days in advance so you can be impactful in that relationship
What is Push Notification Spamming?
This technique is simple as it only requires the attacker to manually, or even automatically, send repeated push notifications while trying to log into the victim’s account. The credentials used could be obtained via brute forcing, password reuse or spraying. Once the attacker obtains valid credentials, they will perform the push notification spamming repeatedly until the user approves the login attempt and lets the attacker gain access to the account. This usually happens because the user is distracted or overwhelmed by the notifications and, in some cases, it can be misinterpreted as a bug or confused with other legitimate authentication requests.
This attack is particularly effective not because of the technology involved, but because it targets the human factor of MFA. Many MFA users are not familiar with this type of attack and would not understand they are approving a fraudulent notification. Others just want to make it disappear and are simply not aware of what they are doing since they approve similar notifications all the time. They can’t see through the ‘notification overload’ to spot the threat
This blog covers MFA notification spamming, which has an attacker deliberately spamming a user with MFA notifications in the hope that they will just press accept.
This is far more likely to succeed if you already prompt your user for their MFA a lot. It's often a security push to set very short, often arbitrary limits to sessions that require re-authentication. From session idle timeouts of 3 or 5 minutes, to authentication timeouts of 4 hours.
All of these "timeouts" require users, who might be authenticating on different devices, to repeatedly approve notifications, which almost certainly lowers your protection against this form of attack.
Reauthentication should only occur if the system believes that something has fundamentally changed that might increase the risk. Using a new computer, using an account from a brand new never seen location, or potentially carrying out a serious security impacting action might all require reauthentication. But idle MFA is probably too much if it's happening more often weekly or potentially daily for high risk users.
"Zero-Days" Without Incident - Compromising Angular via Expired npm Publisher Email Domains – The Hacker Blog
The TL;DR Summary & High-Level Points Developers for highly-installed npm packages had their npm accounts registered to email addresses at expired domains.
Registering these expired domain names allowed for the takeover of important npm packages such as ajv-formats which currently has ~5 million installs a week.
The ajv-formats package is a dependency of @angular-devkit/core, Angular’s core utility library. @angular-devkit/core is a dependency of @angular/cli, which is the tooling used to compile Angular apps.
Dependency security is a complex problem with risk tradeoffs that should be weighed carefully.
Developers using custom domains for their email address should seriously consider the risks they are taking on by using the email for their online accounts. If this domain expires or is hijacked, where does that leave them?
It’s unclear if npm has changed anything as a result of my report to them and npm users should likely assume that this issue could still be exploited in the future.
This is a fascinating read, and there are no good solutions to the dependency problem as it stands.
This whole thing is a good example of the sociotechnical problem space, where the problems aren't just technical, but a combination of technical and social, and therefore the solutions also need to be in both spaces.
Sadly, many of our current solutions tend to focus purely on the technical rather than on the entire space.