Seems odd to take this advice from a company like Twitter when you compare them to companies like Instagram and WhatsApp. How to keep a lot of engineers busy and burn a lot of money, they could offer lots of good tips there.
Why? Because Twitter as a company hasn't produced effective revenue? Twitter (or their employees personal projects) has brought us Bower, Bootstrap, Typeahead, Flight and many other fantastic open source tools to make devs more productive. I think they are a great company to take advice from in this specific area.
> Why? Because Twitter as a company hasn't produced effective revenue?
Because they're lecturing about engineering efficiency, yet they require 2,000 engineers to support their product. By comparison, WhatsApp scaled to 3X as many active users with a engineering team 1/40th the size. Instagram also runs circles around them in this respect.
For a team so huge and so productive, where is the output? More productivity tools? Maybe Twitter should pivot into that space.
> WhatsApps product is much, much simpler than twitters products.
Can you enumerate Twitter's products?
Perhaps Instagram is a closer comparison -- broadcast photos instead of broadcast 140 characters. And you have a much smaller engineering team, much faster growth, twice as many active users, and far fewer fail whales.
Regardless of the comparisons, 2,000 engineers seems excessive in proportion to Twitter's product, which suggests engineering inefficiency.
Don't forget that Twitter has a comprehensive advertising platform. The partnerships, sales, tooling, and ad auction system themselves are likely just as complicated (or more so) than the basic Twitter product.
Instagram has only recently started to monetize the product -- it's almost unfair to compare the size of the engineering teams supporting the systems.
In addition to advertising and the engineering required around that Twitter has many data product offerings and has recently pivoted to end simple data products to partners (such as selling direct access to the firehose) to more complicated data analysis product offerings (consider the purchase of Gnip last year). Lots of engineering required around building these products.
I believe the primary difference can be summarized in two words - data analytics. Twitter has a ton more analytics options for its users than WhatsApp appears to have mostly because, like Google, Twitter is more of an advertising platform than a utility platform as far as its actual business model goes. WhatsApp is potentially b2c as a business while I'd argue Twitter is really b2b. My experience with enterprise businesses makes it hard for me to believe that going b2b is actually efficient as much as it is about revenue assurance and scaling for sales / marketing culture organizations.
The scale and reliability is the challenge. You could probably hack out a client and server on the weekend, but simulate 10 million concurrent users and every single part of your stack will break.
Also, I suspect that their strategic plan is not about minimising the number of engineers. They may want to be able to set up non-public projects which iterate for years or months before becoming visible: frameworks, app ideas, you name it. Their Fabric platform gives them excellent insights into what people are doing on mobile apps, for example. The kind of insights and understanding they have into personal and aggregate app usage is quite frightening when you realise just how much they have instrumented.
Instagram and WhatsApp also benefit from the work of their parent corp, Facebook. I know people who work on Instagram.com and they consider themselves Facebook employees. So I think maybe those companies are not good comps, or at least a poor apples-to-apples comp when doing headcount: product.
To me, this is obvious. I find it extremely valuable to spend time making things more efficient and clear. Even if the time spent doesn't save that much time, but makes things less frustrating, it's a big win to me. There's a lot to be said for having processes that are predictable, that don't randomly have issues that require taking time out of your day to resolve before you get to your actual problem. I'd be surprised if there was a significant percentage of companies that don't spend at least some time solving these types of problems. I think the question that this article brings up, is what that ratio should be to actually gain.
They're a cost center and not a revenue generator.
When you've got a group that provides no measurable revenue they will always be at a disadvantage to the group that provides the money train. This is why you see a systematic de-valuing of tools and iteration improvement despite the massive gains they provide.
JIRA costs $20k for an organization with 2000 programmers. How much custom development can you fund with that amount? If your programmers earn $100k/y (fully-loaded!), you can't even afford 3 man-months.
I think the point is that JIRA won't do exactly what you need. Using a tool that's "good enough" is the best choice when you've got 5 developers but not when you've got 5000.
Yeah, but when you buy a license, you get access to the full source, which you can adapt to your needs. I think that's a much better option than building a similar tool from scratch.
We generate a huge amount of IP at work in a (similar to) engineering effectiveness role. Even the dumbest tools we come up with could be spun off into an ok-ish start-up.
I guess it's a matter of mindset, if you think to make tools which address the issue at hand, you'll end up as a cost center; if you think of products to solve the class of problems the issue belongs to, then you'll be adding value to the company as well as improving effectiveness.
Regardless of the coefficient, it comes down to whether or not everyone else in the company realizes that the tools expertise is the secret sauce driving the money train. I think that's what the person you were replying to was getting at.
It is unfortunate, but the reality of our profession is that tools/infrastructure work always has an uphill battle when it comes to justifying engineering time. It's something we all have to fight for when appropriate, and discussing why and how to do that can be super useful.
Working on tools and infrastructure is by definition time spent making things that will help us make things to make money. The people paying us usually would much rather have us spend time making things to make money, rather than making things to make things to make money. If there's not enough trust between the engineer and the nontechnical manager/investor/whatever, it can be hard to get buy-in for time and money spent making something which is essentially an IOU for hypothetical returns later on. Build that trust and have great ideas and hopefully resources can be directed towards indirect (tools/infrastructure/whatever) engineering expenses.
It is always an uphill battle though, I think it's just the nature of the industry, or at least most companies. :( I'm not bitter though, because it really is totally rational if you look at it from the perspective of the stakeholder who would have to approve it. Just part of the professional landscape to be aware of.
Sometimes(read: most of the times) the tech debt and other code issues arise from the last min requirements although as dev. we try make sure the code is robust enough to absorb these changes seldom this happens.
What I have seen is effective for me is to sit down with pen and paper and describe the problem at hand and then think about the solution write up.
Raise $1B in private capital and another $2.1B in an IPO. Now you have billions to burn and sky-high expectations and no path to profit. Hire lot of people and hope for the best.
But in their defense, Whatsapp and Instagram hadn't demonstrated an viable alternative yet.
