Ask HN: Books for engaging with business problems as an IC? | Hacker News Reader

Ask HN: Books for engaging with business problems as an IC?

15 pointsrlue5 comments

After a youth spent avoiding the rat race by any means possible—volunteering on farms, teaching English overseas, etc.—I find myself in my late 30s as a junior eng. IC at a tech megacorp (think 10k+ employees).

Even after 1y+ here, I continue to struggle with adapting to this environment and making myself valuable to the team/company beyond merely completing my assigned tickets. I think I am reasonably competent at the craft of building software (writing tests and documentation, identifying code smells and antipatterns, applying design patterns and particular software programming styles where appropriate); I'm even pretty good at the bureaucratic work of filing tickets, maintaining the wiki, and writing self- and peer-evals through performance review season. But I have difficulty with being a proactive member within it: in other words, having a voice, leading initiatives, or feeling qualified to make meaningful decisions (technical or otherwise).

If pressed, I could describe my team's OKRs and how my tickets move the needle on them. I could not describe what my teammates are working on, much less what adjacent teams are working on. There are a lot of design docs, architecture docs, and planning docs; I have a deluge of these tabs open, and I have a vague sense that it would be good to grok them, but when I take the time to read through them, I feel very little confidence that I understand well enough to put that knowledge to use. The only meetings I've ever scheduled were to ask for help getting unblocked on a ticket. I tend to drift off in meetings because people are almost always discussing things I have no context on and am not party to.

Can anyone recommend books that will help me engage better with the business that I work for, or get meaningful things done within it? I am not necessarily aiming for a management position, but would like to actively leverage the fact that I work in an organization: to create my own opportunities to work with people other than my manager and mentor, and in the process, to get things done for the business that is greater than the sum of us working separately.

I came to this post thinking I was going to find a bad question, but it's actually the opposite. Very good question as our other friend pointed out in the comments. I think you are already on the right track just by asking it.

I don't know about any books on this subject, and it was something I could have benefited from before for sure, instead of having to learn myself how to "succeed" in an environment like the one OP described.

There's a lot to be written about the subject, in multiple levels, but at the highest level, and in the most summarized way, what you have to do to succeed is simply to bring solutions to people and not problems.

The catch, in my experience and opinion, is that the large majority of people, by far, confuse the two things.

Coming up with an idea for a project that will solve a problem is not a solution. It is actually a problem from your supervisor/company perspective.

"Why is it a problem?", you ask.

The reason is simple, now this project is another item for your supervisor to add to their backlog because they will have to do all the work: write about it, explain and sell it to stakeholders and supporters, assemble a team, plan the project, manage execution, and all the other stuff.

"How do you transform this into a solution?"

You take on all those things. You should do all the work required to put a real plan together. Once that's done, then you bring it to your supervisor and you'll find that it is much easier to get support like that. The challenge is coming up with a plan that includes everything your supervisor/company cares about.

I can assure you that if you get this right, you'll find yourself contributing to the bigger picture much more often. Everyone says they want to contribute, but when it comes time to do the actual work, very little people want to do it, because it's really hard.

This is a super interesting question and a problem I’m struggling with too. Really excited to see how others answer but I’ll give my 2¢.

To get people to agree to projects, you need to couch its goals in terms that management & other ICs care about. So for some groups, that will mean increasing revenue, or improving margins, or reducing latency, or automating manual work. But sometimes groups inside companies aren’t aligned with the overall strategic objective of the company: ie a company needs to improve its ROI, but its marketing group is working on increasing its revenue (if you’re not profitable, this could literally destroy your company if marketing does its job too well, even though that’s what marketing ~should~ be doing is increasing growth/sales).

So you need to know how to align your group with corporate strategy. What do your top execs want? One of the best ways to figure this out is to listen to/read your company’s earnings calls. These will tell you what shareholders and management cares about. Read between the lines. What business lines are the analysts asking about? Which are they ignoring? If you’re in a group they never mention, you probably don’t matter too much… The business lines they’re asking about are the important ones.

