I'm not huge of Bryan Cantrill's often provocative tone and advice. The author links to a talk by him where Bryan deliberately misdirects the audience so he can introduce a false dichotomy about whether Software Engineering Middle Management is a toxin or a cancer. While fun if you're the kind of engineer that sneers at management I would hardly consider it a guiding post for becoming a leader.
Being a leader is hard. Being a good technical leader is harder. Programmers are like cats and their opinions are more important and refined than anyone else's. And I don't think it's sustainable to work in an environment where your every mistake or bad day will make you seem like a dipshit to your team. It can be demotivating to work under someone who has a toxic attitude problem, for sure, but it's also hard to be perfect all the time.
One thing I would add to the Humility and Empathy section is that you don't have to be all these things all the time. It's okay to have a low-energy week where you don't feel up to mentoring junior developers. It's normal to get frustrated when you review code that consistently exhibits the same patterns and bad habits you've been coaching your team out of for months. Part of building humility and empathy is creating a team where it's fine to be vulnerable: the team knows you're having an off week, that your energy is low, and they trust you that you're going to recover and bounce back from it.
Off the top of my head, these are the kinds of things engineering managers often have to deal with:
Hiring:
- Writing job specs.
- Dealing with recruiters
- Reading CVs/résumés
- Interviews
- Onboarding
- Outreach
- Who do you need to hire next quarter to avoid capacity problems?
People:
- How do you level up your developers? What new responsibilities can you delegate to them so that they can grow without swamping them? Are you available enough to them so you can help them take these new tasks on?
- Evaluating training courses / conferences etc.
- Are there any personal or interpersonal problems that need sorting?
- What can you do to help your team gel better and feel like they are part of a team?
- Where are your team members' careers heading and how can you help them get there?
- Your team has grown too large to manage effectively by yourself. How do you split things up?
Process:
- What is everybody working on? What will everybody work on next?
- What are people blocked on? How do you unblock them? What is likely to block them next?
- Can you do things in a better way? How?
- You've got a lot of bugs in the backlog. Is there a root cause? Are there any patterns?
- You aren't performing as well as you thought you were. Where is the time being spent? What's the cause? Are the estimates wrong or the performance?
- Some people want to shift their hours or work remotely. Can you accommodate this? Do you have to adjust process and if so, how?
Line management:
- Approving invoices
- Approving holidays
- One on ones
- Salary review
- Getting people back to work after sickness / parental leave / sabbaticals
- Disciplinaries / performance problems
- Firing / redundancies
- Exit interviews
Planning:
- How well is your team performing? How do you measure this and how do you improve?
- Do you have enough capacity?
- If not, which features do you bump?
- Are there any bottlenecks in the pipeline?
- What are you telling the shareholders you're delivering next quarter?
Product:
- Does marketing know what you are building next? What information do they need from you to sell it?
- Do CS know how to support your customers with the new features?
- Feedback from the rest of the business about the product and how the tech team works.
- Are the specs precise, correct, complete, and achievable?
- Features have been requested. Are they technically feasible? What's the general size of it and what quarter can we deliver it by?
- A big customer has a major problem with your product. It's not your fault, but it has a disproportionate affect on the customer. How do you prioritise solving this problem?
External:
- A shareholder owns a business with a related product that they want integrated ASAP. How do you deal with that pressure without disrupting your plan?
- One of your suppliers has a data breach that has leaked your data. How do you deal with that? Have you defined processes for reporting security issues?
- A supplier is failing to perform adequately. Can it be fixed? How do you move away? How soon? Where does the work fit into the schedule?
- A supplier has changed their pricing structure. Do you have to move? How soon? Where does the work fit into the schedule?
- New legislation has been passed and you have to make changes to your product. What are the requirements?
- A complaint has been made about the accessibility of your product. Does it have merit? What's the impact of fixing it, and how urgent is it?
- A big prospective customer is on the verge of signing, but they must have one feature that you weren't planning on building until next year. How do you rearrange things to get the customer with minimum impact?
- A service you use is changing their API. What's the risk of staying on the deprecated version until it can be planned in?
'I think there's a real reluctance to put a precise dollar figure on how far we'll go per person toward "universal coverage of everything", but that's precisely the conversation we need to be having.'
This is only a thing in the US.
In the countries with sane public health systems, they have zero problem saying "Look, we've got this much money to spend, we think this way of spending it gets the most bang (roughly speaking, QALY's) for buck, so if you want more coverage hit up the private insurance market" [1].
And you know what, those private insurance markets work great because they actually have to provide meaningful value beyond the public system in order for consumers to bother using them.
As a vaguely relevant side note: Goddam it's difficult for me not to get angry about the diabolical state of the health system in the US and I don't even live there. There should be marches on the streets about this. You could radically improve the lives of the vast majority of 300 million people without spending an extra cent of government money on health if you just stopped being so goddam dumb about it [2].
> Rule #2: Take a long hard look at a candidate’s social profiles.
Is not having a LinkedIn account going to come back to bite me, even when applying for dev roles? I've had even senior devs at popular local dev shops say LinkedIn is a "necessary evil" because it:
1. is easy to grep
2. you can find whether a candidate has similar connections to you
3. recommendations
I get New Zealand is small and the social graph for LinkedIn can be well utilised because of this but I just don't want a LinkedIn account. Is a traditional CV so bad?
Most people don't know about Innovis, which was mentioned in the article. That said, I've never run into a company where I've needed to lift an Innovis freeze. Anyway, I agree that it's tiring to constantly track which data brokers allow (are required to) adding a security freeze. In my opinion, better legislation is needed to curb this activity and data brokers in general.
For the VM, follow the same OS hardening standards you would apply in a non VPS environment. Each OS distribution has its own NIST, CIS hardening guides. Do not use pre-built images created by someone else, as you have no idea if they are tainted. Build, patch and harden the image in your own continuous build environment.
Each VPS provider have their own site specific means of locking down their API's and web consoles. Speaking in generic terms, limit API access to known trusted networks when you can. Limit the lifespan and capabilities of API keys. Rotate API keys, just as you would passwords or ssh keys. Delegate the minimum permissions required for people to do their job. Audit accounts and delegated sub-accounts. Set up multi-factor authentication for non API key logins. Set up email alerts for account changes.
In high level terms of networking, do not allow unfettered outbound access from your VM's unless there is a specific need to do so. Either set up your own traffic logging at the host level, or determine if your VPS provider have the ability to log traffic.
In terms of payment methods, use a virtual account number (virtual credit card) that is tied to that vendor and has a currency spending limit. Not all banks have this capability. Ask yours to add it. When possible, set upper limits on the number and sizes of VM's your account is authorized to create. Ask your VPS provider to add this capability if it does not exist.
Being a leader is hard. Being a good technical leader is harder. Programmers are like cats and their opinions are more important and refined than anyone else's. And I don't think it's sustainable to work in an environment where your every mistake or bad day will make you seem like a dipshit to your team. It can be demotivating to work under someone who has a toxic attitude problem, for sure, but it's also hard to be perfect all the time.
One thing I would add to the Humility and Empathy section is that you don't have to be all these things all the time. It's okay to have a low-energy week where you don't feel up to mentoring junior developers. It's normal to get frustrated when you review code that consistently exhibits the same patterns and bad habits you've been coaching your team out of for months. Part of building humility and empathy is creating a team where it's fine to be vulnerable: the team knows you're having an off week, that your energy is low, and they trust you that you're going to recover and bounce back from it.