[lostcolony]

To change anything you have to be responsible, empowered, and knowledgeable about it. If you only have one or two of them, seek out the others. If you can't attain all three, stop worrying about it; you can't change it.

Transparency leads to trust, but also can be abused. Be transparent in incremental steps, so that you still build trust with those that are trustworthy, and so you aren't hurt too badly by those that aren't.

Failures of people are as often due to the environment they're in as they are the people. That can be useful to not judge colleagues too harshly, and also to remind yourself you are good and capable when you find yourself in a job/role where you're unable to function.

The way to build successful products is to care about them. Stakeholders that seek to explain problems they're trying to solve and why the matter will get results; stakeholders that try to dictate solutions to dev will not. Seek out places that recognize the devs job is the 'how', and the rest of the business' job is the "what".

People who say "we're one team" and "it's not us vs them" are to be avoided. If the groups they're talking about were truly one team, such statements would not need to be made; making them is trying to band-aid over issues and misalignments rather than address them.

Be kind. Even useless assholes can become allies if they see you going out of your way to be kind to them.

[jumaro]

Thanks a lot for your comment. There's a lot in there. In fact, I added most of it to my personal collection of quotes.

[veddox]

> To change anything you have to be responsible, empowered, and knowledgeable about it.

What do you mean by those that?

[lostcolony]

So I'm actually planning on writing a blog post on it which at some point I'll share, but, basically -

Responsible: You're the one affected by something, and the one expected to respond to it (first, possibly only). You have incentive to prioritize it highly and deal with it. I.e., if anyone cares about it, it's you. So, for instance, an alert goes off that a service is down. While it may affect the whole company, if it's your service, -you- are responsible for it. "We're all responsible for it" is not true; who feels that sense of ownership, who is going to have to write the post-mortem, who would be blamed if it's a blame culture, etc. Or, more succinctly for this example, "who is waking up to deal with it". This matters because it's too easy to blur lines of responsibility; is the director of the department responsible for it? No; while long down time that leads to revenue loss may require his presence in meetings and things, he isn't expected to actually go fix it himself. He's responsible for hiring the right people, and setting the right policies in place; NOT answering the Pagerduty. Broadly sharing responsibility is an anti-pattern, and, frankly, a lie; it's why "decision by committee" and "too many cooks in the kitchen" are bad ideas.

Empowerment: The changes you need to make, you can make. This might be in terms of organizational authority, or actual technical permissions. In the prior example, if I can't access prod enough to fix the issue, I'm not empowered. What I AM empowered, and responsible, to do, is send emails/call someone who can make the changes. If I don't know who that is, I'm not knowledgeable; I can do what I -am- knowledgeable of (send an email to the whole department? Post it in a seemingly relevant Slack channel? File a ticket?), and then wipe my hands of it until I can either acquire new knowledge (who to reach out to), or new empowerment (the ability to make the changes).

Knowledgeable: Knowing what needs to be done. This might be a business need, or it might be technical. Technical is 'easy', in that you can usually go learn it on your own, but the business is harder, as it comes from somewhere that may not want to work with you, or that you can't identify. As an engineer, I might be responsible and empowered to build things, but I'm not knowledgeable about -what- the business wants/needs; I have to get that information from product or other stakeholders.

If I know what and how something should be done, I'm responsible for delivering it, and I'm empowered to actually go get it done, I can (and if a good employee, will) do it. If I'm missing any of those, I can't; I have to get the missing piece(s). This sounds obvious, and it kind of is, but pretty much every organizational problem I've run into can be framed using this (though sometimes with slightly hand-wavey definitions).

Dev is blocked on product; dev doesn't have the knowledge to know what to build. Go to product; they don't have the knowledge either. Further, they're not empowered to prioritize getting that knowledge; instead, they're spending all their time on what they feel responsible for, say, unrelated meetings, UX design, and documentation of status. A fix: change what product is responsible for (from "gather status and respond to upper management -> unblock dev"), and empower them to prioritize their time accordingly.

Dev feels releases are a pain in the ass; they are responsible, but empowerment to actually push to prod resides in an ops team. The ops team has the empowerment, and the knowledge, but they don't feel responsibility; if a release goes bad it's their issue, but if a release doesn't happen it's the dev team's issue. A fix: Either empower devs to release to prod without the ops team's involvement, or make ops feel responsible for releasing (i.e., time between dev says "we want this released", and when it gets released, is a factor on how the ops team's performance is evaluated).

Determining what is missing provides direction in what to address to solve the problem, and if you're unable to, moves it from something to agonize over, to something to accept as not something under your control.

[ellimilial]

This really stuck a cord, thank you for sharing.

[thunkshift1]

+1 , some excellent points in there