#DeveloperExperience #TechDebt #ProductDevelopment #EngineeringLife
Have you ever been told that “Developer Experience doesn’t matter”? As a seasoned engineer in the startup world, I have heard this statement more times than I can count. But let me tell you, it couldn’t be further from the truth.
The Pressure to Build Product Faster
Two years ago, a project manager on my team emphasized the need to focus solely on building the product faster, dismissing the importance of developer experience. While it may seem logical to prioritize product development to meet customer demands, overlooking developer experience can have detrimental effects.
The Reality of Developer Experience
After analyzing our continuous integration/continuous deployment (ci/cd) metrics and retro board, it became evident that our team’s biggest bottleneck was, in fact, developer experience. Time spent on resolving build issues, inconsistencies in local environments, and other technical hurdles significantly impacted our productivity.
Making the Case for Developer Experience
When I presented the data to the project manager, highlighting the potential time savings by investing in improving developer experience, the response was dismissive. The focus remained on pushing more features rather than addressing underlying issues.
The Unresolved Tech Debt
This scenario isn’t unique to one startup – it’s a prevalent issue across the industry. Tech debt accumulates, compromises system stability, and limits engineers’ ability to advocate for addressing crucial issues. So, how can we break this cycle?
To the Engineers: Taking a Stand
As engineers, it’s essential to advocate for the importance of developer experience. Presenting concrete data, outlining the benefits of investing time in reducing tech debt, and showcasing the long-term impact can help gain support from project managers.
To the Project Managers: Finding a Balance
For project managers, understanding the value of developer experience is key. What would you need to hear from an engineer to allocate dedicated time towards addressing tech debt? When should you prioritize feature development over resolving technical issues?
It’s crucial for both engineers and project managers to collaborate, communicate effectively, and find a balance that prioritizes both product development and developer experience. After all, a seamless developer experience ultimately translates to faster, more efficient product delivery.
So, the next time someone tells you that “Developer Experience doesn’t matter,” share your insights, experiences, and the impact it has on your team’s productivity. Let’s work together to create a culture that values and prioritizes developer experience for sustainable growth and success in the tech industry.
i usually resolve this by finding another job
Easy. I’ve never waited for any overlord approval to tackle tech debt.
It’s also very well documented with the quick wins and the longer upgrades/heavy refactoring needed. There’s always a clear benefit underlying any tech debt ticket.
Because yes there are tons of tech debt where it will almost never make any sense to fix this in terms of time spent Vs business value unlocked. And that’s what senior Devs are good at putting the cursor in the right place.
As you get more experienced at doing your job you tend to want to do more of what doesn’t need to be done at all (from a business value perspective) so you need to be clever about that or you’ll just use all of the vital energy of the dev team and the startup will crash and burn.
As a Deverloper Experience engineer, I disagree. Productivity of devs goes waayyy up when you put a bit of effort into the experience.
Welcome to startups. Design and tech debt. You just have to accept that if you want to work at startups.
The problem is….these people are right. Faking it until you make it is what matters when investor money is on the line.
Maybe you fix all that debt of you the startup makes it to Series B. Good part for you, is all this debt creates jobs for people like me to come in and fix it.
I think you need to push back. If you’re an early engineer with 8 years of experience, you should have a lot more power than what you’re saying. As a lead engineer myself, pretty much everything I say goes, including buying significant time for tech debt repayments. If not, you should leave, and if they’re not afraid to lose you because of it, it just proves they were not going to be successful and you needed to cut losses and run as soon as possible.
Happy to read this as we invest a lot of time into devOps, automation and our CI/CD pipeline incl. automation in our regularatory documentation because of our wise Software architect sais “most time is spent on releases and costs the most money” and what we dont do pre-release regarding automation, we will never do – see statement of your PM. It’s so short sighted as if the customer would care about 2 weeks earlier or later (if its not a bugfix or any)
> To the engineers: How have you resolved this?
1. Roll tech debt improvements into future feature requests. When a new product requirement is passed to engineering that enhances something with debt, or is dependent on something with debt, include refactoring work into the estimates and planning. Keep in mind, though, the effort should be proportionate to the request. Consider 10% to 20% debt work as the total cost of a new feature.
This is only needed because:
2. Leadership needs to be managed up. PMs don’t drive all the work. The team drives the work. And this needs to be driven up to leadership if they don’t already know it. You don’t need to convince PMs to avoid tech debt or make improvements. You need to negotiate a % of time / velocity to dedicate to tech debt. For startups it’s initially 0 and needs to grow slowly over time.
Short sighted PMs who don’t understand long tail benefits are the worst. Sure you shouldn’t be taking large chunks of time at the expense of features. You should be chipping away at things where you can. The compounding benefits to delivery of small improvements are so large, but often times people can’t understand that if you walk a you can run.
Really, a lot of the stuff is so easy to do in the beginning to, IF someone knows how. But usually you don’t have those people in place at the start and so inertia.
Startup podcasts that I listen to always suggest building the company/group culture as early as you can, because it’s almost impossible to change once in place.
Answer: probably very, very slow. Quasi-static, if you will.
Tech debt kills speed. Show them the cost, win the argument.
You need buy in from the decision makers, and if they are don’t have a tech background so they know firsthand how much time is wasted without investment in DX, then it’s not really something you can force.
You can try putting it in terms of money, with things like “due to this, our team wasted 15 hours last week, which at the average salary for such a position, it basically costed us $5000 just last week. That happens almost weekly, so the annual costs are these. In contrast, we can dedicate a developer for a week to fix this, costing us X and saving us Y from that point onward.
But it would be way easier if the decision makers that can push technical direction have a technical background and understands that sometimes it is needed to put pause on feature development and make sure what you have built so far is stable.
> To the engineers: How have you resolved this?
Lots of ways to resolve this.
One is, by having representation at the top level. A PM can be readily overwritten by a CTO/VPE or competent CPO in a normally functioning organization.
Another is having representation on the team. A PM should be counterbalanced by an Engineering Manager or Tech Lead who can advocate for things like DX, tech debt paydown, etc..
Another is, DX should be a part of your normal operating procedure. Reducing build time usually is not a single two week project that you do and then you’re done, its a thing you have to constantly do work against over time.
Another is, ask the PM for their rejection of the ticket/subject/etc in writing. This can sometimes freak people out a bit. Formalize the denial.
Another is, wrap DX together with tech debt, rearchitecting, performance improvements, etc. and pitch it all together. DX is easier to reject, while things like “if we don’t do XYZ the app explodes” are harder to reject. If someone rejects that type of stuff, see the previous suggestion.
Another is, after advocating for changes and being denied, let the failures happen, particularly in a controlled environment if you can. You should definitely pair this with the point two bullets ago.
Another is just plain old success. Many organizations have this hair-on-fire point of view because the business has not yet succeeded. Once the business finds success, these types of issues are lessened. Often times, startups have 2 apps, one that gets worse and worse over time via tech debt and such while you learn the business/market/etc, and the second one is built “right” to replace it.
Finally, I’ve found that fellow engineers do not know how to correctly frame things like DX, tech debt, etc into terms that non-engineers can appreciate. Practice those types of skills and pitch DX projects in terms that impact the business, not your personal day to day.
Ways to overcome.
1. Have a day dedicated to it weekly
2. Build in x% of the time needed in each feature. However you do the estimates just pad 30% in to cover these debt with or without permission. If inexperienced or stubborn PM says something you can bring up the initial chart
Less mature options include
3. Fire pm
4. Ignore PM
5. Find new job
6. Engineers all get on board to fix it and ignore any attempt to get a thing else done. When asked or challenge refer said PM to another engineer. Keep doing this until they are upset explain to them PM experience doesn’t matter.
dev with 10+ years of exp here. i worked at a startup with a similar situation as you. however, they let me go full time on developer experience because of my tenure / results, and the result was 100% retention of developers on my team (10+ engineers) over 4 years. through prioritizing DX, the culture was great and everyone on my team loved it. but even then management was disconnected and didn’t see the value
you should pad your estimates going forward. they’re never going to allocate 2 weeks solely to improve developer experience. instead you should just chip at it during every sprint. if a feature will take 1 week, just say it’ll take 1.5-2 weeks. what do PMs know about how long it takes to build something?
It really depends on the type of debt. If you are losing developers regularly or shipping an unreliable product then you are failing.
hey, 15 years of dev here….
to solve this you factor in cleanup into every task, every feature, every deployment.
why? the difficulty of your job is not the PM or CTOs concern…it’s your concern…the difficulty of their jobs is their concern…stop asking for permission to make your job easier / better… and yes, you should make it easier and better…it’s better for the company and the PMs and CTO does this daily…work smarter, not harder.
if/when you get pushback ask them if they want you to tell them how to do their job…they will immediately stop pestering you because they don’t want you squeezing efficiency out of them…but they will do it to you because it’s easy.
I have seen this even in Fortune 1000 companies.
Most of the time they are busy over promising the business, not even the end-users, and end up making features take longer due to not spending time improving processes. Or the end product is delivered and they ask, why is it taking so long to update X? Well, because as I mentioned previously we did not take the time to improve Y.
You need to fight to get these things done. Even then, they ask why did Z get pushed back?
It’s a never ending battle. Lol
This should not be a PM decision.
This brings up some really interesting questions. As someone in an exec leadership role in PdM, I’m all for predictability in release planning and cycles. If you had come to me with the data showing the benefits of your changes and how my teams could better plan releases, I’d be all for it. PdMs need to remember that not ever release is a “feature release” and sometimes you need to pay down the debt.
To me, this brings up a very interesting question that is rarely discussed: the trust relationship between Engineering and Product. Not intending to hijack your thread, but I think it’s something that really should be discussed more. Where should product sit in the org structure: under marketing? under engineering? directly under the CEO with it’s own leader? All of those things will influence those relationships and perceived power within the startup.
I’ll ask a bit of a flippant question, but I’ve also seen it used as a tactic to address your question of tech debt and release planning: How does a PdM know and trust that the estimates for feature X are actually 10 man-weeks vs 2 man-weeks?
Hear me out here. I’ve personally experienced a lot of cases where my VPE would artificially inflate the estimates of features he didn’t want to do or didn’t think were as important as some of the pet projects he wanted to get done. The product function rarely has the expertise or the organizational power in a startup to call BS on estimates which can turn into engineering controlling the roadmap. Unfortunately roadmaps aren’t a blank check of resource so we have to decide what will fit and if the proverbial juice is worth the squeeze.
To answer your question in the most unethical way possible: if the PdM won’t listen to data on how your ideas will be best for the overall product moving forward, over-inflate your estimates on other features so the PdM has no choice but to choose paying the tech debt.
I never had been on a formal dev team(paid) honestly, I would just watch what happens while I fill out for other jobs.
Not sure how to argue with someone who believes they will win a race by driving a slower car.
Sounds like you need to either care a lot less, or find another gig.
You have the domain knowledge to know; they don’t (aka this is why I hate PM’s, especially those in my area of work who don’t have the relevant domain knowledge).
So many PM’s these days with 2~3 years of experience who think they’re somehow industry experts after being promoted a few times during the recent VC bubble.
Only people worse are the former bartenders who think they’re enterprise sales experts b/c they were hired by Salesforce during the same overhiring bubble before getting laid-off.
PM shouldn’t have an opinion on tech debt/quality. How are you taking a managers opinion on a tech design matter? What do they know about that? Ofc they will say that.
There is no PM in the world that says lets delay this product for 2 months!
>To the engineers: How have you resolved this?
You don’t
Tech debt is a good thing
You don’t want perfect code, perfect code doesn’t exist and there are diminishing returns on effort.
Getting something done 80% is maybe twice as fast as 90% and same for 95% is twice as hard as 90%
That extra 10% isn’t going to change the product and in fact it should be considered nothing more than a risk factor
Will it make development harder in a year? Yes
Will it matter if the company is dead in six months? No
Engineers love the idea of working on and building awesome code but awesome code is expensive and most of the time good enough is more than enough.
All code at the major profittable companies is halariously shit, I should know I built some of it.
Good code doesn’t make money, products make money
In my experience there are two types of companies, those with tech debt and those that failed.
source: Senior Software Engineer
Edit:
To give an example.
My current contract has an inefficiency that is costing them roughtly $1000 a month in database cost. We know the fix, we know the problem, but it’s going to take at least a week to implement.
We bill software engineers at roughly $1000 a day, so IF a SINGLE dev fixes this and some how makes it cost $0, we will only save any money after 5 months.
Realistically it won’t hit $0, maybe $500, maybe even $400.
Is it even worth bothering with when there’s other work to do?
3 letters: ROI
Anything we do in a startup or a big company can be quantified to a some point. Blank statements like: DevEx doesn’t matter or DevEx is the only thing that matter do not cut it.
Think you have a $100 and you are burning 1 dollar a day. You can slow down the burn (bottom line), you can make more money (top line). To make more money, you can burn $10 to make $20 in the next 5 days or you can spend $10 making 5. There is no silver bullet, it is all math and understanding your current standing.
“Developer Experience doesn’t matter”
hahaha. hahahah. That’s a good one! rich! Those developers, we’ll throw ’em in the basement and communicate with them through a pipe in the floor! s/
I’ve dealt with lots of tech debt related issues at start ups, seen some projects over build, and other projects become unable to grow or refactor, and the only solution be a full re-write, which can be pretty destabilizing and risky.
What I’ve found works, is that you empower engineers with a good sense of the business to be the final arbitrator of what goes into the codebase, and be able to engineering developer velocity features, with full context on what’s going into the tradeoff space between “getting it out in 4 weeks”, and “we have engineer-years to do this thing”. The PMs shouldn’t be the stakeholders for the code, the engineers should be, as they are the only ones experienced enough to make the right calls.
Ignored dev experience equals mounting tech debt. Bad trade-off.
I can tell you this, with very limited experience, I’m looking at salsforce.com as I type this trying to figure out API best case integration into my web site. ExperienceMatters!!
a PM is by definition a guy that can’t even program, and struggles with all fields of exact science.
They can speak, I will sometimes listen, but it’s me who decides.
Same issue here. Manager only focus on buggy product than addressing underlying issues
We’ll take all the Developer Experience feedback we can get over at Codegiant (https://codegiant.io). DevEx matters most, particularly as toolchain sprawl keeps increasing.
What you’re describing is a company wide schema. It’s not limited to tech debt and will inevitibly cause waves through the entire company. Might just be a misalignment for you. Not bad people in my experience just a lack of awareness and foresight.
Y’all need agile.
Your product owner tells you what the business needs and that’s it. They don’t decide deadlines, they don’t decide priorities, they don’t decide what you’ll be working on etc. They’re not the lead engineer.
Your product owner should be telling you that they need a man in space in 2 years and boots on the moon in 10 years.
How are you reporting on your data. You’ve done the hard work of showing how much time you’ve saved.
Now translate that to CFO speak. Show how it reduces operating expenses or gets the product to market faster.
How does it translate to a Cost of Goods Sold metric?
https://www.thesaascfo.com/what-should-be-included-in-saas-cogs/