I write software in support of supply chain and operations, so the book I read about this was “Operations, Strategy, and Technology: Pursuing the Competitive Edge“ by Hayes et al. I’d also recommend the McKinsey Valuation book for understanding what’s motivating your management, shareholders, and company.

Basically you’ve got to learn how to speak MBA and put your technical projects in that context. If your company cares about scaling growth in ecommerce, and your project works on customer journeys—translate your project into $$ made for the company.

That’s what I’ve learned so far, hope to hear discussion on this.

> I could not describe what my teammates are working on, much less what adjacent teams are working on.

That's an organizational communication problem, less for an IC to solve and more reflective of the culture.

From everything you've described, it seems the company is structurally built so that you would be on a need-to-know basis. I'm going to use the analogy of horse blinders: processes around teams have been built so that ICs would focus on their tickets, just as you describe. This is not an act of malice - in a company this big, to steer the ship in any one way, you don't want noise coming from half your workforce, nothing would ever get done...

But it does mean that all the gaps you are describing are, in many ways, there by design. So going against them is going against the grain of the organization. I think it generally helps to bring something to the table. A point of view on something external to work that could add value inside it. In many ways, though, it still requires hustle, in the sense of reaching out to people and creating opportunities.

For example, you might take an interest in a certain type of antipatterns, and want to propagate the knowledge internally about it, and how to resolve it. (I'll assume the company doesn't actively seek to cultivate this anti-pattern deliberately. You never know.) You might say, oh, I can put together a colloquium about it. So you find the person in the org who's in charge of the events, and talk to the person who books the rooms, and talk to people around you to get ideas on how to promote it internally...you get the drift, it's not all that different to doing these things outside a company. (Except the part where you risk treading on more toes.)

One book that's really useful for just about anything is "The Goal". It teaches you to think in terms of processes, bottlenecks and constraints. With this perspective, you learn to look at the work you and others do not as a series of discrete tasks, but as part of a flow of production. It broadens the perspective on the types of questions you can ask.

I post this from time to time. You may find it useful...

Understanding codebases:

- https://news.ycombinator.com/item?id=19924100

Testing pipelines, scaffolding, issue templates:

- https://news.ycombinator.com/item?id=26591067

Making the most out of meetings and leveraging your presence:

- https://news.ycombinator.com/item?id=22873103

Product development:

- https://news.ycombinator.com/item?id=22827841

Giving a damn:

- https://news.ycombinator.com/item?id=20356222

If I disappear, what will happen:

- https://news.ycombinator.com/item?id=25008223

Consulting, understanding the problem your "client", who can be your manager, has:

- https://news.ycombinator.com/item?id=24972611

On taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable:

- https://news.ycombinator.com/item?id=24209518

Product, architecture, and impact on the team:

- https://news.ycombinator.com/item?id=24503365

Onboarding new hires to a codebase, what if it were you, improve code:

- https://news.ycombinator.com/item?id=22860716

Tips to learn from videos:

- https://news.ycombinator.com/item?id=22710623

- https://news.ycombinator.com/item?id=22723586

Communication with the team:

- https://news.ycombinator.com/item?id=21598632

- https://news.ycombinator.com/item?id=21614372

Reduce information asymmetry, template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended:

- https://news.ycombinator.com/item?id=21427886

More meeting notes. Reply to a person who had trouble talking in corporate meetings:

- https://news.ycombinator.com/item?id=20323660

Communication, alignment:

- https://news.ycombinator.com/item?id=24177646

Useful things for the team and product that add leverage:

- https://news.ycombinator.com/item?id=21808439

Management involvement as a spectrum:

- https://news.ycombinator.com/item?id=22715971

Researching topics:

- https://news.ycombinator.com/item?id=25922120

Keeping up with a firehose of information:

- https://news.ycombinator.com/item?id=26147502

Fractal Communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets:

- https://news.ycombinator.com/item?id=26123017

Remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align:

-https://news.ycombinator.com/item?id=26179539

Write better. Always.

Reply on news.ycombinator.com