Here's an insight from someone not in Big Tech: it's rare that engineers go "broad" in traditional companies, thus cross-functional teams are hard. However, in Big Tech it's still pretty common (and encouraged!) to work/move across stacks (e.g. do backend changes as a web eng)
A few things that make this more common at these companies:
- Internal open-source model (anyone can put up PRs)
- Monorepos & 1-step build processes
- Heavy automation & LOTS of automated quality checks ("if the tests pass, you can push it")
- Hiring for generalist engineers
On the last part - hiring for generalist software engineers - Big Tech gets a lot of flak for the interview process that is... generalist. Rarely going deep into e.g. specific frameworks.
And this is intentional. They want/need people who won't be tied down to one language/tech.
It is wild how striking the difference can be though.
On my team, I had a sr mobile engineer go backend, another change focus to web for a few years, iOS --> Android etc. People were interested, I encouraged, everyone won.
You basically never see this in traditional companies.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A recently IPO'd company mandated moving over to JIRA because... well, reporting, and lack of options. So they did.
As a data-driven company, they ran a survey afterward. The NPS for JIRA among engineers: -83. This means that 83% of devs would recommend *against* JIRA (!!).
Now I'm not saying JIRA is terrible... but it requires a long, and painful learning curve that most people don't tolerate. And, let's be honest: they hate.
It's also why companies like @linear are capturing the market with startups and places where engineers are decision makers.
JIRA also increasingly has a perception problem after years of treating decision-makers as their end users, not the engineers forced to use a tool to move things around.
Those engineers are now becoming decision-makers. And they want to desperately avoid JIRA, given the options.
In my observation, burnout in tech is (finally) starting to hit managers, their managers, and their managers, hard. Quote from a VP Eng:
"After 1.5 years of 15-20 Zoom meetings per day, I hit my limit and can't do it anymore. I'm taking the rest of the year to recover." (cont'd)
Some very interesting follow-ons of this trend: 1. Fast-growing startups very much struggle to hire director-level or above... and are promoting ICs/inexperienced managers as directors (yes, really) 2. The demand for experienced senior managers (and above) is exploding
3. Until now, most companies have been mostly concerned with IC burnout (ICs are in the largest numbers). It was assumed senior managers who get paid more/have more vested interest(equity) would sort themselves.
The fact that these people are quitting is a *huge* warning sign.
Uber's CTO, Sukumar Rathnam stepped down just 12 months after joining the company.
I left Uber shortly after he joined as CTO, and here are my thoughts on this departure, from the sidelines. A thread
1. This was never meant to be an easy job. SK joined after the 2020 Uber engineering layoffs, low morale, and sinking stock price.
By the time he was in, attrition was high, and he had large shoes to fill that Thuan Pham, Uber's CTO of 7-years left behind.
2. Uber was also without a CPO at this time: Dara stepped in to fill this role. One more challenge.
3. The tension with what engineering wanted (build for the long-term) and Uber's business needs (get to profitability the short- or medium-term) were always at odds.
The tech hiring market has never been this hot: not even during the Dotcom Boom. I talked with dozens of tech hiring managers (from managers to CTOs), swarms of people switching jobs to answer:
Why this is happening, and what are companies doing who keep growing?
A thread:
1. Covid-19 being the tipping point of companies going all-in on digital. Not just e-commerce, but all industries are investing *big* money to move to digital.
What are Platform teams, why are they important, and why do (almost) all high-growth companies and big tech have them? A thread.
1. The easiest way to visualize Platform teams is blocks of specific types. Other teams (called Product/Program) use these "blocks" to build.
2. Platforms are focused on a technical mission, rarely have cross-functional engineers (e.g. mobile & backend folks) on the same team, and customers are (usually) internal engineering teams.
Examples include infra-like Platform teams and Product Platform teams.
3. Why even have a Platform? Could we not just... do what we do?
Platforms own very specific goals, often tied to non-functional capabilities like performance, reliability, compliance, security etc.
Yes, you could do without them: and every single team would need to own these.