This article is written for software engineers that work in collaborative settings. It is also interesting for anyone on the business end of tech and everybody that works in supporting tech teams with decision making (if only to read the perspective of someone on the receiving end of that support).
If the following story speaks to you, then keep on reading:
A small team of software engineers sits together in a cramped, windowless conference room. It smells like sweat and sugary drinks. The AC tries to make up for its inability to sufficiently air the room by producing more noise. Snacks, laptops, and whiteboard markers litter the table in the center. This is the fifth time this week that these people have come together to talk. It is only Wednesday. The last two weeks looked no different.
Despite everyone on the team being really experienced in their domain, which they all share, you can feel the tension. Nobody is at ease. Odd glares are exchanged. People shift in their seats and seem not to be able to find a comfortable position. One member frantically scrolls through a large document. Another cleans the whiteboard on the wall with quick and needlessly powerful strokes that speak of anger and frustration, something that is palpable in the room. You can see varying degrees of the same frustration and the same anger written on everyone’s face. And exhaustion. Everyone looks as if they haven’t slept for days. They have. Their fatigue is caused by hours upon hours of discussion over days and weeks. Discussing what? A simple question, really: what is the best approach to solve <this problem>?
_By now, everyone in the team has developed a strong opinion about that. The trouble is just: Not two of them agree on what the best approach is. Only that the other’s methodology is flawed and ridden with pitfalls. Only that much is agreed. One of the engineers makes a throat-clearing sound and starts to say, “I think I have found another perspective to illustrate why we should not consider the outcomes of yesterday’s proof-of-concept a valid sample, because…” which is as far as that goes, before a chorus of moans and snarls from the others around the table puts an end to this attempt. “Really?” asks another. “You spent the rest of your time yesterday trying to prove that we are unable to agree on even that much?” Heads around the table nod vigorously, and the first speaker starts to turn red. “Yeah, really,” the exasperated reply bursts out, “we cannot go forward if it is clear that we will fail on this path!” More irate sounds emerge, and the mood in the room noticeably sours by at least one more octave.
Let’s pause here. This illustrates what I’d call an Expert Deadlock. Nothing is moving forward. Nothing is being decided. Everyone is mad. It is bad for every individual involved because it smokes you up, burns you out. It is bad for the business because it is the most unproductive state possible: total stalemate. It may not be as bad as illustrated in every case. Sometimes you are able to still progress in some areas while being in a deadlock with only specific decisions. Sometimes a deadlock lasts only for days and not weeks (or months). Either way. It is always very taxing in the moment and it always has the potential to cause long lasting damage in the team relations.
Have you been here? Are you in that picture? How do you think a mess like this came about? How can you fix it?
Well, I’ve been there. I’ve seen it happen to others, and I’ve heard about it, too. Speaking to a friend who currently is in a similar place is what triggered me to write about it now. There are many variants of this scenario. Often, it is not as bad as my fictional story above - at least not yet. Sometimes it is worse. From what I can tell, this is not an uncommon occurrence at all. Alas, among software engineers, which is my realm of experience. If you haven’t seen it yet, count yourself lucky. Or not, because then you might not know how to handle it when you encounter it. We’ll get to that later.
Casus Belli
So, how do we end up in a dilemma like this then? From my observations there are many individual reasons and contextual circumstances that contribute. I am not interested in those. What I care about are the common, underlying patterns. If they are known you will fall prey less easily to them. Let me also be clear: this is not about bad actors that have bad intentions, are motivated by greed, or are malicious - or any such notions. I am sure all of that could easily yield a situation as described - but it is not needed. This happens to juniors and highly experienced people alike, who work together in good faith, and with good intentions.
The following reasons I’ll be discussing here are all contributing. All of them are sufficient, as in: they are enough to produce an Expert Deadlock. All of them are also probabilistic, as in: You can get away with any of them, if your circumstance allows it. I highly doubt that this list is comprehensive. It is only the list that I have experienced myself so far.
Goal Glitches
A common contributor to messy situations is the good ol’ misalignment of goals. If this divergence is known, then it’s easy: you can account for that - or choose to part ways. However, if it is not known, then it becomes awkward. You may pitch your idea with the best reasons that are fully supported by data and still you find yourself rejected. And probably hurt. The other person simply doesn’t share your priorities as they have a different goal in mind. Imagine we are both bakers and I try to convince you that blue icing is the way to go, as proven by extensive empirical research. You simply don’t care, because you cannot see how this contributes to the goal of healthy cakes that you have in mind. We are badly misaligned here. The chance of us finding an approach we both agree on is very low – especially as long as we both operate under the assumption that the other is sharing our goals.
This contributes to Expert Deadlocks in two ways: First, by people simply talking past each other. I’ve taken part in hours of heated discussion only to find out that everybody was talking about something different entirely. You might think this could only yield a brief deadlock, because such misunderstandings are certainly uncovered quickly, right? Well, if you are lucky, yes. However, it doesn’t take long for emotions to become entangled and then for stung egos to supersede rational argument. Once at that stage, it is not easy to think straight and even the obvious may elude you. Not only can it take much longer than you think to even identify the misalignment when in this state, people that are that riled up may still choose to continue arguing either way.
Deep Ends
The holy triangle of the three Ps - Perfectionism, Pragmatism, Passion - is both a curse and a blessing in any software engineering endeavor. They must be carefully balanced to arrive at a desirable outcome.
Perfectionism makes us focus on details that might be essential. It drives us to optimize and iterate until we can make true breakthroughs. Too much perfectionism leads to many yaks losing their fur and many rabbits being disturbed in their holes. Nothing is ever shipped because something can always be improved, or polished, or refactored, or …
Pragmatism makes us focus on solving the problem. It allows us to be open to any approach. It drives us toward efficiency. Too much pragmatism results in a whatever-attitude and sloppy solutions. Trashware systems, the eventual outcomes, are as maintainable as they are usable: not.
Passion is The _key motivator. It feeds us energy. It makes us stay after hours and come back early in the morning. It drives us towards impossible goals – and makes them possible. Too much passion makes us blithely impervious to facts and data: “_The critics are just afraid” or “You just fail to see the vision”. A marvelous approach to create spectacular art. A terrible mistake for the business of engineering.
Expert Deadlocks can easily arise from an excess of both perfectionism or passion. Either makes for a great foundation for last stands on the least relevant hills. I cannot see extreme pragmatism leading to a deadlock. However, it can create meetings where nobody gives a sh*t and that comes with its own pitfalls.
Tunnel Vision
This happens to the best of us: You are deeply into a topic, say a technical solution of sorts, then you gradually lose perspective of the big picture until you are so focused on the task that you forget why you started it. You simply lose sight of the reasons for your actions (and everything else) by focusing entirely on those actions. That is not a wholly wrong approach either: we humans are single-taskers after all, and we are much less prone to errors when doing one thing, than when doing multiple things. This focus increases the quality of our work. Even if this work is unnecessary or counterproductive.
I’ve seen Expert Deadlocks arise – even with rather seasoned engineers that you would think know better (and yes, I was one of them) – when people just get too invested into a solution to be able to back out easily. It hurts to do that. Nobody wants to get hurt. It’s so much easier just to keep going. A room full of engineers that are afraid to lose all the efforts they have put in over the last days / weeks / months – not to speak of all the self-worth that is bound up in that – is not the most rational place.
Being able to step back, take a breath, detach yourself from the emotions of an approach and refocus on the bigger picture is both a skill and a function of culture. It can be learned and it can be taught. And it can be prevented if acknowledging or making mistakes is punished.
Fear Is The Mind-Killer
This brings me to another common cause. And it is a sneaky one. While being able to step-back and regroup is a great skill, it can also be overdone. Being afraid to commit to a pathway. Ever seeking the comfort of the higher-level perspective. While that may not end in the clash of strong opinions, it ends in a myriad of evaluations, trials and proof-of-concepts that eventually have no value because they never go far enough to have any effect at all.
Thereby it can also lead to an Expert Deadlock by creating a room full of critics and nitpickers. Everyone then only sees problems with everyone else’s solution. Always one more alternative that needs to be reviewed. Effectively nobody is willing to take the risk of having signed off on a future failure. The only proposals are then either so outlandish that there is no chance in hell that they will be accepted (so there is no risk to propose them) or they are so vanilla that doing them or not makes no difference (and there is no risk of failure).
Dog Eat Dog Ethos
Somewhat related to the previous point is a culture of hyper-competitiveness. A place where everyone is pitted against each other, where any advancement requires continuously winning against somebody else (or cutting them down, to step over them). I know this may sound like the bad actors I said this would not be about. To this I’d say (with sadness): if it is culturally / structurally caused, then the actors are not bad, just rational.
Either way I think it’s pretty obvious how this creates a breeding ground for Expert Deadlocks: The overarching incentive is to promote yourself. If it is more important to look good than to make headway towards a shared goal, then why would you? Agreeing to a proposal from your boss, so as to increase the chances of climbing up the ladder yourself? Sure, a concession here may get me a promotion. Agreeing to a proposal of a peer, however suitable and beneficial? Nah, if they shine and get the promotion then I won’t.
Feedback Void
This is the big one. Big as in: All of the above can be mitigated or aggravated by how this is done. The previous point about hyper-competitiveness illustrates how feedback loops that stimulate bad behavior lead to a deadlock. This is about how the lack of them can be even worse. Feedback is essential to being able to formulate goals and specify the right work that needs doing to achieve those goals.
How those feedback loops are implemented depends on the individual organization: They might come as leaders that are sufficiently knowledgeable and involved to be able to make decisions and can act as tiebreakers. Or they emanate from a community culture where proposals of solutions can be discussed without fear of giving critique nor reluctance to receive criticism (think RFCs). Or both. Or something else entirely.
If such mechanisms are lacking and an individual team is entirely free-wheeling, then any of the above factors can easily take hold and grow. There is no steering mechanism that provides direction or even keeps us from falling into the abyss. The Expert Deadlocks that will eventually arise are likely one of the lesser problems that come out of it.
Make Progress Not War
Nobody wants to be a character in the story at the beginning. Still, we find ourselves in such situations. We discussed some factors that make it more likely that we arrive in such a mess. The questions now are: How can we make sure that we do not end up here? And: if we do, how can we get out again? Prevention and remediation.
Prevention Strategies
Measures that reduce the risk that deadlocks arise are almost exclusively structural. Which means they must be implemented at organizational level. They must be part of the culture.
Culture Of Candor
If you do not know where to start, then start here. The following is absolutely fundamental for highly effective teams. You can look at it as a general antidote that strengthens teams’ abilities to work together and therefore immunizes against deadlocks and other ailments. It comes out of a body of decades of research, among which a multi-year study at Google that involved hundreds of their teams to answer the question: “What makes teams effective?”. It was called Project Aristotle and you can read up on the journey that it was here.
The primary learning that you should take from that is the concept called Psychological Safety – a term coined already at the start of the millennium by Prof. Edmondson from the Harvard Business School. It measures the degree to which people in teams / organizations believe that they can be candid without being punished for it. There is of course more to it, but this is the gist. A team that rates high on Psychological Safety is much more likely to be effective. As a matter of fact: Google’s study did not find any other factor that came even close in predictive prowess. This efficiency also includes the ability to reach decisions smoothly, that is: without falling into Expert Deadlock traps.
So how can you help to improve the perception that candor does not backfire then? Well, if you are coming from the DevOps-world as I am, then you are probably immediately reminded of Blameless Postmortems. Postmortems are processes to analyze previous incidents, so as not to repeat them. The practice of Blameless Postmortems shifts the focus away from individuals as the primary contributing factors and instead concentrates on the systemic causes. It has been very effective in addressing root causes and improving systems, hence it is by now widely accepted across the industry. Another consequence is that it makes candor without punishment a valued, nay necessary virtue.
Of course, this practice is only relevant for very specific situations: reviewing past incidents. In Systems Thinking exists an idea that arrives at extremely similar conclusions as Blameless Postmortems, only it applies them to a much larger scope. It is called Just Culture and it seems to be spreading through many industries. The principles are again the same: instead of blaming individuals when something goes wrong, it asks “What are the causes?” and then focuses on solving the systemic issues that such questions uncover. Optimized systems are the outcome. Again, this only works where candor is not punished but encouraged, thus looping back to Psychological Safety.
Note: this a prevention measure because it takes time to build a culture with sufficient trust to be candid. Do not attempt this in the moment of crisis.
Escalation Path, Safety Net
Setting everything up to lessen the likelihood of arriving at an Expert Deadlocks, as the previous point aims to, is where you start. However, consider that it takes only one nasty Expert Deadlock that leaves a formerly high-achieving team in tatters. Even if it doesn’t fully destroy the team, each such highly-emotional stalemate chips away at the bonds of trust that tie the team together. High cost, even if you are able to make it low risk.
My years of work in reliability topics left me on the constant lookout for risk mitigation strategies. What comes to mind here is the need for safe-guards that trigger automatically before a critical threshold is reached. Those safe-guards should have the shape of escalation paths and a set of guidelines when they trigger. Like: If we come out of the second meeting about the same topic without agreement, then we escalate. The simpler the better. It is more important to establish this as a habit than to optimize for efficiency. Err on the side of escalating too early rather than too late. Escalating is cheap, failing to is not.
As for how the escalation plan should look: the best I have seen requires simply having an empowered lead engineer on each team. In less formal situations this role can also be filled by an inofficially agreed tech lead. Whatever the name, the point is that one person is the predesignated decider. They are handed the mighty decision-hammer that they can take out in the time of need to break a tie or to end a deadlock. A technical manager that is sufficiently involved in the day-to-day can also work. Worth mentioning here are the perils of micromanagement and running amok on a power-high (neither of which I will detail in this article). In any case: Decision making through escalation should be the exception, never the norm (if it is then this should ring alarm bells about the state of the team).
To emphasize the previous point about candor: this goes for tiebreakers as well. If they are afraid to make a decision their value is blunted at best and negative at worst (i.e. when their decisions are not based solely on best knowledge considering all input).
A single level of escalation will already mitigate the risk significantly. Another level, like a director or CTO that is indeed willing and able to be of value here gives a warm and fuzzy feeling to everyone involved – even if never really used.
I found that not only a lack of organizational planning but also an overemphasis on a culture of consensus leads to situations where such escalation paths are missing (or worse: are seen as bad, because they are “too hierarchical” or some such notion). While this approach may be admirable and can work in specific situations for a while, I think it ultimately leaves teams vulnerable. Without clear escalation paths, every disagreement has the potential to escalate into a full-fledged confrontation, putting the team at risk of falling into an Expert Deadlock.
Note that this is a prevention measure because designating anyone in a position that can serve as tiebreaker requires good faith and ideally is giving credence over time by solving smaller team issues. Attempting this in an active stalemate situation can easily backfire and burn more trust and bridges than you aim to repair. Otherwise see the following headline “Utilize Peer Perspective”.
Remediation Tactics
Having the above prevention measures in place goes a long way. However, as you are here reading this, chances are it is too late for you to think about this now.
If you are currently in a stalemate of sorts then your first priority is to get out of that. Following I will give you tactics that I found useful in the past. Of course, they won’t be all applicable to your current situation. You will have to cherry pick what makes most sense for your case. To do that you first need to know your options:
Peer-to-Peer Arbitration
Shift the question! While you are in a deadlock to decide a particular question: can you still agree on something else? Like which pizza to order? If so, then good. There is hope for an easy out. Try to agree on the following: an external arbiter. This person must be experienced enough so that you all will trust their decision and far away enough so that you do not suspect bias. This is somewhat similar to the prevention measure of a tiebreaker, but different in that it is a one-off and cannot be someone already part of the team that is part of the stalemate.
Whomever you end up deciding on I would strongly recommend not to involve them in your (potentially heated) discussions but instead to give them a short(!) written summary of each branch of the decision tree that you are unable to agree on. Allow them to pick all of your brains if they have questions. Ideally in 1:1 meetings, so as not to have them influenced by the eye-roles and moans of despair that might come up in a group-setting. Now to the hard part: Await their decision. Trust it is good enough.
Note that only full agreement in advance of the arbitration will help you to break the stalemate. Pulling somebody new in without having the team’s consent only aggravates the issue and is not helpful (doubly so if they support your position).
Less Planning, More Driving
I had a really hard time to put this into words, so I have to fallback to story time again:
Imagine a gaggle of disagreeable Tolkien’esque dwarves that visit the surface for the first time. They are quarreling over the right route to take on a map. They all concur on the destination – a place full of precious treasures, gold and gemstones of course – but they cannot settle on how to get there. The destination is a long way out.
The map they are looking at is badly drawn. Some roads were clearly added later by an amateur. Annotations litter the canvas: “road does not exist anymore” it reads here or “don’t trust this overpass, it has fallen down” is written over there. The dwarves are loudly squabbling and arguing with each other. One proclaims angrily “Your path is curving away from the destination! How could it possibly bring us there?” Another exasperates “The bridges you claim are there do not exist on the map! How would we get across those canyons?” And so it keeps going on and on.
Riddle me this: how can you find out which of the dwarves knows the right path? Well, you can’t. The thing is: they are all wrong. The reason is that the map is just too bad. Any plan based upon it is doomed to be wrong! There is really only one strategy that delivers the bearded travelers their destination: Stop looking at the map and look around instead, then head in the direction of their destination. Ideally find higher ground. Maybe scout ahead. Use the map only to navigate around large, unchangeable features like mountains or canyons. If they keep on doing that they will arrive eventually. Unless they discover an even better opportunity on their route, which might happen.
Why do I tell you this story about dwarves and maps? What does this have to do with remediation of Expert Deadlocks among engineers? Everything. If you are one of the engineers in a deadlock, then you did put your own proposal forward. Withdraw it. Now! Acknowledge that all of your solutions are based on incomplete / invalid information about the technical landscape. Worse, the landscape is ever shifting and evolving with new pathways popping up all the time, while old ones deteriorate or disappear entirely. The further ahead, the further in the future, the more wrong your assumptions will become.
If you cannot make this plain to everyone (remember: you are in a deadlock) you must break the deadlock by instead picking one of the other proposals that a) goes mostly in the right direction and b) is the most likely to get more support by others. While you should not assume that this chosen route will deliver you to your goal, you need to accept that it is enough to move ahead towards where you want to go. By that you take on the role of the driver that gets everyone moving in the right direction. Prioritize progression on the right trajectory over the specifics of the movement!
Yes, there are a multitude of asterisks to this, many of which I simply cannot put into words. I give this advice with the assumption in mind that most engineers strongly err on the side of overthinking. I am also harping on this point and wrote a whole story to bring it across because my advice often necessitates to go along with or even champion flawed plans. This seems especially hard to do for engineering-minded people. It certainly was (is?) for me. I think this is the case because among engineers subpar solutions are considered almost offensive. This is why criticism of our own solutions are often received as personal slights to our skills and abilities. Get over it. It is a deterrent from being a driver of progression. You are building an obstacle where you should build a ladder.
Use The Right Tool
If there is one thing that humans excel at it is certainly tool creation and use. Tools are the distillation of learning into a device or process that makes doing specific things easier (or even possible). There is a whole pantheon of tools that are geared towards team decision making. I am by no means deep into this topic, but I have employed some such tools in the past and I have also seen them employed by others. More importantly I am in the lucky position to know someone closely that is extremely experienced in this field. My wife. I picked her brain so that I can give you some immediately useful tools. Useful meaning: circumventing or hacking intentional or unintentional behaviors that are obstacles in the pathway towards making a decision.
Know that I have no affiliation with any of the following (nor do I use affiliate links). You can take this as “to the best of my knowledge”.
1. Workshop Tactics
I write this article with people like myself in mind: software engineers. I assume you are one. That means you are likely specialized in some deeper field in that domain – as I am. Hence you can conceive that there are other people specialized in other equally deep fields. You probably also know how rarely such a focused immersion coincides with the ability to communicate or explain it to someone on the outside. Are you with me so far? Ok. Here is the thing: there is someone that is deeply into the field that pertains to team decision making. This someone is named Charles Burdett and he happens to also be an amazing communicator. He used that to encode his knowledge in a way that is immediately actionable (drumroll) in the form of a deck of freaking playing cards! You can buy this deck for small money (search “workshop tactics deck”). Or you can use it entirely for free online. It even comes with a whole decision-tree interface that guides you exactly to a very useful set of immediate things that actual work to tackle. Try it.
2. Design Sprint
So there is this big internet company that has a lot of very expensive (because very good) people employed. They have a huge amount of great ideas that they want to bring to the rest of the world as products. As execution is generally hard, many such attempts to productize ended in a mess. Or if not: they took longer than anticipated and were more expensive than necessary. Consequently the big internet corpo was eager to find a reliable and reproducible way that allowed them to go from idea to product. This way also needed to be easy enough so that everyone could follow it without creating a mess. The company is named Google and the methodology they came up with is called Design Sprint. It is a formalized 5-day process that starts with understanding the problem space, goes to sketching solutions, then making decisions and lastly validating the approach (it can restart from there if this fails). The leading inventor at Google was Jake Knapp who later published the recipe of the sprint in a book called “Sprint”.
Both of the above proposals share a couple of elements that make them rather efficient:
- Less overthinking, more momentum through time-boxing and other forced constraints
- Focus through guidance of structured activities vs free-wheeling
- Quick decisions through processes that whittle down options fast
There is more to it, but this is what convinces me. I didn’t like the gamification aspects (just seemed contrived / fake). Still, not a great fan of that part. However, I am swayed as I have seen reliable results with good quality coming out of this. And quickly too.
Seek Professional Help
Who would have thunk: there is a whole industry that is facilitating the above. They are called (drumroll) facilitators. Mind blown. But seriously: if you cannot do this alone, there is no shame in getting help. You are already great engineers (I assume), there is no need for you to master this additionally. I mean, do it if you are interested! It is a great skill to have in any collaborative environment. Whatever you decide: do not stay and wallow in your misery.
You may have these kinds of resources in-house. Often Product Managers / Owners are knowledgeable about this. If you happen to have teams that care about Learning and Development (L&D) they are certainly a good address. Generally Human Resources may be experienced as well. If none of that exists or is unhelpful then you will find aplenty resources externally. Ask your peers and friends if they have worked with anyone they can recommend – you might be surprised. Otherwise a google search for a local facilitator or team coach will certainly yield you a lot of results.
The equation that you should consider / pitch to business is simply this: X engineers are not productive for Y days due to stalemate equals Z money. Additionally, through team burn-out and breakage resulting from this, efficiency will be significantly down at least short- to mid-term. Likely long-term. Is this cost smaller or larger than professional help?
Note: If you are in a position to make that call: Make that call. If not then consider putting a limit on how much time you spend in your attempts to get the funds. I found myself frustrated in the past fighting against the wrong windmills (if you keep hearing “sort it out yourself, you are all professionals” then consider it a sign of resigned helplessness and move on).
Get Out
This is the hardest. And the easiest. It can feel like giving up. It is not. If you tried, really tried, to resolve your disagreements and still could not do it then acknowledge that and move on. It doesn’t mean you gave up, it means the cost of going in that direction exceeded the value it yields. This can feel almost like a break-up in a relationship. It can go equally wrong and leave everyone hating each other afterwards. Or it can go well and people agree to disagree and everybody just moves towards where they want to go next on their own. No harm done in this case.
Advice how to get this right probably fills books. The only one I can give you is to do it quickly, kindly and firmly. Above all be clear with yourself and anyone else – this is probably the greatest kindness of all. Remember that you can only control your own actions and nobody else’s. This is also where your responsibility ends.
Fix it?
From what I can tell things (at least in the software engineering industry) are moving somewhat in the right direction – but not across the board, only in some select companies that invested the time and money to gain the metrics that make the factors of productivity crystal clear to them. So I think it is on all of us to change that. I do not exclude myself from this at all. Here is how I think you can help, depending on where you are:
Tech Side (developers, engineers, product?, etc)
Do you believe in using the right tool for the right job? If you do then make sure you act the part. Saying things like “don’t bother me with this non technical nonsense” is a direct pathway to more frequent, more painful and longer meetings. Unnecessarily, because there are well researched practices and tools that are indeed getting the job (of reducing needed organizational chores) done. If you are already familiar with strategies and tactics to that effect then share them. If not then consider learning them. At the very least be open to take part in them. There are best-practices for collaborative environments. This does not come easy to me as well and I am getting it more often wrong than right. I get you. We just have to get this fixed.
Business Side (managers, executives, product?, etc)
The hidden costs of Expert Deadlocks in your engineering teams are significant. Beyond the immediate loss of productivity, these situations erode team cohesion and can lead to long-term and permanent efficiency declines. Investing in prevention and mitigation strategies isn’t just a feel-good exercise – it’s a necessary business expense of the same token as continuously investing into technical debt reduction is. The return on investment in terms of increased productivity, faster time-to-market, and improved team retention can be substantial.
People Side (L&D, HR, product?, etc)
From where I am sitting your value proposition is not being received in the way I think you intend it. Speaking for myself as a software engineer: I am convinced by fewer, shorter and less painful meetings and subsequently more engineering time. You should focus on virtues like that if you aim for an enthusiastic “hell yeah, I’ll do whatever you say” from the likes of me. To put it bluntly: Right now you are often perceived as overhead by us. Additional things we have to do that detract from the things we want to do. This is a framing problem. This is a communication problem. I think you are also not convincing business as it stands. Alas the preventive measures I spoke about are rather elusive. Given the business risks they mitigate, they should be absolutely everywhere. TL;DR: Plz change your pitch.
Outro
Wow. You made it. What a long post. Thanks for reading! I’d be curious to hear about your experience – whether you are a fellow code monger, or one of the brave souls that tries to help us heathens. Comment or DM me on LinkedIn.
