Apple Inc. is preparing to allow alternative app stores on its iPhones and iPads, part of a sweeping overhaul aimed at complying with strict European Union requirements coming in 2024
Mark Gurman over at Bloomberg with quite the scoop if true. It’s not understating it to say that this would be a significant shift in policy from Apple, which has, since the introduction of the App Store in 2008, been the sole arbiter of what software can be installed on your iOS device.
In a former life, I was a professional iOS Developer, so I’m extremely familiar with the App Store and the somewhat opaque nature of it’s rules. I will admit that pushing software to the App Store can be an extremely frustrating process at times, and the 30% cut they take on pretty much every cent that flows through it is bordering on extortion, but nonetheless, part of me wonders if this is as consumer friendly a development as I’m sure many will hail it as.
If there’s anything people associate (thanks in part to Apple’s marketing team) with iPhone and iPad, it’s security and ease of use. And I think this is achieved in part by Apple’s monopolistic approach to iOS, so depending on the implementation of this reported policy I am somewhat concerned that it will damage these key associations in the minds of consumers, and with that the iOS App economy in the long run.
There’s a quote floating around the internet that is supposedly attributed to Steve Jobs and although I confess I don’t know if he ever said it, I like the sentiment regardless of the source. It goes something like this -
For the past 33 years, I have looked in the mirror every morning and asked myself: ‘If today were the last day of my life, would I want to do what I am about to do today? ‘ And whenever the answer has been ‘No’ for too many days in a row, I know I need to change something
As a hiring manager, I take part of dozens of interviews per month, and since I see them as a chance for a candidate to interview me as much as I’m interviewing them, I always make a point of dedicating a certain amount of time for them to ask me questions without interruption.
The questions are varied, ranging from “how does career progression work there?” to “what’s an average day for your team?”. Regardless of the question, most of the time it’s the candidate trying to assess if the job I’m offering is right for them, and that’s exactly the kind of question I think they should be asking.
But it’s important to remember that we should all have a consistent set of questions we would ask if we were interviewing for a new role, and we should ask ourselves those questions about our current job, answering as honestly we can. We should have a similarly objective way to grade the responses.
Heck, if you have a strong enough relationship with your manager, you should even feel comfortable asking them those questions from time to time.
And if you find yourself consistently not liking the answers you get, then maybe it’s time to start looking around for a new opportunity. Sometimes people stay in jobs not because they enjoy the work, or they’re growing, but because change is hard, and the path of least resistance is to just maintaining the status quo.
Changing jobs, or even careers, is not always a comfortable or easy thing to decide, and for many it’s not a luxury they might have, but if you work in technology there’s a non-zero chance that you have that level of job flexibility, and you should take it whenever makes sense, because you might not have that flexibility forever.
I can’t tell you what the right questions for you are, because everyone looks for different things from work, but you should try to figure out what makes you happy. Maybe it’s learning new things, maybe it’s having more impact, maybe it’s making enough money so you don’t have to answer to anyone again. I spoke a bit about these in the past but it’s a very personal thing, so figure out what works for you.
So my advice to you is this. Imagine you were being interviewed tomorrow. What questions would you ask of your interviewer to decide if it was the right job for you? Write them down, and write down the best possible answer. Now ask yourself those questions about your current role. If you don’t like the answers, well that’s an answer all by itself isn’t it?
Ask anyone in tech about LinkedIn, and it usually won’t be long before you hear about a constant barrage of messages from recruiters.
Truly, the best kind of spam is the one that’s constantly offering you jobs, but it still usually evokes a negative response from folks, even though I actually view them as an opportunity.
Not an opportunity for a new role though - they’re an opportunity for some market research.
The reality right now is that it’s a candidate’s market, and recruiters have targets to hit, so they’re usually willing to get into a conversation, and you should use that, even if you’re not looking because you should always try to keep up to date on the state of your industry, so you know (with data) if your current job is as ideal as you may or may not think it is.
That’s why I respond to every recruiter InMail I get, even if I’m not in the least bit interested in a job with their company/client. So what do I say to all these recruiters? Well, I find that three questions is usually enough to get what you need.
What those exact questions are will depend on you and your job, but they should fall under 3 topics
Well, compensation and other perks both relate to what you are materially getting out of the job.
Look, I love what I do, and I enjoy near enough every day I go to work, but I’m absolutely doing it primarily for the money. If I’m going to let someone else tell me how to spend a quarter of my week, then I’m going to get everything I can from them, and as valuable as experience and upskilling definitely are, my local grocery store doesn’t take those things as payment for food, so if those two topics aren’t up to scratch, there’s no point worrying about the company culture.
Assuming the perks and money side of it is well tended to, I ask about company culture because it speaks to how happy I’ll be there.
For me, here are the questions I ask for each topic.
Compensation
For compensation, I don’t go overly fancy and I think regardless of your role/industry, this question is the same. I just ask for a salary range they’re targeting. You could also ask about stock, but unless they’re a publicly traded company, stock compensation is as good as magic beans and should be treated as such. For this question, there’s usually three types of answer.
“The salary range we’re thinking is between X & Y”
This answer obviously gives me the range, but it also tells me some other things -
Is this role financially viable for me? I gotta pay the bills no matter how good the job might be.
If the range is absurdly broad, it could be a sign that they have no idea what level they’re hiring for and are just throwing numbers at the wall. They might also be full of it and the range is much lower.
If they range caps out pretty low, it’s a sign for me that it’s junior position and might not suit, or they’re undervaluing me.
“We don’t have a salary range and we build a bespoke package for each candidate”
You don’t get the range from this, but again, you can read into the answer -
This, frankly, is either not true, or the company is so mismanaged you should run a mile.
They might not have a bottom end of a range, but you can be damn sure they have a ceiling. That ceiling could be 50k under what you want, or 50k over, but you won’t know if they don’t tell you.
Even if a company is well managed, but still doesn’t have salary ranges, it means they’re not investing in their employees careers, because if they don’t have ranges, then they don’t have career ladders that are documented and are likely a minefield of bias when it comes to reviews and performance management
“We don’t share that data”
Again, no direct compensation data, but more you could imply -
Be wary of companies who won’t even talk ballpark figures, because they’re potentially trying to low ball you and/or waste your time.
Even more worrying is companies that won’t share ranges internally, because they are absolutely trying to lowball their staff.
Other benefits / perks
God there’s so many potential questions here, and it’s really a movable feast. It could be any of
What’s your 401k/pension/retirement scheme.
I don’t care what age you are, 401k/Pensions should always be on your mind
What’s your healthcare plan?
What’s your bonus structure?
Do you fly your staff business class for long haul travel?
What’s your commission structure?
What’s your remote/hybrid/office policy?
Do you provide onsite snacks/meals?
What software / hardware do you provide? Can I deviate from that?
Regardless of the question, what you’re looking for here is some kind of material benefit that isn’t immediately spendable. That could be long term compensation like savings or preferred stock purchases, or something less tangible like giving you more time to spend how you choose, or traveling comfortably.
For me, currently, I’m asking the question about remote work. Pre-COVID, I used to spend a minimum of 70 minutes per day of my own personal unpaid time traveling to/from the office. That’s about a full 24 hour day per month dedicated to my job for zero pay.
Don’t get me wrong, I love working in an office with people, bouncing ideas off each other, getting stuff done, and obviously having some fun, but damn, a literal full day a month just to get there and back?
COVID really opened my eyes to what a time sink that was, so I don’t know that I’ll ever want to do a full time office job again. But equally, I don’t want to never meet my co-workers in person, so in terms of an answer, I’m usually looking for some version of “we have an office, you can come if you want, but if you wanna work from home, that’s cool too. But we do have budget to get everyone together in-person every 6-12 weeks.”
One gotcha answer here which I’ve seen lately is “well your contract says you have to come into the office, but we don’t enforce that”. Don’t buy that for a second. The only reason a company puts something in a legally binding document is to give them the option to enforce it. This applies to so many contract clauses - if they won’t strike it off the contract, you need to assume they plan to enforce it.
Company Culture
Like I said, whilst the first two questions speak to a mix of tangible and intangible benefits (sometimes called “total compensation”). But this last one is more about your mental health. Do you think this job will make you happy. Will you operate in a creative environment, is there a lot of office politics, are you being set up for success, etc etc.
Like the “other benefits” topic, there’s a pretty wide spectrum of questions here, but to give you some examples, think about
How do promotions / career laddering work?
What’s your turnover rate?
How often do you release code?
Where in the company org chart does this team sit?
Will I be a people manager?
How many people are currently on the team?
With such a wide spectrum of questions, I can’t possibly provide insight into all the answers, but I will say that I’m currently asking about the org chart, and that’s entirely a personal preference thing. In my profession, you usually sit under engineering, product management or marketing, and I have a preference for the first two, so if DevRel sits somewhere else, that gives me pause about how happy I’ll be long term.
But for you, the question and answer could be totally different.
Remember, this too shall pass
It’s a golden age right now to be a person working in tech. Your skills are wildly in demand, and there’s a lot more of that demand than there is supply.
But as with all things, this too shall pass, which is exactly why you need to use your leverage while you have it. Maximise for whatever it is you want, be that money, happiness, influence, whatever.
Just remember, you can do this market research without being a jerk to the recruiter, so when you’re asking these questions, do it politely, and if they refuse to answer them, that’s their prerogative. They’re a person, trying to do a job, just like you.
Like many SaaS companies, the planning year at Slack runs from February to January, so we’re coming to the end of our planning process for the next 12 months.
One part of that process which is important in my role as Head of Developer Advocacy at Slack is recruiting and headcount planning. I need to make an ask for a specific number of hires, justify that, start working with recruiting to hire those people, etc etc.
As part of that, I’ve been thinking a lot about what it is that I want the team to achieve.
Obviously I need to consider what we’re doing through the lens of the company, but like any good leader, I try to consider what each individual on my team will get out of it. What skills will they learn to advance in their career, what will be transferable to other roles, other teams and more.
I think these skills could serve as a good blueprint for many small DevRel teams, so wanted to share them.
So with that, let me talk about what Slack’s Developer Advocates will be doing this year.
It’s all about the content
A big focus for us next year is massively upping our content game. More video, more blog posts, maybe some other mediums we haven’t considered yet.
Towards the latter half of 2021, we started to spin up what we’d consider mid-length videos, that is longer than 5 minutes, but less than 15.
Here’s a great example by Sandra, the most recent member of the team, who was speaking about using our App Home feature.
Whilst both of those example are very “you already know and have bought into the idea of Slack”, we also want to start producing content which is more reflective of our amazing community of developers. At the end of the day, our platform exists to help people get things done more easily in Slack, whether that’s responding to incidents, managing their projects, or most importantly bragging about your wordle score, so we want to talk about the interesting things that our community are making, and even things that aren’t related to our APIs, but can still make your life easier, like offering a look at how we plan content, or build product, or launch features.
Here’s just a few of the things we want to tackle soon.
Once more unto the in-person events, dear friends
I still think 2022 will be very heavy on digital content, but like other organisations, we’re keeping a close eye on what a return to in-person looks like, so there’ll likely be some hybrid events too.
We already have at least one major event on the books in the form of TrailblazerDX 2022 this April, but as with everything, it will depend on COVID-19 and how safely we can run an event at the multiple thousands scale.
As I say though, I don’t know that any large event will ever be 100% in-person again. Hybrid is here to stay.
One message, many mediums
But fundamentally, COVID or otherwise, I think DevRel is a multimedia discipline now, so DevRel teams should have experience / an interest in generating content across all sorts of mediums.
There are so many ways to help your community, and make your content accessible to a wide range of folks, regardless of where they’re based, or their style of learning. We’re not there yet, but we want to be a team that generates content for our whole community.
In a practical sense, I think that knowledge of how to produce content in multiple formats is a table stakes skill for a DevRel professional today. You don’t have to be a world class video editor, but the idea of learning to slice together some video content in iMovie/Premiere Pro etc shouldn’t terrify you. The same can be said of audio. Voiceovers, podcasts, virtual workshops all require you to be confident speaking into a microphone.
Similarly, you need to be confident in your writing. Blog posts, tutorials, even tweets. The written word is still important, no matter how much video or audio you pump out.
I think what’s going to be interesting is how much we could leverage short form video for technical content. If you look at the success other industries are having with the likes of Instagram Reels, YouTube Shorts and TikTok, I can’t believe that it’s not going to be a useful way to get developer facing content to a new audience.
For some examples of folks who I think are doing this well, I always look at what GitHub and Stripe are doing. Michelle Mannering, BDougie and Chris Trag in particular from those teams are doing great stuff.
Staying close to the product
In a post last year, Getting better at Developer Relations, I spoke about the importance of being Developer Zero and working closely with Product Managers. I definitely still believe that to be true, and I’ve started to think more about how our team should balance that work with the content creation work.
When I do, I envisage it as a circular thing, because each part of a Developer Advocate’s job is wholly dependent on the other. You cannot create value for your community if you’re not pushing your product team to build things that solve their problems, and you cannot get valuable feedback to bring to your product team if you’re not sharing ideas, sharing information and ultimately building a relationship with your community.
If you’re only ever pitching your product, then congratulations, you work in Sales and Marketing, and I wish you well.
If you’re only ever having interesting technical conversations with people that don’t teach you more about how people use your platform, then congratulations, you’re a well funded distinguished engineer, and I wish you well.
Developer Relations / Advocacy sits somewhere in the messy middle. We are neither engineers who talk in the abstract and write fancy algorithms all day, nor are we marketing/sales people. You need to be comfortable living in that grey area.
At Slack, Developer Relations sits inside the Product Organisation, alongside the Platform Product Managers, so it’s easy for us to build and maintain these relationships with them. Wherever your team sits though, you should put in the effort, as PMs are one of the most important partners you have.
Always tighten the feedback loop
So what is 2022 at Slack Developer Advocacy? It’s about iterating on the loop I mention above, making it faster. Ship more content, ship better content, ship platform improvements, ship ever increasing value for our community, because ultimately, it’s them we’re here to serve, not the other way around.
If you’re as passionate about these things as I am, and want to join us, I’m always looking to talk with great people. As I write this post, I’m actively looking for people in Europe, and hope to soon be looking for people in North America. So drop me a DM on twitter, and let’s talk.
The Incident Commander is a powerful role in the world of Incident Management. Like Flight Directors in NASA missions, they have responsibility for the decisions made and actions taken during an incident. Depending on your company’s process, they may have powers like stopping deployments, commandeering staff or even shutting down the service. Whatever they deem necessary for resolving the incident.
In many software organizations, the Incident Commander is an on-call rotation, shared amongst senior members of the engineering team. And this seems logical right? Engineering managers and senior engineers will be close to the technology involved, so are best placed to solve the issues that may arise. But have you ever considered that maybe you should be casting your net a bit wider when it comes to staffing that role?
Incident Commanders are leaders, not fixers
The excellent PagerDuty training materials distill the role of the Incident Commander down to “Keep the incident moving towards resolution”. You’ll note there’s nothing their about actually resolving the incident directly. The training materials talk instead about skills like
Listening
Leadership
Clear communication
Rapid decision making
These are skills you should expect across your entire organization, and certainly ones that you would want to foster. Incident Command is an excellent way for people to exercise those skills, and limiting that opportunity to just your senior technical staff does a disservice to the whole company. In fact, at Slack we encourage members of the Developer Relations team to take part in the incident process.
If you staff up your Incident Command rotation with Product Managers, Salespeople, Customer Support Reps and others, then those people will be less drawn to directly solving the problem, letting engineers act as the subject matter experts and leaving the Incident Commander to focus on their primary role - coordinating the response.
Beyond just tapping into the leadership talents of your whole organization, there’s other benefits to sharing the responsibility of incident command, so let’s talk about those.
Solving problems can be a powerful lure
Whilst it is logical to think that good incident commanders will also be good engineers, it ignores what the role of the incident commander actually is. Put simply, incident commanders shouldn’t be solving the issue directly.
I can’t speak for everyone of course, but I know that for myself, a problem is an extremely tempting thing. I love to solve puzzles, and sometimes an incident is a ready made puzzle. But when I’m running an incident, I must constantly resist the urge to jump in. Instead, I remind myself that my role is to co-ordinate the response, because if I get too into the weeds of a proposed solution, I’m more likely to take my eye off the bigger picture of the incident.
As I mentioned earlier, as folks in Product or Sales are likely to be further removed from the technical architecture, the likelihood they’ll be tempted to offer solutions is minimized.
Empathy and Empowerment
On-call rotations in technology companies are typically only expected in the Engineering organization, but since the IC rotation involves being on-call, this expectation is shared more broadly, meaning more of your organization understands and empathizes with being on-call.
And in a similar vein, if your customer facing teams are directly involved in your incident management process, they’ll be in a much better position when it comes to discussing that process with their peers and with customers.
Many companies provide root cause analysis documents to customers after major incidents. Imagine how much more empowered your sales and support teams would be if they could speak to how the incident was run when sharing that RCA with customers.
A fresh set of eyes
The final point applies not just to incident teams, but organizations more generally. You know the expression “When all you have is a hammer, everything looks like a nail”? The same can be said about your incident process. If everyone involved in the incident process is an engineer, then your process will bias itself towards engineering solutions.
Now whilst the solution to a technical incident is likely to be technical, the same doesn’t need to be true for the process. By diversifying your rotation of incident commanders, you’re adding a fresh set of eyes to the process and will therefore create opportunities for new ways of approaching incidents to emerge.
First steps to diversifying your Incident team
Slack incident training tabletop cards
You might be wondering how to go about building a more diverse team of responders. Every organization will have a different approach, but I’d suggest the following -
Speak to the leadership of the relevant departments to get buy-in. Explain the benefits to their teams, but also the company as a whole. Incident Response will need to be considered part of the person’s role, not something that gets in the way of “actual work” that will need to be completed in addition to incidents, otherwise you’re contributing to burnout.
Invite those that are interested in helping out to observe some incidents, either live or through recordings / channel history.
If they’re still excited at the prospect, it’s time to start training them up. You can use the PagerDuty training materials as a template if you don’t already have a process for this. Although regardless of the background of your commanders, training is a good idea.
Run some mock training incidents. At Slack we do a tabletop exercise as part of the IC training process.
Let your trainees then shadow some real incidents
Add them to the rotation and see how it goes!
As the leader of your incident response program, be sure to note their contributions when it comes to performance reviews
Never stop learning
I’ve been an incident commander at Slack for over a year now and I can honestly say I’ve learned so much about leadership, communication and system architecture because of the role I play in incidents here. It’s a fantastic experience that I would recommend to anyone, so please do encourage others to try it out, they’ll thank you for it.
