My opinions became trusted in decision making because I spoke up only when I had well-founded thoughts on things I understood. Now that I'm looked to for opinions on a wide breadth of topics, apparently "let's find (or train) someone qualified and ask them instead" is not a decision anyone wants.
Telling me to just be as useful as a generalist doesn't work when it was the specialization that made me worth listening to. It's a setup for failure. And I know the platonic ideal of management understands the team has different capacity on different topics and yadda yadda yadda, but I have a job in reality.
> Telling me to just be as useful as a generalist doesn't work when it was the specialization that made me worth listening to. It's a setup for failure.
True, you will fail to make the correct decision occasionally. But you and the article are making the same mistake. You are thinking failure is the end of the story. It's not.
As a senior engineer, you're goal isn't to make perfect decisions. Your goal is to learn how to make better designs over the long term. There is really only one way to do that. Make lots of design decisions, and find out which are best. The remainder (the bulk) will be failures. So if you aren't failing often you aren't moving forward.
Or to put if another way, if you refuse to commit because of fear of failure, you are refusing to move forward at the speed you should be moving.
A lot of things flow from that. Mistakes are costly, so you have to weed them out quickly (and consequently you learn from them rapidly). That means lots of visibility, it means finding ways to test ideas on small projects and not make one large "make or break" bet, it means change control so you aren't overwhelmed by your failures.
Ultimately it means engineering leadership, which is what a senior engineer should be doing is about knowing how many mistakes you should be making and how fast you can be making them. The answer isn't 0.
He will make many errors outside his area of knowledge. As many as anyone else. They won't be better in the long term. He is senior in his area. And just like anyone else, he is junior outside of his area.
It is just magical thinking to expect some long term benefit from insisting on him bullshitting his way through something he don't understand much.
I genuinely curious here, if you are the trusted decision person, is it not accepted if you say “the decision is we do not have enough information at this time to make a decision, thus we need to [research x/do a timeboxed poc/drill down on y part of system/etc]”?
But I also just read an article calling out my non-committal cowardice.
I'm OK-enough at managing up these days that you could weasel word around and say it doesn't apply to me. But it's a failure pattern of management that I've seen happen to more than just myself.
I’ve been in your shoes. I found three options to work (in worst to best order):
1) I become an “overnight expert” at the expense of my work life balance and frankly the system architecture long term
2) Pushed back on management with tangible risks: a rough estimate to implement is XX and we are not confident in the solution so that could result in rework cost or worse long term scalability/maintenance cost. We propose outside (could be another expert on another team) consultation to close the risk gap.
3) We need to reassign resource X who is our most knowledgeable in adjacent tech, this takes them off feature Y and we will do a spike of duration Z to verify our approach.
When you do #3 enough your management will appreciate you using existing resources, providing the trade-offs, and you will also up skill that person.
1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.
2. Many orgs have a poorly managed culture around disagreements on technical design and some folks just don't want to put up with that kind of friction when the difference between using approach A or B is real, but not going to topple the project either way so why waste that energy fighting that kind of battle?
EDIT: Simple analogy
> Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? Either is fine with me; I just want to go out to dinner and have a good time. I am happy with either Japanese or Indian!
Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time!
It's like asking me to choose GCP, Azure, or AWS. Does it really matter if there's no constraint? I can and have delivered systems on each of these platforms. Am I cowardly for not committing and not being a diehard for one of these when there are no NFR's that favor one over the other?
> 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.
I understand where you’re coming from, but in my experience this only leads to deadlock on both sides with nobody moving forward.
The best engineers I learned from will push forward with a decision and also communicate the tradeoffs and consequences upward. This breaks the stalemate and forces the “business side” (which shouldn’t actually be separate from engineering) to either accept the decision or propose an alternative.
The game where engineers view themselves as in a standoff with “business side” people and nothing moves forward has been a path to a slow decline everywhere I’ve seen it happen.
Of course you push forward as a team, committal here I take to mean between two or more engineers trying to debate a technical option.
Why must every engineer have an opinion on every technical decision if there are no hard requirements? I may only have an opinion if there is a hard requirement.
I gave an example below.
> Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? I just want to go out to dinner and have a good time otherwise; I am happy with Japanese or Indian!
Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time!
It seems pretty clear to me that not every engineer must have an opinion on every technical decision to which they should commit when sometimes, the choice doesn't matter and it's easier to let the individual with a stronger opinion drive the choice because the other option is friction for no reason and expending energy debating made up constraints.
> Some engineers think it’s a virtue to remain non-committal in technical discussions. Should our team build a new feature in an event-driven or synchronous way? Well, it depends: there are many strong technical reasons on each side, so it’s better to keep an open mind and not come down on either side. This strategy is fine when you’re a junior engineer, but at some point you’ll be the person in the room with the most context (or technical skill, or institutional power). At that point, you need to take a position, whether you feel particularly confident or not.
That is the very first paragraph of the article. Take up your complaints with the author of the article; not me!
I'm not sure how that paragraph gave you the understanding that "every engineer must have an opinion". It explains that the most senior/influential/knowledgeable engineers must have an opinion because they're the ones making the decisions. In that context, the decision is the opinion; not having an opinion is the same as not deciding, which is obviously bad for the person/people responsible for deciding.
This strikes me as parallel to "the best way to get the answer to a question online is to post the wrong answer, and people will flock to correct you".
As for "non-functional requirements" ("NFRs") Wikipedia suggests examples:
1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time).
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.[5][6]
Sometimes "the business side" has the expertise required to define these. Sometimes they don't, and engineers need to do it, using whatever knowledge of the business they have. "The business side" often will not take responsibility if the system is insufficiently testable, maintainable, extensible, scalable, secure, or usable, instead blaming engineering.
> Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.
Doesn't this necessitate asking the questions to get the NFRs out? You don't need to be non-committal then. Just say "we need answers to these 8 questions before we can estimate, as they will make a massive difference."
You'll get them...at some point. It may be even at the very end when the customer complains that it doesn't quite work the way they intended and it turns out, they never fully specified exactly how it was supposed to behave!
If you haven't experienced this, you haven't truly lived the enterprise software delivery reality.
Of course it can happen that way :) But as an engineer you have to decide on the NFRs if you don't ask anyway, so why not ask them and declare them up front if you don't get an answer? Then you can point to the problem is down the line and say we need X time to increase this NFR.
Sure, but you've missed my point: in that case, some engineers just don't want to have that debate because there's very little point in expending that energy.
Best strategy would be to declare NFR using engineer’s domain knowledge without waiting for clients to tell them. This is conditioned on engineers knowing domain sufficiently well. Which is a requirement for effective work anyway.
I feel like a broken record now, but once an engineer decides to "declare NFR", then it's a situation where it's one opinion versus another not driven by actual requirements and I contend that this is a point of friction that some engineers just do not have the energy for when there are no real requirements -- just fabricated ones.
So does the engineer sit there and do nothing until they know the NFR, or do they decide on the NFR themselves and build to that?
If the former, fair enough? If the latter, what energy does it take to send that NFR in an email saying "This is what we're building to; you have 7 days to debate it."
> So does the engineer sit there and do nothing until they know the NFR, or do they decide on the NFR themselves and build to that?
Imagine you are going out to get dinner with a group of friends. "Hey, Antoine is allergic to shellfish and Lin is a vegetarian" are hard requirements. Now that I have some hard requirements, I may have input on options that fulfill those requirements because there are real constraints around which the choice must be made. With no requirements, I don't really care where we eat, I'll go with whomever has the stronger opinion; I'm really interested in having a great meal together -- why ruin vibe over whether it's Japanese or Indian?
Is there really a need to debate whether it's Japanese or Indian? Am I a coward for not taking a hard line on Japanese being the clearly superior dining option? Why cause friction when both get the job done? But if Antoine and Lin are coming, then I will take a hard line because Antoine is allergic to shellfish and Lin is a vegetarian so let's pick Indian because I like Antoine and Lin's company.
> ...send that NFR in an email...
Yes, this is exactly how real world software engineering works. Just send the NFR in an email and call it a day.
> Is there really a need to debate whether it's Japanese or Indian?
This analogy is wrong - you're not the diner. You're the chef. You're going to cook something. You need to pick anyway; why not say what you're picking in advance and give people a chance to object? Is it really just something you can't muster the energy for?
> simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.
"We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." is a completely valid decision to officially make. And it helps with planning and development of related code. "I don't know, because of missing NFRs" is not a decision though.
Generally speaking, "we're scaffolding/not implementing/delaying this part" is something you can do with functional requirements, but not with non-functional requirements. Changing non-functional requirements like security, maintainability, or testability generally requires rewriting the whole system from scratch, incrementally or otherwise.
Not committing: "I don't have enough info, don't know".
Decision: "We can only finish it once X is known. Until then we assume it behaves like (…). For code that relies on it, we're prioritising flexibility to change over perfect solution at this point. Y is responsible for announcing when X is known."
I find there's a good way to not commit, slightly different from this article.
There's a non-committal way of designing software that I think we should all strive to follow. It's not things like "let's use an ORM so that we can swap the database later" or "let's write abstractions over everything so we can swap everything later". It's more that you're trying to keep the code as simple and static as possible, naively doing the exact business function, and rarely generalizing. There are a few practices I've picked up over the years for non-committal architecture of this kind (for example: doing more at "build" time, passing the functions what they need instead of what you have, keeping IO in shell layer, and a few more). The goal is not to end up with a codebase that has foretold all the possible futures, but that implements just what it needs to do now in the most straightforward way, such that it's easy to read, understand, and change. I think this kind of non-commitment is the ideal to strive for. The less committed you are in this way, the easier it remains the change the codebase as it evolves, the less shackled it is with over-engineered "solutions".
It's deceptively hard to do this in practice. Everybody wants to implement their over-engineered "system for doing a thing" layered on top of the programming language. Sometimes we forget that the programming language itself is a great tool for expressing business logic.
If you have trouble committing to an option, it's usually because the options are equally good as far as you know.
There are two ways to go about this:
1. If the stakes are low, you can just pick one option at random and commit to it.
2. If the stakes are high, come up with a way to reduce your uncertainty around the options. Set a time limit, and perform an experiment that will inform your decision. If that experiment doesn't conclusively settle the options, just pick one and commit to it.
In general I don't have a problem committing, but there's also some solid rules of thumb that you can follow, for example: "if all else is equal, take the option that leaves you the most opportunity later".
However I have also employed Weighted Decision Matrices[0] to a pretty high degree of success if they're undertaken seriously and the outcomes taken as a learning exercise.
Ironically when I employed the Weighted Decision Matrix I often didn't like the result, which was equally telling!
Also, getting better at intuitively analysing these situations and picking an option is part of what it means to gain experience and become better at what you're doing. If you're doing things right, you will start out finding it difficult to pick an option when you're new (to programming, to a particular domain, to a particular technology, whatever), and as you get better, you 'll develop a "taste" for what seemingly-equivalent solution you prefer.
I found using "architectural decision records" to be helpful; it's not a panacea and I'm sure there's other approaches, but the gist of it is that you make a document, write down your thought processes, consider the different options (demonstrate you did your homework), and get the team together to proverbially shake hands on it.
It's not set in stone; if anything, the writing reflects "what we know right now" about a problem and its possible solutions, but it's a message to the future when either the context of the problem changes, the problem is better understood, the underlying assumptions and/or requirements change, or something changes in the solution.
It's both committing to a thing "in the moment", while leaving it open for updating down the line. It's much preferable to someone just picking something because of gut feeling / hype / assertiveness / cool factor which is how a lot of projects end up in the bin after a few years.
I tend to do something like this for most tickets I work on (that have choices to be made). I work through all the details and make sure I understand them all, then note what the difference choices are for various things. Where there's a choice to be made that requires "customer" input but that I have a pretty solid idea what the right choice is so am going to move forward on that, I'll make note of it, etc. It also gives me time/space to document ambiguities in the requirements.
I am.. overly verbose in tickets. That being said, it's come in handy many times in the past; some of which are me trying to figure out why I made a specific choice.
So am I, and I'm proud of it. I see a GitHub issue thread as effectively infinite storage for the ideas, decisions and research behind a change I make to a codebase.
> Well, it depends: there are many strong technical reasons on each side, so it’s better to keep an open mind and not come down on either side.
My heuristic in this case is just to go with whatever option is simpler, and gives us the most flexibility to course correct in the future if we turn out to be wrong.
Basically make it clear that in the absence of sufficient data to decide on the best course of action, we are being intentionally non-committal. Then outline what new information would be required for us to make a more informed decision one way or another (e.g. an actual customer asks for the hypothetical feature that we are discussing, or performance is insufficient, etc), and what actions and effort we would need to change course. When put like this, I find that everyone in the room usually ends up pretty satisfied with the plan.
A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all.
The tricky part is estimating consequences of these technical decisions. If you’re more or less confident in your estimations, and you believe the technical decision being made has severe consequences (not just to the product, in the long run development process is equally important), only then is the time to commit.
> A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all.
Until people start touching each others' code; then it makes sense to pick one or the other and stick with it.
Ironically, when I implemented .editorconfig at my job, (code formatter and checker in CI), I decided that we were going to pick one or the other. I did a little bit of research, and found the silliest little detail that made me pick one over the other.
I won't say what the detail is; but I will say it's a lot easier when CI enforces one approach, and I can run a simple code reformatter if I accidentally violate the rule. Otherwise, it's super-annoying if, every time I get into a new area of the code, sometimes its tabs, and sometimes its spaces.
With style, consistency matters more, so ensuring everyone either uses spaces or tabs but not both is helpful. I don't think being willing to commit means you need to decide on which one is used, unless you are a designated tie breaker and others cannot come to a choice.
I think this article still applies there just in a different way. If:
- you're working on a project with other people and
- you're at the right level to make such decisions and
- people compete with different / conflicting formatting
Then it is important that you make A decision. It can be "we're using my preferred style", or "we're using gofmt/rubocop/black/whatever", or something else. But any of them is going to be better than future waste of time in reformatting, merge conflicts and people arguing.
> The tricky part is estimating consequences of these technical decisions.
Estimating or knowing; your tabs vs spaces for example has been tirelessly discussed for years, but the consensus there is that consistency is important, else your git diffs will include tons of churn where tabs are converted to spaces or vice-versa by people's editors.
> However, I don’t force people on my team to also use tabs
Wait a minute. Does that mean you are using mixed tabs and spaces depending on file author? Or are you just saying you start projects using tabs but don’t enforce it for others’ new projects?
> "If you don’t take a position, you’re tacitly endorsing the decision that eventually gets made"
This is important in a lot of situations, not just engineering.
Variants of cut-and-choose can be useful here. If you flip a coin to make the decision for you, do you object to its outcome? If so, you've picked the other one.
It's also worth having a discussing about responsibility, power, and accountability here. Conventional management structures are supposed to align this, but that rarely corresponds to reality.
We have 5 different engineering teams in our company.
The 4 are being led by benevolent-dictator-type of engineers, the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates.
Two of the 4 teams have become so big and independent, that the dictator-leads no longer need to participate in the d2d operations/decisions, to the point where they now work mostly on individual RnD projects.
The other 2 are small specialized teams, whose members have become domain experts in specific areas, to the point that they can talk with the business and move on development, with little need of interaction with their lead, and absolutely no need for a PM/PO layer.
The only team that struggles to perform is the one with the non-commital lead. It became so bad, that the current discussion is to dissolve the team, and have it's members/responsibilities be absorbed by the 2 big ones.
> the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates.
This is a very common failure mode for first-time leaders and managers. They optimize for minimizing conflict and want everyone on the team to like them.
A difficult lesson to learn in leadership positions is that you can’t make everyone happy and you can’t avoid every conflict.
Hyper-democratic leadership styles don’t work outside of very small and tight knit teams where everyone was already on the same page.
Someone needs to pull that person aside for some intense coaching to train them out of the mindset of people-pleasing and into the reality of getting work done. It’s not a fun transition but it needs to be coached. This is one of the turning points where many people realize they don’t want to be in leadership or management roles because the difficult decisions and uncomfortable conversations are in conflict with their personality.
Thinking about this more. I guess my n=5 observation is that committal engineers tend to have specific expectations about the performance of their teammates, and hence produce similarly performing teams to them
Whenever I face this, in my own analysis or others, I apply the "let's find out" tactic. Instead of doing nothing I'll propose that we do X which I surmise as an option that a) is non-destructive and reversible, b) has a chance of working out. [You can add your own criteria, e.g. fast/easy, simple, etc] At the very least we'll learn something. When someone else is stalling, I'll phrase it something like "Unless someone has specific reasons against investigating X, I propose we prototype it and see where it goes." If still unsure, prototype Y. After that you usually realize there's not much point prototyping yet another an simply choose one and see how far it can go.
Almost all software engineering systems are reversible. If a decision can be unmade later I find is a lot easier to accept committing to a decision despite not yet being 100% confident it's the best approach.
This works in collaborative decisions too: if someone still has doubts, ask them to "disagree and commit" to the new direction but promise them that you'll evaluate if it is working out in a fixed time period - drop something on the calendar in two weeks time for example.
Indecision paralysis is much more harmful to a project then picking an option that later turns out to be suboptimal.
The question "Is this a one-way door or a two-way door?" can eliminate that paralysis in the majority of cases where, as you point out, the decision is reversible.
I strongly support this approach. By voicing my thoughts, including any weaknesses and unknowns, I invite others to contribute their insights. This not only helps to address gaps in my knowledge but also encourages a collaborative environment where other engineers can engage in discussion and decision-making. I believe this dynamic is a sign of a healthy workspace, where open communication and teamwork are valued.
The flip side of this is that engineers who won’t commit aren’t trusted and thus have low status on the development team. It’s easy enough to get promoted over them if they haven’t been Peter Principled yet.
Passive Non-Comittance (I will need more information, more prediction power, more certainty about future events) ironically is still more expensive, then active Non-Comittance (We just built all the implementation-components in such a way they can be exchanged later).
My opinions became trusted in decision making because I spoke up only when I had well-founded thoughts on things I understood. Now that I'm looked to for opinions on a wide breadth of topics, apparently "let's find (or train) someone qualified and ask them instead" is not a decision anyone wants.
Telling me to just be as useful as a generalist doesn't work when it was the specialization that made me worth listening to. It's a setup for failure. And I know the platonic ideal of management understands the team has different capacity on different topics and yadda yadda yadda, but I have a job in reality.
> Telling me to just be as useful as a generalist doesn't work when it was the specialization that made me worth listening to. It's a setup for failure.
True, you will fail to make the correct decision occasionally. But you and the article are making the same mistake. You are thinking failure is the end of the story. It's not.
As a senior engineer, you're goal isn't to make perfect decisions. Your goal is to learn how to make better designs over the long term. There is really only one way to do that. Make lots of design decisions, and find out which are best. The remainder (the bulk) will be failures. So if you aren't failing often you aren't moving forward.
Or to put if another way, if you refuse to commit because of fear of failure, you are refusing to move forward at the speed you should be moving.
A lot of things flow from that. Mistakes are costly, so you have to weed them out quickly (and consequently you learn from them rapidly). That means lots of visibility, it means finding ways to test ideas on small projects and not make one large "make or break" bet, it means change control so you aren't overwhelmed by your failures.
Ultimately it means engineering leadership, which is what a senior engineer should be doing is about knowing how many mistakes you should be making and how fast you can be making them. The answer isn't 0.
He will make many errors outside his area of knowledge. As many as anyone else. They won't be better in the long term. He is senior in his area. And just like anyone else, he is junior outside of his area.
It is just magical thinking to expect some long term benefit from insisting on him bullshitting his way through something he don't understand much.
I genuinely curious here, if you are the trusted decision person, is it not accepted if you say “the decision is we do not have enough information at this time to make a decision, thus we need to [research x/do a timeboxed poc/drill down on y part of system/etc]”?
> is it not accepted
I haven't been fired, if that's what you mean.
But I also just read an article calling out my non-committal cowardice.
I'm OK-enough at managing up these days that you could weasel word around and say it doesn't apply to me. But it's a failure pattern of management that I've seen happen to more than just myself.
I’ve been in your shoes. I found three options to work (in worst to best order): 1) I become an “overnight expert” at the expense of my work life balance and frankly the system architecture long term 2) Pushed back on management with tangible risks: a rough estimate to implement is XX and we are not confident in the solution so that could result in rework cost or worse long term scalability/maintenance cost. We propose outside (could be another expert on another team) consultation to close the risk gap. 3) We need to reassign resource X who is our most knowledgeable in adjacent tech, this takes them off feature Y and we will do a spike of duration Z to verify our approach.
When you do #3 enough your management will appreciate you using existing resources, providing the trade-offs, and you will also up skill that person.
I think author misses some points:
1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.
2. Many orgs have a poorly managed culture around disagreements on technical design and some folks just don't want to put up with that kind of friction when the difference between using approach A or B is real, but not going to topple the project either way so why waste that energy fighting that kind of battle?
EDIT: Simple analogy
Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time!It's like asking me to choose GCP, Azure, or AWS. Does it really matter if there's no constraint? I can and have delivered systems on each of these platforms. Am I cowardly for not committing and not being a diehard for one of these when there are no NFR's that favor one over the other?
> 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.
I understand where you’re coming from, but in my experience this only leads to deadlock on both sides with nobody moving forward.
The best engineers I learned from will push forward with a decision and also communicate the tradeoffs and consequences upward. This breaks the stalemate and forces the “business side” (which shouldn’t actually be separate from engineering) to either accept the decision or propose an alternative.
The game where engineers view themselves as in a standoff with “business side” people and nothing moves forward has been a path to a slow decline everywhere I’ve seen it happen.
Of course you push forward as a team, committal here I take to mean between two or more engineers trying to debate a technical option.
Why must every engineer have an opinion on every technical decision if there are no hard requirements? I may only have an opinion if there is a hard requirement.
I gave an example below.
Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time!It seems pretty clear to me that not every engineer must have an opinion on every technical decision to which they should commit when sometimes, the choice doesn't matter and it's easier to let the individual with a stronger opinion drive the choice because the other option is friction for no reason and expending energy debating made up constraints.
> Why must every engineer have an opinion on every technical decision if there are no hard requirements?
This isn’t what anyone is suggesting.
Committing doesn’t mean everyone needs an opinion on everything.
> It seems pretty clear to me that not every engineer must have an opinion on every technical decision to which they should commit when sometimes
Again, not what’s being discussed.
You don’t need an opinion on everything.
Your team does need to commit to something and move on.
The phrase “disagree and commit” is commonly used when engineers have opinions on everything and are struggling to commit.
Committing != having opinions on everything.
I'm not sure how that paragraph gave you the understanding that "every engineer must have an opinion". It explains that the most senior/influential/knowledgeable engineers must have an opinion because they're the ones making the decisions. In that context, the decision is the opinion; not having an opinion is the same as not deciding, which is obviously bad for the person/people responsible for deciding.
This strikes me as parallel to "the best way to get the answer to a question online is to post the wrong answer, and people will flock to correct you".
As for "non-functional requirements" ("NFRs") Wikipedia suggests examples:
1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time).
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.[5][6]
Sometimes "the business side" has the expertise required to define these. Sometimes they don't, and engineers need to do it, using whatever knowledge of the business they have. "The business side" often will not take responsibility if the system is insufficiently testable, maintainable, extensible, scalable, secure, or usable, instead blaming engineering.
> Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.
Doesn't this necessitate asking the questions to get the NFRs out? You don't need to be non-committal then. Just say "we need answers to these 8 questions before we can estimate, as they will make a massive difference."
You'll get them...at some point. It may be even at the very end when the customer complains that it doesn't quite work the way they intended and it turns out, they never fully specified exactly how it was supposed to behave!
If you haven't experienced this, you haven't truly lived the enterprise software delivery reality.
Of course it can happen that way :) But as an engineer you have to decide on the NFRs if you don't ask anyway, so why not ask them and declare them up front if you don't get an answer? Then you can point to the problem is down the line and say we need X time to increase this NFR.
Sure, but you've missed my point: in that case, some engineers just don't want to have that debate because there's very little point in expending that energy.
Best strategy would be to declare NFR using engineer’s domain knowledge without waiting for clients to tell them. This is conditioned on engineers knowing domain sufficiently well. Which is a requirement for effective work anyway.
I feel like a broken record now, but once an engineer decides to "declare NFR", then it's a situation where it's one opinion versus another not driven by actual requirements and I contend that this is a point of friction that some engineers just do not have the energy for when there are no real requirements -- just fabricated ones.
So does the engineer sit there and do nothing until they know the NFR, or do they decide on the NFR themselves and build to that?
If the former, fair enough? If the latter, what energy does it take to send that NFR in an email saying "This is what we're building to; you have 7 days to debate it."
Is there really a need to debate whether it's Japanese or Indian? Am I a coward for not taking a hard line on Japanese being the clearly superior dining option? Why cause friction when both get the job done? But if Antoine and Lin are coming, then I will take a hard line because Antoine is allergic to shellfish and Lin is a vegetarian so let's pick Indian because I like Antoine and Lin's company.
Yes, this is exactly how real world software engineering works. Just send the NFR in an email and call it a day.> Is there really a need to debate whether it's Japanese or Indian?
This analogy is wrong - you're not the diner. You're the chef. You're going to cook something. You need to pick anyway; why not say what you're picking in advance and give people a chance to object? Is it really just something you can't muster the energy for?
Read the first line of the article:
I'm non-committal because I don't care where we eat unless there is a constraint.In this are you the cook making the food (the engineer) or a customer ordering the food (one of the business people)?
If you're the cook / engineer, you are going to make something. What are you going to make?
> simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.
"We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." is a completely valid decision to officially make. And it helps with planning and development of related code. "I don't know, because of missing NFRs" is not a decision though.
Generally speaking, "we're scaffolding/not implementing/delaying this part" is something you can do with functional requirements, but not with non-functional requirements. Changing non-functional requirements like security, maintainability, or testability generally requires rewriting the whole system from scratch, incrementally or otherwise.
"what do we do with this part?"
Not committing: "I don't have enough info, don't know".
Decision: "We can only finish it once X is known. Until then we assume it behaves like (…). For code that relies on it, we're prioritising flexibility to change over perfect solution at this point. Y is responsible for announcing when X is known."
I find there's a good way to not commit, slightly different from this article.
There's a non-committal way of designing software that I think we should all strive to follow. It's not things like "let's use an ORM so that we can swap the database later" or "let's write abstractions over everything so we can swap everything later". It's more that you're trying to keep the code as simple and static as possible, naively doing the exact business function, and rarely generalizing. There are a few practices I've picked up over the years for non-committal architecture of this kind (for example: doing more at "build" time, passing the functions what they need instead of what you have, keeping IO in shell layer, and a few more). The goal is not to end up with a codebase that has foretold all the possible futures, but that implements just what it needs to do now in the most straightforward way, such that it's easy to read, understand, and change. I think this kind of non-commitment is the ideal to strive for. The less committed you are in this way, the easier it remains the change the codebase as it evolves, the less shackled it is with over-engineered "solutions".
It's deceptively hard to do this in practice. Everybody wants to implement their over-engineered "system for doing a thing" layered on top of the programming language. Sometimes we forget that the programming language itself is a great tool for expressing business logic.
If you have trouble committing to an option, it's usually because the options are equally good as far as you know.
There are two ways to go about this:
1. If the stakes are low, you can just pick one option at random and commit to it.
2. If the stakes are high, come up with a way to reduce your uncertainty around the options. Set a time limit, and perform an experiment that will inform your decision. If that experiment doesn't conclusively settle the options, just pick one and commit to it.
In general I don't have a problem committing, but there's also some solid rules of thumb that you can follow, for example: "if all else is equal, take the option that leaves you the most opportunity later".
However I have also employed Weighted Decision Matrices[0] to a pretty high degree of success if they're undertaken seriously and the outcomes taken as a learning exercise.
Ironically when I employed the Weighted Decision Matrix I often didn't like the result, which was equally telling!
[0]: https://en.wikipedia.org/wiki/Decision-matrix_method
Also, getting better at intuitively analysing these situations and picking an option is part of what it means to gain experience and become better at what you're doing. If you're doing things right, you will start out finding it difficult to pick an option when you're new (to programming, to a particular domain, to a particular technology, whatever), and as you get better, you 'll develop a "taste" for what seemingly-equivalent solution you prefer.
I found using "architectural decision records" to be helpful; it's not a panacea and I'm sure there's other approaches, but the gist of it is that you make a document, write down your thought processes, consider the different options (demonstrate you did your homework), and get the team together to proverbially shake hands on it.
It's not set in stone; if anything, the writing reflects "what we know right now" about a problem and its possible solutions, but it's a message to the future when either the context of the problem changes, the problem is better understood, the underlying assumptions and/or requirements change, or something changes in the solution.
It's both committing to a thing "in the moment", while leaving it open for updating down the line. It's much preferable to someone just picking something because of gut feeling / hype / assertiveness / cool factor which is how a lot of projects end up in the bin after a few years.
I tend to do something like this for most tickets I work on (that have choices to be made). I work through all the details and make sure I understand them all, then note what the difference choices are for various things. Where there's a choice to be made that requires "customer" input but that I have a pretty solid idea what the right choice is so am going to move forward on that, I'll make note of it, etc. It also gives me time/space to document ambiguities in the requirements.
I am.. overly verbose in tickets. That being said, it's come in handy many times in the past; some of which are me trying to figure out why I made a specific choice.
"I am.. overly verbose in tickets."
So am I, and I'm proud of it. I see a GitHub issue thread as effectively infinite storage for the ideas, decisions and research behind a change I make to a codebase.
Here's a recent example - 51 comments and they were almost all me talking to myself https://github.com/simonw/llm/issues/617
> Well, it depends: there are many strong technical reasons on each side, so it’s better to keep an open mind and not come down on either side.
My heuristic in this case is just to go with whatever option is simpler, and gives us the most flexibility to course correct in the future if we turn out to be wrong.
Basically make it clear that in the absence of sufficient data to decide on the best course of action, we are being intentionally non-committal. Then outline what new information would be required for us to make a more informed decision one way or another (e.g. an actual customer asks for the hypothetical feature that we are discussing, or performance is insufficient, etc), and what actions and effort we would need to change course. When put like this, I find that everyone in the room usually ends up pretty satisfied with the plan.
Some technical decisions aren’t that important.
A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all.
The tricky part is estimating consequences of these technical decisions. If you’re more or less confident in your estimations, and you believe the technical decision being made has severe consequences (not just to the product, in the long run development process is equally important), only then is the time to commit.
> A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all.
Until people start touching each others' code; then it makes sense to pick one or the other and stick with it.
Ironically, when I implemented .editorconfig at my job, (code formatter and checker in CI), I decided that we were going to pick one or the other. I did a little bit of research, and found the silliest little detail that made me pick one over the other.
I won't say what the detail is; but I will say it's a lot easier when CI enforces one approach, and I can run a simple code reformatter if I accidentally violate the rule. Otherwise, it's super-annoying if, every time I get into a new area of the code, sometimes its tabs, and sometimes its spaces.
> then it makes sense to pick one or the other and stick with it.
Oh, being stuck with incumbent decisions.
OMG, the difference between tabs and spaces is so tiny that it's generally inconsequential in modern IDEs.
In our case, where we use .editorconfig and a reformatter, if someone makes a case that we should change, it's trivial to do so.
> Oh, being stuck with incumbent decisions.
I think if you feel that way about tabs vs spaces, the problem isn't "incumbent decisions," the problem is your attitude.
With style, consistency matters more, so ensuring everyone either uses spaces or tabs but not both is helpful. I don't think being willing to commit means you need to decide on which one is used, unless you are a designated tie breaker and others cannot come to a choice.
I think this article still applies there just in a different way. If:
Then it is important that you make A decision. It can be "we're using my preferred style", or "we're using gofmt/rubocop/black/whatever", or something else. But any of them is going to be better than future waste of time in reformatting, merge conflicts and people arguing.> The tricky part is estimating consequences of these technical decisions.
Estimating or knowing; your tabs vs spaces for example has been tirelessly discussed for years, but the consensus there is that consistency is important, else your git diffs will include tons of churn where tabs are converted to spaces or vice-versa by people's editors.
> However, I don’t force people on my team to also use tabs
Wait a minute. Does that mean you are using mixed tabs and spaces depending on file author? Or are you just saying you start projects using tabs but don’t enforce it for others’ new projects?
Not using python, then, because this causes useless issues.
> "If you don’t take a position, you’re tacitly endorsing the decision that eventually gets made"
This is important in a lot of situations, not just engineering.
Variants of cut-and-choose can be useful here. If you flip a coin to make the decision for you, do you object to its outcome? If so, you've picked the other one.
It's also worth having a discussing about responsibility, power, and accountability here. Conventional management structures are supposed to align this, but that rarely corresponds to reality.
We have 5 different engineering teams in our company.
The 4 are being led by benevolent-dictator-type of engineers, the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates.
Two of the 4 teams have become so big and independent, that the dictator-leads no longer need to participate in the d2d operations/decisions, to the point where they now work mostly on individual RnD projects.
The other 2 are small specialized teams, whose members have become domain experts in specific areas, to the point that they can talk with the business and move on development, with little need of interaction with their lead, and absolutely no need for a PM/PO layer.
The only team that struggles to perform is the one with the non-commital lead. It became so bad, that the current discussion is to dissolve the team, and have it's members/responsibilities be absorbed by the 2 big ones.
> the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates.
This is a very common failure mode for first-time leaders and managers. They optimize for minimizing conflict and want everyone on the team to like them.
A difficult lesson to learn in leadership positions is that you can’t make everyone happy and you can’t avoid every conflict.
Hyper-democratic leadership styles don’t work outside of very small and tight knit teams where everyone was already on the same page.
Someone needs to pull that person aside for some intense coaching to train them out of the mindset of people-pleasing and into the reality of getting work done. It’s not a fun transition but it needs to be coached. This is one of the turning points where many people realize they don’t want to be in leadership or management roles because the difficult decisions and uncomfortable conversations are in conflict with their personality.
Exactly. I think both parties (him and his VP) are now realising that maybe this person will be happier/better suited as an IC
Thinking about this more. I guess my n=5 observation is that committal engineers tend to have specific expectations about the performance of their teammates, and hence produce similarly performing teams to them
Whenever I face this, in my own analysis or others, I apply the "let's find out" tactic. Instead of doing nothing I'll propose that we do X which I surmise as an option that a) is non-destructive and reversible, b) has a chance of working out. [You can add your own criteria, e.g. fast/easy, simple, etc] At the very least we'll learn something. When someone else is stalling, I'll phrase it something like "Unless someone has specific reasons against investigating X, I propose we prototype it and see where it goes." If still unsure, prototype Y. After that you usually realize there's not much point prototyping yet another an simply choose one and see how far it can go.
Almost all software engineering systems are reversible. If a decision can be unmade later I find is a lot easier to accept committing to a decision despite not yet being 100% confident it's the best approach.
This works in collaborative decisions too: if someone still has doubts, ask them to "disagree and commit" to the new direction but promise them that you'll evaluate if it is working out in a fixed time period - drop something on the calendar in two weeks time for example.
Indecision paralysis is much more harmful to a project then picking an option that later turns out to be suboptimal.
The question "Is this a one-way door or a two-way door?" can eliminate that paralysis in the majority of cases where, as you point out, the decision is reversible.
I strongly support this approach. By voicing my thoughts, including any weaknesses and unknowns, I invite others to contribute their insights. This not only helps to address gaps in my knowledge but also encourages a collaborative environment where other engineers can engage in discussion and decision-making. I believe this dynamic is a sign of a healthy workspace, where open communication and teamwork are valued.
The flip side of this is that engineers who won’t commit aren’t trusted and thus have low status on the development team. It’s easy enough to get promoted over them if they haven’t been Peter Principled yet.
Famous example from the pop-culture is Burr vs Hamilton:
> If you stand for nothing, Burr, what'll you fall for?
Passive Non-Comittance (I will need more information, more prediction power, more certainty about future events) ironically is still more expensive, then active Non-Comittance (We just built all the implementation-components in such a way they can be exchanged later).