48 comments

[ 2.6 ms ] story [ 97.6 ms ] thread
Particularly if you do your own devops.
Actually, I've heard all those sayings at Bay Area companies, and often by senior managers who wilfully enforced them.

So the trite article advice to man up and DIY is more tone-deaf clickbait.

This sounds good on paper but ... if your team asks you to e.g. prove P=NP, “taking ownership” of that is just going to be stressful and unsatisfying. Is that deflecting?
"Reality is that which, when you ignore it, fails to go away."

fF you truly believe you can do anything (1), when you come across something you don't manage to do, now you know it's not your disbelief in yourself that's making it not possible.

(1) If you think you can fly, start from the ground.

Ofc you're correct about the failure mode for this - the attempt, and subsequent failure, are stressful and the like. Whatcha need is a different system with a different failure mode, such that the two failure modes don't "line up". Then you can use one to check the other.

It is essential to have a clear notion of what the goal/success looks like, so that you can own that. At present, These days I'm confronting a few situations in life where the direct path to what has, for a decade, been the ostensible goal is demonstrably closed.

It has been useful to realize that, in most cases, those goals have been proxies for more abstract goals that are more attainable. Owning those outcomes is both possible and powerful.

If the linked post is resonant, have a gander at Extreme Ownership -- the same general philosophy.

Extreme Ownership makes (more) sense in a military context where the price for failure is much higher than in a civilian situation.

Ownership as a word has been hijacked by self-help marketers to goad people into providing more labor than they are paid for. True ownership means having a meaningful stake in the success or failure of the company. If you are not on the hook for more than having to find a new job on failure and will not get anything more than a mild pay raise or promotion (if even that) on success, then you do not "own" a process no matter what any internal document says. Acting as though you do just means that you are giving away value for free.

Hmm...

All else being sufficient, acting with/feeling "ownership" over something is the #1 way I've gained the skills to get that change-companies-promotion.

AKA, I've found it worth it for personal growth, even if it's not been worth it for this-season career.

"The goal is not to hold the garrison, but to render the enemy unable or unwilling to take the garrison" (Erfworld)
As I see it it's not that one can't push towards a solution. It's that one doesn't find the potential reward (or potential risk of negative consequences) of doing so worth the work/stress/time. Plenty of companies where the nail that sticks out gets hammered down.
Sounds like a culture worth working to change.
Sure but that's a very involved, long and risky process. If you want a different culture then it's generally better to just find a new job at a place that already has one.
Some places can’t be changed. You’ll have to fire the entire executive team and the board to get a change.

It’s important to recognize when that’s the case and get out.

If it’s a small/medium company/team - sure. But if you try doing that in a giant behemoth of a company as an IC - this is a recipe for quick burnout and/or ruining your mental health.
"Internal Server Error" It's not your team or you, it's your server.
One might argue that "it's not your server, it's you."
Very true. I would add that if you believe it's your team then your team is probably talking about leadership with variations of the few lines at the top of the article.
Reminds me of the mentality strong players in MOBAs advocate for. You're playing on a team with four other strangers, so it can be easy to feel hopeless and give up when they make mistakes. But the most optimal thing to do is to not focus on their mistakes, but focus on how you can correct your own mistakes: how you can beat your lane opponent, how you can anticipate a jungle gank, how you can translate a won lane into a won game, how you can communicate your intent effectively with pings to prevent that failed dive next time, how you can foster a positive mentality among your teammates and what you can do to help them win their lanes.

You get better by revisiting the decisions you made, think about how you could do better next time, and move on to the next challenge. When you develop learned helplessness, you stop getting better and can actually become worse.

This is a really fantastic way to describe this, thank you.

I'm considering the last few situations I was in, professionally, and how they match these descriptions...

How do you translate IC work wins into company wins (akin to turning a lane win into a game win)?

Is... step one of that, gaining the organizational power to expand beyond your lane?

PS - This concept is hazy and I'm finding it hard to grasp to put it into words ATM, so if this isn't clear enough for responses, ask some questions and I'll try again.

Mostly, become good enough in your own lane that you get access to / become desirable for teams with other good players. Some games are just lost no matter how well you manage your own lane, similar to how some companies are doomed no matter how good their tech is.
Hmm.. "The game is lost when those who're winning in it aren't given the lead" ?

Then reconjugate to be a thing you can do -

"If the game's being lost, and you're winning in lane, ask to be given leadership. It's when /that/ comes back 'no' that it's time for you to find a new game."

