Platform Support
Supporting multiple platforms can be a repetitive and boring problem, or a fun challenge.
I work for a big tech on a smaller product that is part of a rather large portfolio. This product has front-ends in multiple platforms (web, desktop, mobile and so on). Unfortunately, my team handles the smallest platform and we’ve been suffering deep cuts in funding. We now handle an entire platform with a minimal team.
Do you have any recommendations on how to grow on this type of context? How do I grow to a post-senior position if my team can barely keep up with the essentials?
This question came in through our SaaSy question portal.
First, you want to have Consistent Caliber Teams. Platform support is an interesting question, because it can make it hard to naturally create teams with equivalent opportunities to others.
The example above is common - one shared backend supporting mobile, web, desktop. Often the client platforms are considered lower value work than the universal backend work - sometimes that’s true and sometimes people make silly assumptions like backend being harder than mobile clients.
While platform client work can be undervalued, if it’s broken, it’s a huge problem. High risk, (perceived) low complexity work can be quite challenging. Can you retain high-skilled workers for this kind of work? Can you afford to not hire high-skilled workers given the risks?
It gets worse - sometimes one of the platforms is slowly dying - maybe the desktop version of your product is declining in users, but some of your highest value customers use it. Now you have to find high-skilled workers to support a platform that you know is not the future of your product. Good luck.
Ok, now that we know the problem space, let’s get to some productive answers.
Heuristic one: be decisive
The number one failure in this scenario is not making decisions. People just hope it’ll kind of all work out. Then, slowly over time you realize you can’t support the portfolio of platform support, e.g. that one guy who was supporting the desktop platform quit, and you have to scramble.
So, rule one - analyze the situation and decide:
Deprecate, shut down, or open source platforms you can’t support
Set a clear strategy for the quality of talent you’ll have supporting these platforms
Repeat this process yearly as your platform client portfolio changes.
Heuristic two: make lots of small problem into one hard problem
People’s natural tendency is to make platform support teams mediocre. This is because leaders see several smaller problems (platforms) instead of one big problem (how to support the portfolio).
Hiring B talent is a mistake - you’ll forever be on a treadmill of engineers who are second class citizens, or who leave the team (internally or externally) after getting fully up to speed.
And remember - these platforms can fail terribly. The errors that just-ok engineers make in these platforms will hurt just as badly for your customers. So you’ll constantly be frustrated by things like bugs in the iOS app you have one junior engineer supporting.
You should hire great people and challenge them to support these platforms in high-leverage ways. Maybe that’s switching to a build-once-deploy-everywhere platform like React Native. Maybe that’s building a core set of libraries that are portable to all platforms. Whatever it is, if you think about supporting multiple platforms as one hard problem - how do we support n platforms without having highly repetitive work - it’s much more scalable than thinking of it as several pesky, small problems.
Another version of this is approach to hire great people that can do platform support really fast. Then, you can challenge them to take on other tasks as well - side projects, open source contributions,etc. 30% of an A player’s time doing platform support often yields much better outcomes than 100% of a B player’s time.
Backup plan: solve with people
Maybe you can’t for some reason just have a handful of A players tackle these problems for you. You can - and many do - tackle this problem by adding people.
Most people staff these teams with a bunch of junior or mid-level employees. You want to make sure two things are true:
You need to have at least one really really talented person oversee of this platform support team(s).
You need to have a growth pathing strategy for the team members.
On the first point - it’s imperative that at least one member of your platform support group is really talented, tenured, and capable. Having this kind of person in the system means that your more junior resources can be directed productively. The difference between junior staff directed by an A player and junior staff directed by a B player is monumental - it’s the difference between a team that works and a team that doesn’t.
On the second point - the junior and mid-level staff working on platform support will never become a bunch of Staff engineers if the problem space isn’t deep enough. That’s OK, you just need to have a plan, which means in many cases having a path for people out of the team.
Companies often have teams that require leaving the team to pursue more senior IC roles. Tech support is often a place where there is a ceiling on the seniority of technical depth you can achieve. In both of these cases, and in any case like this, the key is to be clear about expectations.
Bringing It Back
Back to the original question - you’re on the smallest platform of the portfolio and you’ve seen deep cuts in funding, what do you do?
There’s a few of possible options here -
First, say you and your team are really good, just running a skeleton crew right now.
The thing you must do is drive decisions, like:
You can stop supporting your platform. You can combine your team with another platform team, make a deprecation plan, and have more success in the bigger group.
You can advocate for a build-once-deploy-everywhere solution like React Native. There are pros and cons, but if you can’t sustain a team on this native platform, that kind of centralized building can be the right tradeoff.
You can challenge your team to find high leverage solutions even if it means slowing other development. Use this moment to write automation, make your team more high leverage, and get more done with fewer people.
On the other hand, if you and your team are not great - i.e. finding a new job would be quite difficult, or doing a bunch of heroic automation would be challenging - you might just be hitting the wall of reality. In the ZIRP days, everyone had an ambitious growth path. In current conditions, some people are getting more clear feedback that their performance isn’t justifying more responsibility. The answer in this case is to really work on improving your skills.
This last bit of feedback might sound a bit harsh, but again, the most important thing to do is to be clear about what’s happening, where it’s going, and what decisions you need to make. Ignoring realities - both for things like platform support and personal growth - will only delay outcomes, so I’d suggest taking a sober look at what’s going on, understanding where it’s leading, and making the best decisions possible given that information.
Share to Twitter , Hacker News , LinkedIn