Recommended books about tech company growing pains

[mike128]

Hi there, I work at a company that is experiencing what I diagnose as growing pains. I’m looking for book recommendations that could help to direct the solutions.

A bit more context. The company is profitable with high margin, growing close to 100% year to year in the past couple of years. The tech department is around 250 engineers. The value the company provides relies heavily on the proprietary software products. Now we are in the situation where core product is a legacy monolith and a pain to keep iterating on.

Seems like what was working when the company was smaller does not scale anymore.

There are different initiatives being pushed from multiple angles aimed at bettering the situation. It seems like the coherent tech direction is missing that would allow to reorganize the company to be more effective.

That’s the gist of it. I’m sure we are not the first company facing this sort of struggles, but I have never worked for one in this situation. I’d appreciate book recommendations that could help me to propose right improvements - whether that is from the product/tech/leadership or any other direction that might be in my blind spot.

[kypro]

This seems a bit niche for a book? I mean, there might be a book out there with some relevant information in, but my guess is that the advice would be too generic to be particularly useful. The solution(s) probably depend on the nature of the business and the specific problems you're facing.

I think networking is the way to go here... If you live in a decent sized city you should find plenty of networking events for business owners. Alternatively you could reach out to people on Linkedin who might have some advice to share. When I was working on startups several years ago that's something I would do a lot. I would try to find people doing similar things successfully and send a message saying hi and explaining the situation - you'd be surprised how many people will happily talk to you for hours just to be helpful.

[codingdave]

There might be a book that has some info, but a migration off a legacy stack is not a cookie cutter project. It requires understanding of how the entire system works in a way that you can devise a plan of how to slice it up and move one piece at a time without breaking things.

Because in general, the migration will first need to be planned without consideration for technical roadblocks. You decide which pieces to move, in what order, based on what your desired final solution is. You then identify what is stopping you from making those moves and you spent a bunch of time and effort mitigating those roadblocks. That could take you a year or two. Once you are actually ready to start migration... execute the plan. Another year. It sounds slow, but a 3 year plan to decommission a legacy product is fairly standard.

In any case, people like myself exist who have done such projects, but we don't know your product. So while you are correct that getting some outside advice may help you find your direction, nobody external to your company has the knowledge to truly make the plan. You need to put your heads together internally and use your knowledge of the legacy system to plan things out, while also figuring out how to keep the system alive while you migrate. Identify which pain points in the system impact your customer, and focus on fixing those so that your customer base doesn't revolt while you take the time to move the stack.

[bwh2]

A few books that are relevant to your situation:

  * High Growth Handbook - covering the operations and biz side
  * The DevOps Handbook - developer effectiveness in larger orgs with examples
  * Monolith to Microservices - how to execute the transition
  * Team Topologies - how to organize teams for effectiveness

My site has notes for these books and more: https://www.briansnotes.io/books/

[hayst4ck]

There is absolutely no replacement for experience.

I have worked with one engineer I would literally chose over 30 random senior engineers. They dealt with all the problems from 200 to 20000 engineers and they understood the systemic solutions rather than hack job half way solutions. They also come with clout that people would defer to. When you pay someone a lot, they have more organizational value and are therefore able to more easily get their way. Often times line workers will understand the problem and the solution, but not have the clout to lead an initiative. Incredibly experienced people are rare and hard to hire.

I've found PHD's to be half absolutely phenomenal and half kinda meh.

Leadership is a much harder problem because a lot of people in leadership have failed upwards. I don't have a lot of respect for most of the senior leadership of companies I've seen, but long term direction needs to come from senior leaders. Especially for the work that sucks (refactoring/migration). My understanding is that they frequently consult with peers at other companies or pay retired folks for consultation.

Extreme Ownership is a fantastic book on leadership. Having been in exactly your situation (I think?), that book did an amazing job of breaking down why the leadership at the company I worked for wasn't great, as well as how they could have done better.

If I had to guess, there are some pain points that no one has direct ownership of, specifically the monolith doesn't have a team of people who directly claim ownership of the monolith itself. This likely leads to flakey tests, flakey builds, slow tests, slow iteration and all manner of problems.

Monoliths are fundamentally a tragedy of the commons. Every individual engineer is incentivized to add complexity and almost every engineer is also incentivized not to reduce complexity. Complexity is like fish in the ocean, and once all the fish are fished (once it's too complex), you can't catch any more fish (you can't generate new features quickly enough).

The answer to a tragedy of the commons is a government which enforces regulations, so a monolith owning team will likely need to be given authority (and more importantly resources) and then to start regulating the complexity of the monolith (no more bespoke features/dependencies without major justification and a design doc to review).

Creating the concept of ownership for directories/files in your code base and then wiring up automatic code review for owners of various areas goes a long way towards fighting the "no one wants responsibility for this" problem. All code must be directly attributable to a team.

If you have specific problems, you might try asking HN how they have been solved, or you can ask here too.

If you are a member of the ACM, then you also have digital access to the entire o'reilly library and can peruse their offerings. "scaling" is probably the key word that most directly applies, but "monolith" might have results too.

I think this blog has a lot of fantastic content if you want to go mining: http://highscalability.com/start-here/