(I'm noticing this is begin to look like "Winners want the ball.")

You don't have to ask for leadership to do things to enable others. Like improving CI, facilitating communication with another team, fostering a positive environment.

I think ICs who focus solely on keeping their head down and writing good code are limiting themselves, and it's a similar mentality I see at lower ranks in games.

This! Definitely. Can you go into more detail / provide links for more on exactly this?
I'm not very positive about this either. Great skills in one position don't necessarily translate well to leadership skills. It's even worse outside the area of expertise. If the dev team has been rocking it but sales can't deliver, would you promote one of the devs to Head of Sales in the hope that this would turn the ship around?

In any case, asking to be given the lead only works if you have sufficient levels above you that leadership can be taken away from the people currently in charge. If those are (for example) the founders of the company, good luck.

Hmm. I think a good question, even if the question itself shows the error -

- To keep using the MOBA analogy (for me that'd be LoL), when you're winning in your lane enough to roam, you don't take over someone else's lane, you go assist them in it.

If eng is killing it and sales are lagging, I guess you'd send some folks from one to assist and empower the other. Maybe sales doesn't understand the tech well enough to sell it, maybe what sells isn't what's been built, maybe it's a question of moral and bodies, maybe it's a question of tooling.

Hmmm. I'll admit I'm not much of a MOBA player (SC2 is more my thing) but at some point "roaming" stops working because the game changes. MOBAs work because skills transfer at least reasonably well between lanes. The amount at which an HR person could help me with algorithmic problems is very limited, as is the amount to which I could help them with legal issues. To that extent "real world" problems don't translate well to game worlds.

I am intrigued by the possible interplays with sales though. So far I have not been in a position to really help them out, but maybe I'm just lacking in imagination?

Re: Cross-discipline where the skills don't transfer - Ehh depends on a lot of things? If the assist can go on for months, a lot more makes sense. Plus, I dunno about you, but programmer seems to be almost entirely "learn new skills". Sure, they're all programming skills, but we're still really good at picking stuff up as we go.

Re: Sales - I'm actually a "Solutions Engineer", which is one of the many versions of sales-supporting-engineer roles, others being "solutions architect", "customer engineer", "sales engineer", "field engineer", etc etc. Depends on what kind of thing the company makes (AWS is def SAs, for ex, while stuff that gets physical installs is FEs (AFIAK)), the balance between pre-sales and post-sales in the role, etc. I love it, and if you like face-time with people while still doing tech, you might as well. I kinda view the whole category as under the motto: "My job is to deploy our technology"

You don't have much control over mistakes they can make, but you have a better control on your own mistake or what you can do to prevent them from making some of theirs. By focusing on you and what you can do to help, you're being a positive force in the team. When other members of my team help me or do actions that prevent mistakes I can do, I'm so happy to give back to them. If the only thing they do is complain to me, well you just sap my motivation.
This, one thing I've heard about Michael Jordan wasn't just that he was amazing at the game himself, but that he was inspirational to his entire team. He pushed them to do better because he pushed himself to do better.
Stoicism: Worry exclusively about the things you can control. The only things you can control are your own intentions. The behavior of others, the results of other's actions, and even the results of your own actions are all outside your control, and it is therefor unproductive to worry about them.
I had some really good luck early career influencing people. It took me quite a while to realize how much of that was luck and not talent.

Teams are often more concerned with coherence than objective 'rightness', and they're not wrong to value it, but at the end of the day that really means that you should look elsewhere instead of being some sort of... I'm not sure what you'd call it. Vigilante?

I should be looking for a new job, but I'm staying where I am because gestures at the world but also because I'm still figuring out how to ask about my non-negotiables during an interview, instead of assuming I'm going to renegotiate them once I start. You can talk junior developers into a lot of things. Senior developers push back.

Which one on the team is You though? It cannot be 'not the other guy' forall guy.
This totally makes sense, if you also find some benefit (personally or societally / globally) by taking ownership of the problem.

If you're a) not going to get paid b) not going to materially improve your prospects c) not going to be helping the world etc then I find that digging in and trying to save everything by making it your problem is a recipe for extreme frustration which will show up clearly in your interactions with other people whose job it probably is to do the things you believe are not happening correctly (managers, executives, other team members)

Make sure before you make this leap that you're doing it for the right reasons, either for the benefit of the world, or for yourself and not just because you work someplace and a blog said "you are responsible". Stay mentally healthy. Save your energy for the important stuff.

Obviously this message is extremely important for smaller places, startups, etc and in your personal life. Recognize excuses. Be proactive. But there's a balance when it comes to your work life.

Not even mentioning that the approach the author takes assumes that everyone is a rational player and will not actively try to undermine you and ruin your career if you (even inadvertently) point out that their project may have flaws. I’ve learned that the hard way.
This feels somewhat relevant as a developer who's moved into more of a leadership. When you're a younger dev, you get ahead by pumping out code, hitting deadlines and making stakeholders happy. As you transition up the chain, you need to start depending on the other developers to pump out the features and you're going to find a lot of them just don't care as much as you do/did. It can get very frustrating at times.

This article hits the point exactly, I've learned all you can do is lead by example and hope for the best while trying to constantly improve your own performance.

This isn't wrong, but isn't really actionable either. I get that this article is marketing for the author's services, but we can take these kinds of problems and think more directly about how to fix them.

As an example, if the CEO (or any other leader) says "No" I'd suggest exploring further the communication patterns that can help change a "No" answer into a productive discussion -- splitting fact from opinion, understanding the motivations of all the players, and knowing the leadership team to understand what communications styles work best on each of them.

Likewise, when the team doesn't agree on what is important, making some members feel like the others don't care about the product and/or the quality... make sure you are working towards the same goals, and measuring each other on activities that support those goals. If your team isn't defining the product correctly, or working on the right items, maybe there was never any solid alignment on the product direction in the first place. Do you put the customer above the tech? Are you in a place where you need to speed to market and tech debt is acceptable? Are you still seeking product-market fit, so experimenting on new tech and approaches does have more value than adding a new feature to a mismatched product?

Those are the types questions to ask - and again, it will lead to understanding the motivations of all players involved and syncing up with the higher-level business strategy.

I’d be hesitant about this. Author is from Israel. This is very much an Israeli cultural thing where they believe the individual is the issue, not the team. Maybe this stems from mandatory military service or something else - it’s not clear to me. This leads to whoever has an authoritative position dictating everything. It’s not that teams get together and decide things as a unit, there’s a dictator somewhere.

But then the dictator makes it seem like it’s what the entire team wants. And says if you go against “the team” then you’re the issue. Meanwhile, no one may agree with the dictator but can’t speak up due to whole team mentality and speaking against is breaking the team values. Effectively, you get gas lit into believing you’re the only one with an issue when possibly all your other team members feel similarly.

It’s a weird culture as an American. It definitely doesn’t prize the rebel in any sense. (I’m not saying being a rebel is inherently good) I’m not saying America doesn’t do this either.

I’ve seen a lot of group think because of this and essentially one person ends up dictating everything while making it seem like it’s really the teams culture. Eventually, people might believe it’s the team culture and forget what they even wanted in the beginning and just learn to live with suboptimal decisions that they didn’t even make. Overall, I’d be hesitant to go against the flow if you’re going to be in a company consulted by this guy. You’ll probably be fired for bringing up anything counter to “the team”. Seen it happen.

I’m sorry, but wut? I’m OP. I work with companies globally, first of all.

But Israeli culture, in high tech, is the exact opposite. Even in my military service, I was arguing against a Lt. Colonel when I had 4 months of experience. Chutzpah is what is driving half of the local startups: CEOs have to convince their teams that regularly poke holes in their plans and ideas. Not all companies are that way, but for years I’ve been hearing from people I tend to assume too many people would speak up. First time I’m hearing I have a bias towards the other side.

After reading this post I don’t see any themes that would prompt me to make the logic jumps made in your comment.

Sure, YRMV implementing advice from any online article.

> Why would the CEO allow something if you failed to make an articulated argument?

"If I just said the right thing." is an illusion of control trap, which eventually leads to you blaming yourself for other people's actions, which is far more unhealthy than the deflection the author is calling out.

I lost count of how many times a particular boss tried to tell me "you can't fix stupid". He was the first person to leave the team, and he actually moved across the country (which I have trouble interpreting as anything other than a Grand Gesture. Fuck this, I'm outta here.)

"Its not a team, if its working with hot magma"...

When everyone is experienced/educated/elevated past that point (crescendo cooling), you have a solid team and/or company (four-leaf unicorn rare).

I immediately thought of "Hail Mary" strategies when reading the article, which keeps the talent/veterns safe and highlights a possible "why" its only an organizational chart arrangement and not a team environment.

If its an org chart arrangement, its definitely not you (but as other comments suggest, you still have to perform/produce/thrive regardless of disfunctions or detached from RL management shuffles)...

I agree with the general sentiment of taking ownership (especially if you are self-aware enough to realise the coping pattern of deflection). The example of a CEO not allowing something if you fail to make a well-articulated argument is obvious, but the complement may not be: they can still decide against a well-reasoned argument. The dynamics get much more complex when you have a larger organisation where participants in a decision may have competing incentives and goals.

I think the ownership action in extreme cases is best summarised by the simulation in WarGames (1983): "A strange game. The only winning move is not to play.". There is lots of interesting game theory (which is probably a digression here), but the Prisoner's Dilemma is a fun starting point if anyone is interested in an academic side trip: https://plato.stanford.edu/entries/prisoner-dilemma/.

> they can still decide against a well-reasoned argument.

Suer, but then you did what you could. I think the main point here is 'do your best instead of giving up prematurely', not 'slam your head against the wall until the wall gives in' ;)

> There is lots of interesting game theory (which is probably a digression here), but the Prisoner's Dilemma is a fun starting point if anyone is interested in an academic side trip: https://plato.stanford.edu/entries/prisoner-dilemma/.

Game theory is highly interesting. There is also the book "Networks, Crowds and Markets", which is free to read online [0] and well worth a read. I've actually had an university course about it.

[0] https://www.cs.cornell.edu/home/kleinber/networks-book/netwo...