There’s nothing quite like the rush of starting a new job and whipping out projects, particularly at an organization where technology is not generally prioritized. Management falls head over heels for your ability to stand up and deploy marketing requests, and as you crank out project after project, it seems like you’re going straight to the top.
Then one fateful day, an urgent request comes in: “We have a real opportunity to capture some immediate sales, but we don’t have an avenue for tagging and remarketing to these leads. What can you stand up before the week’s end, in time for the conference? Surely, you can get something set up?” They stare back at you on a Teams call while you archetype an API service to accommodate the traffic. With your coworkers depending on you and your hubris swollen from recent victories, you make a choice. To meet the deadline, you turn to another language or framework to stand this up, because you are a go-getter and a wizard. As you quickly deploy the dirty codebase, and as your accolades are sung from on high, you think, “I’ll lace this up with our core later. They needed it now—and I did it.” You have reached peak developer-nirvana; none dare question your skill.
Months later, marketing and management requests have continued non-stop and (of course) you’ve had no time to lace everything up. You think back to that fateful decision to implement a quick fix, not anticipating that the organization would utilize it on a daily basis, requiring constant updates for every unique sales avenue. In your haste, you built a system that is functionally not operable within the rest of the ecosystem—and you are now subject to that decision. As the requests take longer and longer to work, questions start to arise: “Is our developer losing his touch? Why is this taking so long when it used to take minutes?” Instead of articulating the issues or communicating the challenges, you keep applying patches and quick fixes. As the choices you’ve made in your haste pile up into a series of compounding issues, your turnaround time slows, but the requests for new projects don’t.
This is a very real story and one that I’ve been party to many times. It’s so enticing to push projects out the door, to woo and impress colleagues and supervisors, but the stark truth is that even the smallest projects should have proper review periods and attention. These daily choices of cutting corners and improperly aligning architecture, all without a real understanding of the organization’s business goals, can create a bad situation within small teams. This is particularly true in companies where the focus is not technology and where developer resources are spread across requests from sales, marketing, and engineering. It’s a tricky place to be as a seasoned professional, much less as a developer early in your career. Do you push the envelope or do you push back?
Compounding the issue in a low code-oriented environment is a fundamental lack of experience. In organizations where a developer functions as a database admin, internal IT, and the catch-all for anything “tech-y” (their words, not mine), the individuals who fill these roles typically have not yet specialized and often don’t have team-based experience. They simply operate and hope for the best.
This conundrum certainly goes beyond software development and applies to many aspects of work performance. Going faster is not always better: those immediate gains may not be worth it. Greenfield projects, projects starting from scratch where no code has been written or committed, are particularly fraught with the potential tech debt. As our favorite uncle explains, “Software teams start out fast, but they make a mess. They wanna go fast and as they make a mess, the team gets slower and slower until they bottom out below 1% of their original productivity.” Without any defined goals, objectives, and long-term insight into what the businesses goals are, these small decisions can, and will, bite you in the pants.
In our cautionary tale, let’s say years pass and now the development team is basically unable to get anything done at any reasonable pace. The company as a whole has lost patience and needs to get development back up and working, so they bring in more developers to solve the problems. With no other cohesive thoughts or plans, they just throw more staff into the mix and the new devs have to figure out what all of this nightmare is. This hydra of a flying code-spaghetti-monster now has more people to work on it, but the same fundamental issues remain!
The software development engine within a company is like the power grid: it’s a given that it works, and there are no celebrations or accolades for keeping the lights on. When it fails or goes down, however, everyone’s upset and what’s left is assigning blame and determining culpability. Unfortunately, in many industries, the responsible application and development of software is not considered until there’s a problem. There is no “working well” for a developer in an ecosystem without insight and intuition as to how difficult the workload is for various projects or positions. The black and white reality is simply ”Working” or “Not working, what the hell is going on, do we need to fire them, why is everything so slow lately?”
This can be incredibly frustrating for developers. In my own experience, the person in the worst position is the developer brought in to clean up another developer’s mess. It’s now your responsibility not only to convince management that they need to slow down to give you time to fix things (which will stall sales), but also to architect everything, orchestrate the rollout, and coordinate with sales goals and marketing. Oh, and let’s not forget actually producing the code to resolve the underlying issues. It can, at times, be an insurmountable problem. A developer in that situation has to wear a lot of hats. They need to be:
● An advocate to management and by extension the C-suite.
● A project manager.
● A marketer to understand the features and desired functionality both now and down the road, to make selling the product more simple with defined pipelines and marketable features.
● A decision maker, willing to make tough calls with regards to future compatibility of the services, how they interact, and what third-party tools they might need to integrate with to ensure the rectified code will be usable for the foreseeable future.
Last but not least, they need to be a good developer to fix the mess. If you employ a developer who can manage all those responsibilities as well as their day job, I guarantee you aren’t paying them enough, or they’re already looking somewhere else.
What can developers do to combat decisions that prioritize speed over stability and growth?
The solution is not glamorous, showy, or exciting and goes against what most sales-centric orgs—those that prioritize quick sales and immediate revenue over long-term stability and growth—typically want in a developer.
- Take your time. We must think through things, put the metaphorical pen to paper, and work through any potential issues. While there may be quick and easy highs for delivering new products or features quickly, long-term speed and maneuverability without a reconciliation to functionality and future development efforts isn’t sustainable. Unless you are a developer who churns through orgs every six to nine months, you won’t be building a career anywhere without thorough research and planning.
- Don’t accept new projects from just anyone. If possible, build your own processes for taking ownership and identifying the issues with projects that you are given. Assert yourself and create boundaries so you aren’t stuck making breakneck codebase changes and Friday night deployments. This is especially important if you’re the only developer at your org or one of a small team. Brian the marketing intern should not be sending you urgent requests for a user feedback function on the company blog without providing some serious thought and planning.
- Ask the right questions. This ideally starts during the interview process for a prospective job. If you notice any signs of a toxic development environment, there are likely some significant alignment issues within the organization.
Common red flags to watch out for:
- No project planning, either in methodology or in practice. If there’s no concrete recording, goal-setting, and milestones, your performance will be measured in a similarly haphazard manner.
- Describes the ideal candidate using words like “wizard,” “code ninja,” or similar nomenclature that reveals that they will expect you to perform magic (literally or figuratively).
- Huge list of desired traits and disciplines. Project management experience, senior-level developer experience, data scientist, and web developer, all while having exceptionally specific industry experience in whatever sector they work in. Chances are they’ve recently added “AI experience” to the description.
- Compensation is not in line with the duties defined in the posting.
Setting expectations in interviews
If you do land an interview, be sure to ask some hard questions and have stringent requirements. Speaking as a hiring manager, hearing the following questions indicates to me a candidate who is willing to speak their mind and ask questions that are pertinent to the role and how they’ll see themselves fitting in:
- “Is this position a new hire, or a replacement?”
- If it is a new hire: “What problems are you trying to solve in this position? What kind of professional and architectural growth do you foresee in this position?” “What’s the biggest flaw with the product and development pipeline currently?”
- If it’s a replacement: “Why did the position become vacant?” “What made them want to leave?” “What would you do differently about the structure of the position given that it’s now open, again?”
- “What are some goals for the position in the next six months?”
- “How is performance measured at this organization?”
- “Can you describe the typical flow of how a project is started, iteratively worked with progress reports, and delivered? What are some weak points in this system that you would change?”
- It should be a red flag when a prospective manager, a colleague, or employee that you’re meeting with says there are no problems with a given product. Another story for another day, perhaps.
If you’re in an established role, be extraordinarily thorough when requests for new features, expansions, or questions come through to you. Start by setting expectations early on. Asking qualifying questions about the specifics of how success will be measured or various aspects of functionality will highlight anything that’s unclear. It’s the responsibility of any technical project owner to drill down and touch on all of the nuances of new ideas and projects to determine feasibility, ownership, and potential future gremlins. By consistently setting the expectation that future projects will undergo the same scrutiny, you’ll create a solid foundation for long-term success. Providing some scaffolding for project development and ideation sets you on the path for consistency and reliability in projects you interact with, and that will pay dividends for years to come.
Let’s assume the worst: You’re in this situation, right now.
Obviously this isn’t ideal, but pump the brakes a bit. Sit down with the powers that be and explain the complications. It may be a difficult conversation. There may even be friction, but if you are being expected to shoulder this load, while planning and deploying the transition (let alone your daily tasks), you must make stakeholders aware of the details. Plan, plan, plan, and most importantly ask questions of your community as a whole. It’s important to know what tools exist, how they can be responsibly applied, and what’s the correct solution to your specific set of issues.
If you do not act, as issues mount and work grinds slower and slower, people will notice. If you fail to address the underlying issues, you may just be dragging out inevitable doom. Speed is a gamble that will cost you when a new feature is requested or a seemingly small ask for a new feature brings about substantial problems.
Be honest with yourself
The cost of speed is something I unfortunately had to learn the hard way. Through copious planning sessions, training, and briefings, we were able to dig ourselves out of the pit I mentioned at the beginning of this article, but it was strenuous and definitely not something I wish to repeat. Moving fast can be an attractive prospect, but with so many emerging technologies, frameworks, and paradigms, it’s easier than ever to fall into a tech-debt trap. Creating a thorough plan, asking the right questions, and over-communicating are skills that I’ve found useful and have helped me grow both personally and professionally. Making mistakes can be the best tool for growth and learning, and at times, a sour reminder of how much you really don’t know.