know how your org works (or how to become a more effective engineer)

The Mirage of Aspiration

The vast majority of what passes for social media discourse on fairly any topic is fairly aspirational (or cantankerous or plain nasty). Much of such discourse gets amplified to a degree not commensurate with the underlying sagacity. None of this is productive; worse, it gives impressionable people a fairly warped idea of how organizations must function. It’s rather disheartening to see aspirational goals get exalted to such heights that anything that doesn’t scale to their quixotic ideal is often deemed as “toxic” or “dysfunctional” by many.

Know How Your Org Works

One of the most effective things you can do to be successful at your job is to understand how your organization works. This understanding will better inform your outlook on everything from:

  • how to build lasting relationships with other people on your team or organization that will ultimately dictate the success of a project
  • how to effectively pitch projects or improvements and see these through to completion
  • how to navigate ambiguity
  • how to manage conflicting priorities or expectations
  • how to best deal with setbacks
  • how to weigh the pros and cons of technical choices in the larger context of the organizational realities and needs
  • how to identify and drive quick wins
  • how to discern what’s achievable in precisely what time frame
  • how to use this knowledge to judiciously pick battles
  • and in the worst case, to know when to cut your losses and quit

Soft Skills Are Hard Skills

This post doesn’t aim to be a comprehensive guide on how to learn such skills, or even a comprehensive list of these skills. What’s worse, there are no fixed set of answers to many of these questions, since there aren’t even a fixed set of questions to begin with. The questions mentioned in this article are simply the ones I’ve encountered. If you were to ask someone else, you might get a very different list. Learning is relatively easy when you know exactly what to learn and how to learn it, and so long as the answer is unchanging (as is the case with many purely technical concepts).

  • how and when to get by without doing so

Understand Implicit Hierarchies

Most organizations have a formal structure. This usually starts with a VP or a director at the top, down to individual teams. If you’re an IC, you’re a leaf node in the org tree.

  • Identify the people who wield undue influence and their way of thinking and general philosophies (by either talking to them, or other people in the organization, or researching their past work, reading any articles or blog posts they might have written, or talks they might have presented, etc.)
  • Identify how the aforementioned philosophies have been previously successfully applied to projects and teams they were on. Why were these efforts considered successful? What were the problems these philosophies solved, and what were the problems they didn’t solve (or exacerbated)?
  • How do you build credibility with them? Can you lean on your past work? Your subject matter expertise? Your previous track record? Is there someone they trust and respect who can vouch for you, for them to take a leap of faith and agree to do things “your” way?

Cultures: Top-Down, Bottom-Up, and Both

Irrespective of titles and hierarchies, most organizations also have a somewhat top-down or bottom-up culture (or a mix of both). I’ve worked in both settings and have seen enough to know that neither one is better than the other. It depends on the kind of engineers you’re working with, their general level of technical skill and experience, their previous experience with various pieces of technology, their background and more.

  • Is there some information or knowledge they have (and you don’t) that informs their thinking on the matter? How best can you get this information?
  • Do you both share the same view of the opportunity cost?
  • What are their implicit and explicit biases? What are their blind spots? Can you use some of these to your advantage?
  • What are the things they generally value? What kind of work or behavior impresses them?
  • Is there any specific abstraction or process or methodology they are particularly attached to? Can you lean in on these to more effectively market your opinion to them?
  • What’s the timeline they are comfortable working with to solve the problem? A month? A perf cycle? Many years?
  • What’s your personal level of trust with them? Will they go to bat for you?
  • What does “success” mean to them, and how do they measure it? How have they typically measured it for work that’s in-progress?
  • How do they typically handle setbacks? Have you drawn up contingency plans and discussed it with them?
  • How do they handle failure? Do they assume any responsibility for it, or will you be scapegoated (and possibly fired)?
  • Do they have a culture of blameless postmortems for large-scale team or organizational failures? Are these lessons shared and discussed transparently with everyone on the team and in the organization?
  • What is their previous experience working with partner teams or organizations?
  • Have they been burned badly in the past working with another organization or another team?
  • What’s their organizational reputation? Are they well-liked? Well-respected?
  • How conflict-averse (or not) are they?
  • How do you break down barriers between different peers?
  • How do conflicts get resolved if there’s no higher authority to mediate? Does it boil down to nitty-gritty quantitative details like metrics, or something more nebulous such as “likeability”?
  • If all key ideas have to originate from the bottom, which ones makes it to the top? How has this worked in the past?
  • Can “code” solve all issues? Can you go prototype an idea you have and then successfully pitch it? Does your team or organization empower you to do this during your business hours, or are you willing to spend your nights and weekends pursuing this goal?
  • Has the problem you’re trying to solve been attempted before? How did that attempt go? What were the failures? Do you understand the proximate cause of these failures? Are you sure you won’t run into the same issues again?
  • What’s the opportunity cost? Can you convince your peers that it’s worth solving right away if it hasn’t been prioritized so far?
  • What’s your scope of influence? Does it extend to just your team, your team and sister teams, or your entire org? Are people outside your team willing to give your solution a whirl?
  • How do you convince different people or teams with different incentives? Is this something you can even do without top-down support?
  • How do you ensure adoption, especially cross-organizational adoption?
  • How do you enlist partners or advocates for your effort? Are there other teams ready to adopt your solution, if you were just to build it, and advocate for it?
  • Do you have key relationships with the stakeholders? Do they trust you? If not, why not? And how would you go about building this trust?
  • How do you convince your peers who’ve had previous bad experiences with your team or project in the past?
  • How do you build credibility?
  • How do you motivate and incentivize your peers in general?
  • What’s the cost of failure? Just one fair to middling perf cycle, or something worse? Who’ll be impacted? Just you? Or your entire team?
  • What are the cultural problems you perceive? In a bottom-up setting where there’s no higher authority that can mandate teams to change how they work, how do culture problems get fixed?

Get comfortable with the “mess”

  • how not to get too caught up in the weeds unless required
  • how to read a lot of code at a fast clip and come away with a reasonably good mental model of what it’s trying to do
  • how to come up with hypothesis and use a variety of general purpose techniques and tools to validate the hypothesis
  • how to reproduce bugs quickly without elaborate local configurations and setups
  • and more.
  • varying (sometimes even opposing) incentives and reward structures
  • varying appetites for risk or change
  • varying philosophical views on software development and systems
  • varying levels of tolerance for failure
  • varying willingness to make investments (in people and projects) with a long-term view in mind

Look For Small (And Any) Wins

It might take you way longer to truly get the measure of your organization’s sociotechnical politics than to get to speed with a codebase. To build credibility, you need to demonstrate some degree of impact early on, instead of waiting for months to get a lie of the land before you start getting anything done. Chasing small wins and low hanging fruit can be an easy path to productivity. Don’t underestimate the importance of this.

Understand Org Constraints and Manage Your Expectations

It’s important to mention that individual managers (much less ICs), can sometimes do only so much when it comes to solving some of the more entrenched organizational problems. DEI is one that comes to mind first. I’ve never seen this problem solved in a bottom-up manner successfully anywhere. Places that have made moderate progress often have enjoyed executive buy-in. Organizations that are serious about DEI have executive compensation tied to the success of DEI efforts.


It’s easy to dismiss much of what’s described in this post as “politics”. The unfortunate reality is that almost everything is political, and beyond a certain level, advancing further requires getting really good at playing this game.

  • relentlessly getting things done
  • successfully creating change than just endlessly talking about the need to do so



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Cindy Sridharan

Cindy Sridharan


@copyconstruct on Twitter. views expressed on this blog are solely mine, not those of present or past employers.