> There's nothing wrong with the agency business, but it'd be a smart bet to use at least some of the proceeds into building something long-term. Some agencies, notably 37signals, have been quite successful doing that. Most, though, never do it.
I've been part of a few agencies that spent a lot of time and money trying to build products. It is a different focus and hard to pull off when you are used to the hustle of agency culture.
Two better options in my mind:
- selling a recurring service related to the agency's work (hosting for a webdev agency, for example)
- productized services related to your work that are more custom than a full product, but more scalable than typical agency work
> You can very well state "I'm going to do XYZ because of [REASONS]. I'm going to do XYZ on [DAY N]. If anyone objects or has any reservations, please reach out to me."
Love this phrasing.
As other comments have mentioned, you probably don't want to go into the full depths of reasons in the email. Rather have a high level summary with a link to a long form doc or RFC. And of course, the appropriate level of detail depends on how big and wide reaching the action is.
IME you often get a response that seeks to turn it into s “conversation.” Keeping everything super vague but something that can be pointed to on s paper trail as “I expressed reservations”
Neither approval, nor disapproval just straight up quagmire.
There’s no silver bullet to getting things done successfully in any large organisation of humans.
> Neither approval, nor disapproval just straight up quagmire.
That's ok. Setup a meeting with said stakeholder, clarify your position, ask for input, and in the end ask straight up if they have any objection. Save the meeting minute and send it to everyone who attended the meeting.
They need to put up or shut up. Playing games does not work.
Objection? No. Concerns yes, as have been detailed at length. No good trying to ram it through without doing the work. We can't manage the project for you etc. etc.
There is no silver bullet. You have to treat each one in the way that works for them. Those who do it well, it's a talent.
Or have the compromising photos of the boss and copies of the bank statements so he's scared and backs you publically always and then just roll anyone who isn't effusively enthusiastic. That works too. Wouldn't recommend it.
I don't see how this works in the context of scrum as I've seen it done, except in the weak case of you getting to raise the ticket of whatever topic you'd like.
I guess you could ask for no around specific implementation details too? So if you are working on ticket XYZ that could be solved in N ways, you could pick one that might be a bit out of the norm (but still solves the problem) and 'ask for no'.
Yes, but NATO members are not bound by contracts that classify them into superiors and subordinates. Whereas at work, you'll have some form of contract in which you agree to taking -- and usually: soliciting -- direction from your superior or client. Silence procedure works between equals, where each party is required, from the get-go, to (a) announce their intent to the shared message bus, (b) diligently listen to the shared message bus, and take action whenever necessary. The communication pattern between manager and report is totally different; the parties are not equals there.
Lots of nuance here! I agree that different kinds of orgs and projects and decision scopes all play a role. As does trust between you and your manager, knowledge of what requires feedback, what doesn't, and what is risky enough to require an affirmative response.
But having a bias towards action has been really important for my career. That doesn't mean I haven't flamed out at times, but when I found the right environment with the right level of trust, this technique was super helpful to me.
Author here. It's a deadline for feedback, which is why I used the word. Other comments have called it an ultimatum.
Both of those might be unnecessarily aggressive terms, but I'm not sure what another one-word term for "time something is going to get done unless you object" is.
It's only a deadline for feedback because after you do it, obviously, feedback can no longer be provided. Timeframe might be less aggressive than deadline.
> One of my managers used to tell me this, instead: ask for forgiveness, not permission. That one seems way saner to me.
So you are suggesting making the change without consultation and then waiting for it to be discovered?
I guess that makes sense for certain kinds of situations, but the ones I can imagine don't sound very pleasant. Maybe I'm missing something. What is an example of a situation where you'd take this approach?
It’s really about (a) the wording (b) the level of risk.
For something that isn’t risky, I trust my reports to make reasonable decisions and wouldn’t benefit from the “I’m going to do this tomorrow unless you say no” approach. Instead, they can just tell me they’re doing it (or let me know after the fact, or add/FYI me on the code review, or not even mention it, depending on what it is).
For a decision that is more important/higher risk, they should get affirmative agreement rather than just hoping that I see the ultimatum and silently approve.
That’s why I’m with the GP that the ultimatum-with-deadline doesn’t seem like the best choice in any situation.
Thanks for the feedback. I guess I'd put the 'ultimatum-with-deadline' in between the two risk profiles you outline--something just on the edge of risk.
> Just hoping that I see the ultimatum and silently approve.
I never would have thought of this as an ultimatum--to me it's more like a 'default decision' that makes my manager's life easier while still looping them in and giving them control should they choose to exercise it.
But now I can definitely see how it might be seen as one, depending on the type of decision and the relationship between employee and manager. I should probably update the post to say that you need a degree of trust and alignment for this technique to work; you shouldn't roll this out on the first day.
The advice refers to situations where you, the report, are both able and (well-informedly) willing to take full responsibility. "Ability" here means that, if your decision backfires, you can revert it, and/or contain the damage otherwise. Otherwise, you may be willing to take responsibility, but are unable to. In other words, this piece of advice applies to things that are ultimately under your control.
The background is that, even when something is (mostly) in your control, you may be tempted to ask for permission, in advance, just to distribute the responsibility to others (shift the blame, cover your ass). That delays things, and usually the manager will sense that they got burdened with the request-for-permission somewhat needlessly. In those cases, it's better to take initiative, and be accountable later on, because the latter is in your power, in the end.
(Of course, if you and your manager have dedicated time slots anyway, then bringing the topic up is prudent, as it will not require them to scramble for otherwise unallocated time.)
Conversely, if containing the potential damage is indeed not in your power, then you shouldn't go ahead without explicit permission. For things where you simply can't bear responsibility, a timeout from the approver is not a default "yes", but a default "no". If you can't bear responsibility, then you need explicit signoff from someone higher up that, should shit hit the fan, they will bear responsibility on your behalf -- and so a timeout is meaningless (it doesn't give you what you responsibly need).
Whenever you can afford to interpret a timeout whichever way you want, then you don't need to ask the question in the first place (--> don't ask for permission, just revert/contain the damage, if needed). Otherwise (--> the potential damage is beyond you), you need an explicit "yes" (which is the only case when you're off the hook).
The problem with your suggestion is that it assumes that you, as a report, are in a position to set deadlines for your superior(s); in other words, to allocate their time and priorities. Usually the exact opposite is true (by contract): it's your manager who sets your priorities. You can consider their (repeated?) failure to respond timely a true failure, but that doesn't give you the right to do whatever you want; it would be in bad faith / a form of vigilantism. Your option is to leave that manager.
That's a great point. There needs to be trust between the person doing this and the boss. That trust is earned.
You also need to pick the right scope of problems--not too big. If you are one month into a new job and use this technique, but the problem you are trying to solve is deep rooted and you don't understand it, you'll burn effort and credibility.
It also makes sense to respond to feedback from your manager, as you suggest above. Some managers may hate this (see other comments, including one that would fire anyone using this technique). In fact, you could even explicitly ask how a manager wants to weigh in on decisions that you feel are in your purview but that they might have feedback on. (Drawing out a manager's readme, as it were.)
Docs: https://warewulf.org/docs/main/
reply