Engineers who won't commit
seangoedecke.com
seangoedecke.com
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.
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.
Who? I described a SME.
There is a difference between a manager mentoring a SME's career into becoming a well rounded senior, and just expecting a talented engineer to immediately operate as a fully developed senior because that manager doesn't have anyone else to rely on today.
Now, I'm smurfing here a bit by describing a position I was at earlier in my career. I guess I appreciate the attempt to give advice, but recalling back to that time in my life you've also written with way too much management-speak for someone in a place that deserves real communication.
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 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.
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!
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?
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.
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!
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.
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.
> This isn’t what anyone is suggesting.
> 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.
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.
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."
If you haven't experienced this, you haven't truly lived the enterprise software delivery reality.
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?
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...
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?
> Some engineers think it’s a virtue to remain non-committal in technical discussions.
If you're the cook / engineer, you are going to make something. What are you going to make?
"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.
> "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known."
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."
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.
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.
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!
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 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.
Here's a recent example - 51 comments and they were almost all me talking to myself https://github.com/simonw/llm/issues/617
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.
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.
Oh, being stuck with incumbent decisions.
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.
- 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
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.
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?
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.
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.
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.
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.
> If you stand for nothing, Burr, what'll you fall for?