I see many Engineering Leaders taking on a ‘gatekeeper’ role, pushing back on business demands to achieve a sustainable pace. This is an exhausting position, that can ultimately erode relationships at a leadership level and lead to ineffective decision making.
There is a better way, pulling forward, the act of enabling, encouraging and driving the leadership team to make good technical decisions. Here I outline why pushback doesn’t work, why pulling forward is a better approach and how to go about it.
- Pushback begets pushback, and gets nowhere
- #1 Accept that anything is possible with caveats
- #2 Recognise your role as ‘options authority’
- #3 Start to ‘pull forward’ as a Leader
- #3 Form and drive a pragmatic, informed and balanced opinion
- #4 Hold the Leadership Team accountable for decisions
- How to form a pragmatic, informed and balanced opinion
Pushback begets pushback, and gets nowhere
New requirements arise for your already-stretched-to-the-limit team. You surface a myriad of valid reasons explaining why a particular timeline/scope is not possible:
- Resource constraints - Not enough available engineers given existing focus’
- Quality concerns - The product / codebase will suffer if rushed
- External dependencies - Certification requirements / API approval
- etc
Never in the history of startups has a founder listened to those reasons… nodded quietly and changed the plan accordingly. What you (rightly) get in response is a firm challenge to every reason you’ve provided:
- Resource constraints? → Hire contractors / stretch the team / use AI
- Quality concerns? → Write it down as debt and fix it ‘later’, this is critical
- External dependencies? → Hound until those dependencies are met
The TLDR… it needs to happen, so figure it out.
When you pushback, you ultimately give your stakeholder two high level options: concede, or fight. They will take option B every time.
This compounds over time as you develop a reputation for pushback. Now your stakeholder comes ready for a fight, it has become a systemic cycle with escalating and increasingly exaggerated concerns on each side to strengthen the case either way.
- “If we don’t build this by March, the company will fail”
- “If we add any more tech debt, the whole system will fail”
Ultimately effectiveness suffers, as decision making is driven primarily by strength of personality. Despite a misaligned technical leader, the target is invariably set and inevitably missed once again.
#1 Accept that anything is possible with caveats
I put it to you that any (software) request is possible, with caveats. This has never been more true than in the age of AI development.
Imagine the CEO comes in asking whether it’s possible to replicate Slack by tomorrow. Rather than pushback, my response would be something like:
- We can make it happen! here are the caveats:
- Cost - I’ll need our 3 best engineers to drop their current project, or to hire 4 contractors at a high premium given the short notice
- Scope - It can be basic messaging, profiles, notifications etc
- Limitations - It can only be used by a maximum of 100 people
- Risks - It has a high chance of crashes/bugs, and will be open to security issues. Key engineers may become retention risks.
- Debt - It’ll need to be rewritten if we want to extend it beyond the above limitations
With sufficient caveats, any request can be accomplished. I find these 5 caveats help to cover all bases (cost, scope, limitations, risks, debt). I challenge anyone to come forward with a counter-example (none received to date across dozens of coaching sessions covering the topic).
#2 Recognise your role as ‘options authority’
What is our role as Technologist within a multi-functional Leadership Team? Typical answers I hear position the Technical Leader as someone there to fight the Engineering corner:
- “I make sure technical concerns are factored”
- “I represent Engineering priorities”
- “I ensure realistic targets are set”
- etc…
These all stem from a pushback mindset, predicated on the idea that all leaders arrive with their own priorities and battle it out to find a ‘healthy balance’.
My alternative view is this:
- I am the options authority and delivery leader. That means:
- I provide all possible options, communicating caveats in business terms
- I deliver what is decided, managing all expectations
- I ensure accountability for decisions
Effective business decisions can only be made by a leadership team when all options and implications are understood. As ‘options authority’ it is on you to exhaustively outline all prospective paths forward, including those that make you feel uncomfortable.
Too often Engineering Leaders bring a singular stance, one that assumes a set position on a number of factors. When a Leader says:
- “We’re off track to hit the deadline, there is too much still to get done in time”
What they really mean is:
- “We’re off track to hit the deadline, there is too much still to get done in time …to the level of quality/security/team strain that I deem acceptable”
Acceptable risk / cost / debt / scope / limitation is not something that can be decided in isolation, it is a collective choice that the leadership team must make together. As a part of that team, you are naturally entitled to an opinion on the matter (one with some weighting given your direct impact) but it is not yours to make alone.
When you fail to lay out the options, the resulting challenge from other leaders is ultimately an unstructured and uninformed attempt to exhaust alternative options. When this happens and you find yourself on the back foot (e.g. having to answer for the 5th time this year why contractors aren’t a magic bullet), its more than likely because you haven’t adequately satisfied this critical part of your role.
#3 Start to ‘pull forward’ as a Leader
‘Pulling forward’ means:
enabling, encouraging and driving the leadership team to make good technical decisions.
This is the positive, constructive and collaborative alternative to the objectionable, argumentative and protective pushback model of leadership. We’ve covered the ‘enabling’ part with the first two points:
- Accept that anything is possible, with caveats
- Lay out all viable options, to enable informed decisions
Now for the hard part… #3 and #4 are what prevents leadership teams from picking the destructive/high risk option every time:
- Form and drive a pragmatic, informed and balanced opinion
- How the leadership team accountable for decisions
#3 Form and drive a pragmatic, informed and balanced opinion
This is an opinion that:
- Clearly and concisely surfaces cross-departmental trade-offs
- Translates all considerations into risk/cost to the business
- Attempts to balance short and long term business concerns
If you can form this opinion, and drive it through with the leadership team, you become the single lead able to navigate the crucial optimal path through:
- Investment in productivity vs productivity potential
- Over-engineering vs under-engineering
- System/security risks vs commercial/financial risks
- Resource availability vs efficiency
- etc
Getting these balances right is the difference between success and failure as a growing startup. They require ownership, leadership, awareness, collaboration and team-wide alignment. This is what ‘pulling forward’ really achieves, something I believe all engineering leaders should aspire to.
#4 Hold the Leadership Team accountable for decisions
If the team consistently chooses the quick/risky options, resulting in communicated risks coming to fruition, it is the shared responsibility of the leadership team. This cannot come back to the team, this cannot solely come back to you as the Engineering Leader, but as a shared decision maker.
This can be jarring for some executive leaders, who are used to being somewhat removed or obfuscated from technical risk. But ultimately the leadership team holds key levers that decide a business’ risk profile, specifically the balance of investment in risk vs growth.
The only viable alternative I accept is a situation where the Engineering Leader has absolute control over resource allocation where risk is concerned, with no scope for other departments to override that allocation of effort. This may seem clean/elegant on the surface, but in my opinion ultimately leads to inefficiency and mistrust among leaders, where this ‘power’ relies on absolute trust, is open to abuse and has fuzzy boundaries. What constitutes a risk? Where do you draw the line on acceptable risk? What if risk-oriented work overlaps feature development? etc In my mind, full transparency and shared accountability works far better.
Accountability doesn’t just mean shared decisions, it also means taking responsibility when those decisions go wrong. That means openly and collectively acknowledging mistakes, holding retrospectives for the team, learning and improving.
How to form a pragmatic, informed and balanced opinion
For someone who has always acted with a ‘pushback’ mindset, within an organisation designed around ‘healthy conflict’, this can be a challenge. But with time and practice, very doable. I see a few key steps:
#1 Add your technical concerns to the table, then try to let go
You will be naturally inclined to add weighting to your departments’ worries. You have to deal with the challenge of aligning your team on a given decision, and any repercussions. It might be you getting up in the middle of the night of the system goes down.
This cant guide your thinking, you need to lay out the technical considerations (stability / security / extensibility / cost etc), translated into business risks, then step away from them. Try to seat yourself if the department-neutral position of the CEO, representing the whole business.
#2 Engage deeply with commercial requirements
Does the cost of pressing for delivery (debt / retention risk / technical risk) outweigh the cost of missing a deadline? (reputation damage / customer loss etc). The only way to form an opinion is to deeply understand both sides of the equation.
Embed with the rest of the organisation, get to understand the importance of particular customers or deals, empathise with the position of other leaders, get to grips with the finances. By connecting in this way, you gain awareness of the motivations driving the push. By role-modelling a collaborative attitude, you might just find questions will start to come the other way.
#3 Translate everything into risk
Risk is a common denominator. What poses a greater risk to the business? A major outage due to under-investment in SRE, or a missed opportunity to capture a new market. Ultimately all decisions can be viewed as a trade-off between different risks, with different likelihoods and levels of impact. Translating concerns in this way can help to simplify the challenge of comparing cross-department apples and oranges.
#4 Build trust by showing that you care
Tell that CCO that you are going to try and make it happen, try and make it happen and then tell them how you tried to make it happen. Start over-communicating your commitment to their cause and you will find that your ability to align them on your opinion will skyrocket. If the only thing they ever hear out of your mouth regards Engineering problems, they will (probably rightly) assume that is your singular priority, and all options/opinions will be weighed heavily in that direction.
#5 Only talk about the engineering concerns as customer concerns
There is no such thing as an engineering priority. There are only customer/business priorities. This is a critical change in behaviour. Some examples:
Stabilityincrease user trust in our systemRefactorsinvest in forward delivery speedScalabilityremove limitations to onboard new customersPerformanceimprove user NPS through product experience
For other departments (e.g. sales) the link to customer/business is explicit. For us, the link simply needs to be made and re-made and reminded every time we talk about it.