19 ms·

As a marketer, let me tell you how things go: 1) You have a marketing project that is speculative (as all marketing is). Say it's an API hookup and some automa

by cm2012 3y ago

As a marketer, let me tell you how things go: 1) You have a marketing project that is speculative (as all marketing is). Say it's an API hookup and some automation between some tools. 2) You submit your project for prioritization by the dev department. 3) It gets done 9 months later. The specs are wrong because there were so many layers between the marketer and developer and the developer has no context for the project. You submit edits which get prioritized and takes another few months. OR You get Zapier approved by security once. Then for every project like this you fiddle with it until it does what you want. Total time: A couple of weeks. No code removes friction from the org. Developer time is always the biggest bottleneck at any org I've worked with. Anything that let's you get around it is worth its weight in gold.

dgellow 3y ago
> No code removes friction from the org. That’s so true. It’s not to build quickly, it’s to keep the agency within the non-engineering department.
- WWLink 3y ago
  To me that sounds like the argument from a business department in an engineering org. The solution is for your department to hire its own software developer(s). I'd say the same thing for an organization that is heavily business-oriented and has an engineering department that gets kneecapped by the business-team-focused IT department that can't appropriately support the engineering department.
  - bell-cot 3y ago
    > The solution is for your department to hire its own software developer(s). Vs. the reality, in most large org's - that plan gets shot down faster than non-union electrical contractors in New York City.
  - sfink 3y ago
    And people wonder why organizations have such high headcounts...
drpossum 3y ago
Having been on the "actually has to deal with the aftermath of investing in no-code" that is when the cost comes in. Out of the literally dozen or so places I've worked and the half of those that went heavy on low code, it has never worked. The complexity becomes too great after a few months of "wins" and the system falls over on itself because the people using low code need increasingly complex things. But I assume as a marketer once you've finished your sale you move on to the next one. Because that what they all did.
- cm2012 3y ago
  The trick is to use the no code implementation to learn what you need to build from scratch. Don't think of it as expensive time to redo - think of it as valuable work finding out what your org actually needed. I'm sure you know that people don't even know what they need when they send developers their brief half the time. It's like excel. Yes excel is used for all sorts of messy things its not ideal for, and would be better built by a programmer. But the excel file teaches the developer what their co workers actually need the product to do. It's not wasted time, it's invaluable.
  - mellosouls 3y ago
    That's a good observation but falls apart if actual developers have to maintain the Rube-Goldberg app created by well-meaning "Citizen Developers" (© Acme No-Code Corp) using a framework which is only intended for prototypes but not fit for purpose beyond that. Of course, that's a management issue - but managers who are easily taken in by consultancy sweet talk about the power of these frameworks are not always the most likely to understand the problems they cause or have the wisdom or resources to clean up afterwards by doing what you suggest.
    - The_Colonel 3y ago
      We can't design tools which are incompetent-manager-proof. There are companies with incompetent management having no clue about software development, but business selection should eventually sort them out.
cbm-vic-20 3y ago
There's a reason so many internal corporate applications are built as Excel spreadsheets: there's a lot less friction than having to get a development team involved.
- olavgg 3y ago
  This is so true. Oil & Gas loves data and excel. Everything starts with Excel, and when it outgrows Excel the next step is getting developers to build a better solution. I absolutely think this is the right thing to do. If ChatGPT can make basic programming eaiser, and Excel ships with easy and excellent Python integration, we will see more Excel.
willsmith72 3y ago
This is why we have product teams. Your experience is the norm, and no matter how much they may think otherwise, 90%+ of software teams are working in waterfall/delivery/feature teams. Product teams are the solution, but very few orgs are willing to completely flip their structures to get there.
- josho 3y ago
  I agree. But what happens when the project finishes and now any remaining work has lower priority/roi than other projects? Is there any guidance for that?
  - willsmith72 3y ago
    product teams are long-lived, unlike projects if someone (say someone from marketing) has a need for the product, and it gets de-prioritised, someone has decided the marketing person's needs are less important. That's why product teams have to be cross-functional and have ownership. You can't just have a board of execs 5 levels of hierarchy removed switching and swapping people randomly. also why there are so few product teams. There aren't many execs willing to put the trust in their people to give them ownership of products/problems/opportunities/outcomes, without wanting a micro level of control on the solutions. Which is always hilarious because they hired these people in the first place (or the ones who hired them etc...)
    - c_o_n_v_e_x 3y ago
      > without wanting a micro level of control on the solutions. HiPPO attacks are real. Nothing like having countless customer interviews only for a dataless HiPPO to come in and maul your product. I feel like PMs are used as sacrificial anodes in some orgs. The HiPPO controls product via the PM. When the product inevitably flops, it’s the PM’s head on a spike.
      - Sylamore 3y ago
        Highest Paid Person?
afarviral 3y ago
This had been my experience as well. You can replace the low-code solution with a junior coder in a non-coding role. Creating a shadow-IT solution will be a fraction of the cost and time. The risks are the lack of governance and amateurishness, though. Solution: have vertically integrated agile teams so that developers are in the problem space with experienced peers and governance. Why don't more orgs do this?
- marcosdumay 3y ago
  We managed to move almost the entire shadow-development from our organization into a low code platform. It works great. The systems already starts in a usable format, and when they need intervention, they are in a very standard format that is easy to start working with. Besides, today we also send applications back to shadow-development, and they are able to maintain them until something big changes. Shadow-development isn't very shady around here anymore.
  - cjalmeida 3y ago
    This here. Fully centralized IT is stifling, shadow/decentralized is chaotic. Good structures come from hybrid, matrix-like approaches.
  - code_biologist 3y ago
    What's the platform? Something you'd recommend?
    - marcosdumay 3y ago
      We use Oracle Apex. The platform itself is quite good. But it only runs on Oracle, so I'm not sure I recommend it.
      - thorin 3y ago
        We used Oracle Apex for years with loads of complex business applications. If you already have Oracle licenses it's a must-use. It's definitely lo-code rather than no code as you really need a bit of db modelling, sql, and development skill to get it working well. It can also be hard to work out how to customise things but you can get it to do almost anything CRUDy.
silpol 3y ago
there is reason why John Woods wrote in 1991 Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability. https://stackoverflow.com/a/878436/499698 https://stackoverflow.com/a/878436/499698
HeyLaughingBoy 3y ago
I never really got this until I was talking to a scientist in our organization and she was bemoaning the fact that it was taking her team hours to do some basic analysis of files that our instrument exported. "So why don't you make a request for Software to add that data to the file? We could do it easily enough." "I did! but they keep telling me it's not high enough priority so it gets pushed out to 'the next release' every time" "OK, I'll write you an offline tool to process the data." Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature. And this was taking a biochemist on average 3 hours every day to do by hand!
- BeetleB 3y ago
  > Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature. The counter to this is that this tool now has no support (which may be fine depending on the tool). I remember my first job which was 30% SW and 70% other engineering. We wrote a few tools to automate stuff that our customers used. One of our customers came to my manager and told us he had a tool we wrote over 5 years prior. It was a small Perl script. Their data source had changed formatting a bit and now the script no longer worked. They wanted us to update the script. Several hours were spent between the two teams arguing. My manager did not want to own it. He said he had no record of it, and none of the people on his team had any memory of it. We did not own it. They kept insisting "One of the engineers in your team (who had since left the company) wrote it, so you own it!" I pointed out to the coworker that the request was so trivial we could have solved it in under an hour, and the company had lost more money by arguing. The counter was "If we fix it, they'll keep coming back to us and in the long run more money would be lost." Over the years, I've realized how right he is. I do occasionally write simple scripts to help our customers, but management always makes it clear to them that this is an unsupported prototype, and the customer needs to maintain it.
  - hooverd 3y ago
    I think some teams could do really well to have an embedded developer- someone who can understand both fields decently enough.
ipaddr 3y ago
Then you want to use your data in an internal system and all breaks lose. Usually what happens the structure of your has to change because sales now wants to sale the product in a different way and your no-code tools can't support it. No-code tools are great for solo founders but terrible for enterprise anything
granshaw 3y ago
I’ve long thought of starting an agency where “we’re developers for marketing depts”, ie, we’re seasoned devs, hire us and we’ll jump into the dev side of things and the company’s codebase, make the changes needed that you want, keep us on retainer if you want updates, and that’s that. What do you think of that?
- letsdothisagain 3y ago
  Yes, it's called consulting and it's great work if you can get a consistent client base. I genuinely wish you the absolute best of luck getting a consistent client base.
- asielen 3y ago
  Some of those exist, usually billed as implementation partners that also can do whatever dev work you need. The problem is getting marketing leadership to believe they need those services. Usually you have a handful of technical marketers shouting from the rooftops asking for dev support. The CMO goes and talks to the dev team and they are reassured that there is no need to outsource, there is a perfectly good team in house that will get around to it eventually. I've had the best luck bringing in a firm as part of an implementation and then keeping them on for a few months to help with odd jobs in the guise of support. Executive leadership in sales and marketing is typically clueless as to what their teams need too be successful. It isn't in their job description, it isn't what they were hired for.
  - granshaw 3y ago
    Very interesting and useful insight, thanks!
MuffinFlavored 3y ago
> Say it's an API hookup and some automation between some tools Why aren't companies better at putting requirements/user stories/whatever into Confluence/Jira tickets? Why do there have to be 10 layers in between, constant followups, repeating yourself? Why do there need to be meetings when you can just keep a ticket updated with all context?
- deepsummer 3y ago
  Because it's hard, unpleasant, and often 'invisible' work that no one wants to do. Often it's also frustrating, because if you write more than 3 lines, many devs don't read it.
bitwize 3y ago
As a developer, let me tell you how things go: 1) Marketer puts together something in their no-code tool of choice. For a while it does what is needed and becomes a critical part of the marketing workflow. 2) New requirements come in, maybe it needs to integrate with a new API or database. Marketer is too busy marketing to waste time with all that plumbing. Thankfully there's a department full of people whose literal job is dealing with all this crap: the developers! The no-code project is thrown over the wall and some coders are assigned the task of rat-wrestling with the no-code tool, as well as writing code against their crufty, idiosyncratic API -- code that cannot be tested using their usual testing tools because it must all live within the no-code runtime -- to fill in the gaps in the tool's functionality. Their productivity grinds to a near halt. This becomes their job for months to years because the no-code workflow is Mission Critical, Essential to the Business, and if it breaks or cannot be made to do what is needed billions are at stake. 3) That thing you wanted takes 9 months to complete because now the dev team has all the no-code cruft on top of their work building actual software for the business. Please, for the love of God, just do us all a favor and learn some Python. When you throw that over the wall for us to maintain, at least we can version-control it, test it, and integrate it with our CI/CD.
- bennyelv 3y ago
  Big assumption that! Code written by non-developers, or even by the type of developer who is a tradesman rather than an engineer is usually untestable. The biggest and only advantage is that you can read it and debug it in order to understand it, which you can’t do if it’s embedded in a mess of lines and boxes with logic hidden several clicks down in a low code platform.
droptablemain 3y ago
- Developer time is always the biggest bottleneck at any org I've worked with. Anything that let's you get around it is worth its weight in gold. To each their own I guess, but it's hard to imagine NASA going to the moon being led by a marketer or business analyst. Hard things are hard. And hard things done right take time and precision.
- pas 3y ago
  there's no need to do them right. and most no-code platform already constrain the solution space brutally anyway, and that's good enough in most of the cases.
- nouveaux 3y ago
  Nasa's biggest challenge is marketing. Their funding is dependant on public perception. Nasa does not get more money by having better engineering. Nasa gets more money when congress thinks it will get them more votes with their constituents.
  - acuozzo 3y ago
    > Nasa does not get more money by having better engineering. But several catastrophic failures in a short timeframe can ensure it gets no money at all!
    - nouveaux 3y ago
      My point isn't that Nasa should prioritize hiring good marketing over good engineering. Nasa has good engineers. My point is that their biggest challenge now is their public perception. The general public does not care about Nasa's mission. SpaceX is far more popular than Nasa. If you stop to think about it, SpaceX is just making travel cheaper and it shouldn't be that interesting. If Nasa can make their mission more fun and interesting, they have a better shot at a larger budget.
austin-cheney 3y ago
No sympathy as this is entirely a self-inflicted wound. The problem is that very few people, at each stage, are qualified to be there. Let’s not kid ourselves with pride and self-congratulatory bullshit about how awesome we are. Most people require several layers of abstractions to do their jobs to cover competencies they should know but don’t both in technology and marketing. The reason this occurs is because there is no baseline of competence in software, so everything becomes wildly subjective and therefore biased. To solve for that business imposes tools to make things easier, but really it’s to commoditize candidate selection. That eliminates some amount of training costs up front but instead requires a larger labor pool with lower product flexibility. More people of lower competence with far less ability to pivot as requirements change and everything takes longer. No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before.
- Nostromos 3y ago
  It's easy to describe this as self-inflicted when you don't understand how large orgs work and have never had to consider how a security team deals with a large org, each piece wanting their own version (or multiple versions) of this solution. Qualification isn't the issue because we (the US, US tech, SF/NY, etc.) have a lot of qualified talent, both in eng and elsewhere. The issue you describe with competence IS an issue but not for this. Your final sentence is correct but not right. Basically, you're right and you're wrong and I should probably write something longer form but won't get to it for months. I'll give you an upvote in lieu of that for making me think deeper about the topic.
  - Nostromos 3y ago
    And after re-reading my first sentence, I apologize for suggesting you don't understand how large orgs work. That wasn't fair and I don't know your background. I'm gonna leave the post unedited for honesty's sake.
- lucasyvas 3y ago
  > No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before. I don't want to dismiss this point, because it's real. But there is an alternative. I've been brought into these talks with other departments before, and I evaluate the tool from an engineering perspective. If they want to use a true no-code solution, we don't block it but raise to the director level that we will under no circumstances support the use of the tool - we are developers by trade and that's what we're paid for, so they are responsible for everything to do with it and bear all responsibility if it fails to adapt. If it's low code and has an API, we generally much prefer that because it means we can actually deploy and properly maintain the code that might be needed to support integration with it. We don't copy and paste fucking code and we don't drag around UI elements with if-else statements - it's simply not our profession. You wouldn't ask a carpenter to assemble IKEA furniture. It's a waste of money and time. So yes, the solutions might "need" a developer, but no sane director would allocate one. It makes no sense.
simonebrunozzi 3y ago
Also reason why Canva is worth a lot. Similar pain point being solved.
rodgerd 3y ago
> Developer time is always the biggest bottleneck at any org I've worked with. Also: you are an expert in something. Half the time the SME will spend a large chunk of their time being lectured by a developer with no domain knowledge, but a deep conviction that the SME is doing it wrong.
- cm2012 3y ago
  The worst thing here is when developer leads have strong personal feelings about things. I've seen a company sabotage its own growth for years because a CTO was uncomfortable with Javascript tracking tags. When they finally relented we were able to 2x our growth rate.
phpisthebest 3y ago
>>Anything that let's you get around it is worth its weight in gold. I have a novel idea.... HIRE MORE DEVS!!!!! I know, I am crazy
lghh 3y ago
Or, and hear me out in this, you just walk over to the developer and talk to them? Or go work for an org where that’s possible?
- marcus_holmes 3y ago
  Then the dev team never gets to write anything because they're always being interrupted. On top of the fact that developers are almost never in charge of prioritising their own work - that's what project and product managers are for.
- cm2012 3y ago
  That worked extremely well at a past org, I had a partner and we worked really efficiently. Until the project manager put a stop to any shadow dev work.
entontoent 3y ago
Every time this happens at the companies I’ve worked at, it’s been because the business didn’t think the need was worth prioritizing over the other business needs. I’ve never been in an environment where IT got to make the decisions about what gets prioritized. If the business doesn’t think something should be prioritized, but a marketer decides that they really want to have it, I’m not sure it’s a great idea to go around what the business has prioritized. Most of the cost in software comes from maintenance of legacy systems. I hope this new no-code solution is something a department has decided to maintain indefinitely! I my experience, after the marketing person quits, the no-code solution gets chucked across the fence to IT, the no-code provider stops supporting their tool, and IT is forced to build a new one as an emergency a few years later because “the business has been using it for years.” In a healthy org, if something is truly good for the business and will create global gains across the company, it should hop to the top of the priority list. Admittedly, I’m still hunting for this theoretical healthy org, though.
- cm2012 3y ago
  No time to write a full comment now, but I would compare the fully planned org to failed communist states vs the more chaotic capitalism that does better.
- asielen 3y ago
  Usually the marketer is stuck between a rock and hard place. A semi-technical marketer will report into a completely non-technical org led by a CMO who thinks pivot tables are black magic. But they same CMO has promised the CEO and the board that they can integrate their product analytics into their pipeline performance reports, and have it by next week. Sure the marketer can say no, but the CMO doesn't understand why it is a no because their buddy CMO's marketing team does it already (not understanding the work that went into making it happen at that company). So the CMO interprets no as a performance issue not a technical or process issue. And this happens all the time. So at some point the marketer is stuck between building a one off report in a spreadsheet or using the tools they have access to (usually something like zapier, or some marketing automation platform) to build a good enough solution that gets presented at the board meeting, and everyone is happy. Play this on repeat with, marketing, sales, hr, finance etc every month. The alternative to low code isn't code, it is excel spreadsheets.
marcus_holmes 3y ago
This is the reason we have desktop computers. Lotus 123 (and then Excel) enabled ordinary folks automate bits of their jobs. But it went through a pattern: - Spreadsheet was created to help do task X - Spreadsheet grew until task X was entirely contained in the spreadsheet - New hires were trained to just use the spreadsheet instead of understanding the task - The person who built the spreadsheet left the department - The business needed a change in the task, and that meant changing the spreadsheet. But no-one in the department knew how the spreadsheet worked any more. - The IT department gets a new urgent task to change the spreadsheet to allow for the change in the task. The spreadsheet is a complete mess of spaghetti, evolved over years with no documentation. It will take months of work to untangle it and make the necessary changes (and document it for next time). The developers pitch that they could build a VB app for the task in less time than solving the spreadsheet and that would improve the situation going forward. - The IT department kicks off a project to build the VB app. Immediately the business department adds a ton of loosely-related requirements because they've always wanted them in the spreadsheet but no-one knew how to add them. - The project founders under its own bloated weight, scope creep moving it from a couple months out to a year's project. - Meanwhile the business department works out another way of doing the task - 18 months later the IT department delivers the app as promised. But it's wildly out of date with what the business department is doing now, so no longer fits the use case it was designed for. I've seen this happen a few times. It'll be the same with Zapier-derived solutions - in two years you'll have left the organisation and then an API changes and the thing you built falls apart, no-one knows how to fix it, and devs don't want to look at it. Everything is more painful this way. It's worth its weight in gold until suddenly it turns to shit.
- zubairq 3y ago
  Describes a scenario I was in almost perfectly! :)
- foxbee 3y ago
  This is a great example. Low-code is not the solution to everything, like spreadsheets were not the solution to everything. With low-code, it really does help if the platform is easily extendible and open source. Also, it's important the IT team owns the low-code platform.
devoutsalsa 3y ago
Good for marketing now. Horrible for maintaining developer later. I was recently working on a marketing application and the it was the worst experience of my development career. There's was zero afterthought about what it would take to keep thing running once it had been launched. The only thing worse than the intractable bugs was the unwillingness to invest in its maintenance. I'm not usually fan of a complete rewrite, but in that case I wanted to nuke the site from orbit. It's the only way to be sure.
- topkai22 3y ago
  I spent years as a consultant following a basic pattern: a subject matter expert wrote a tool or series of tools in something like excel or access. The tool got popular but didn’t scale. My firm would get brought in to “fix that and then automate all the processes.” When I was a junior consultant I’d get angry at how kludgy and inelegant the original solution was. After a few projects I’d realized how hard producing software that business users actually use can be. My response now is “this is amazing, look how far you’ve come. Let me help you go further.” Yeah it stinks and yeah I often did from scratch rewrites, but the work done proving the idea/system was valuable was why I had a job in the first place and had delivered more value then I could as a developer.
xtracto 3y ago
You are so right. I've been CTO of several startups of different sizes , and the frustration of non-product teams to get ANY automation love was terrible on each of them. And the funny thing is that usually, very simple things would mean a lot to said teams. I saw it for marketing, compliance, legal, finance and even RH. But the blame is not the tech team but business/ceo office: they set the priorities . Otoh the comments here make me chuckle. How does the saying go? You can't make someone understand something if his life depends on not understanding it (or something like that in English o think)
brutus1213 3y ago
Not in this space .. is Zapier the same as IFTTT?
- cdaven 3y ago
  Yes, I think Zapier is a B2B version of IFTTT.
asielen 3y ago
As another marketer, this is 100% spot on. And it isn't a technical gap, but a process and priority gap. I have a ticket open for our dev team that would personally take me about half a day to do. The ticket has been open for over a year. It is impossible to get into their roadmap and they are not about to share the keys to the castle to let some random marketer do it, even one with a development background. I hate zapier, but it works and it is quick. Sure it may have to be rebuilt at some point, but having a 60% solution today is a lot better than no solution with the promise of a 100% solution (that will actually probably also only be a 60% solution) in a year.
leros 3y ago
The best escape hatch I've seen for this kind of organizational issue is UpWork. You get UpWork approved as a vendor, then you can spend your own department's budget hiring whatever random contractor you need. Yeah you might spend $1500 on a two hour dev task, but at least it's getting done immediately instead of blocking your whole project for 6 months.

by cm2012 3y ago

dgellow 3y ago

> No code removes friction from the org. That’s so true. It’s not to build quickly, it’s to keep the agency within the non-engineering department.

WWLink 3y ago
To me that sounds like the argument from a business department in an engineering org. The solution is for your department to hire its own software developer(s). I'd say the same thing for an organization that is heavily business-oriented and has an engineering department that gets kneecapped by the business-team-focused IT department that can't appropriately support the engineering department.
- bell-cot 3y ago
  > The solution is for your department to hire its own software developer(s). Vs. the reality, in most large org's - that plan gets shot down faster than non-union electrical contractors in New York City.
- sfink 3y ago
  And people wonder why organizations have such high headcounts...

drpossum 3y ago

Having been on the "actually has to deal with the aftermath of investing in no-code" that is when the cost comes in. Out of the literally dozen or so places I've worked and the half of those that went heavy on low code, it has never worked. The complexity becomes too great after a few months of "wins" and the system falls over on itself because the people using low code need increasingly complex things. But I assume as a marketer once you've finished your sale you move on to the next one. Because that what they all did.

cm2012 3y ago
The trick is to use the no code implementation to learn what you need to build from scratch. Don't think of it as expensive time to redo - think of it as valuable work finding out what your org actually needed. I'm sure you know that people don't even know what they need when they send developers their brief half the time. It's like excel. Yes excel is used for all sorts of messy things its not ideal for, and would be better built by a programmer. But the excel file teaches the developer what their co workers actually need the product to do. It's not wasted time, it's invaluable.
- mellosouls 3y ago
  That's a good observation but falls apart if actual developers have to maintain the Rube-Goldberg app created by well-meaning "Citizen Developers" (© Acme No-Code Corp) using a framework which is only intended for prototypes but not fit for purpose beyond that. Of course, that's a management issue - but managers who are easily taken in by consultancy sweet talk about the power of these frameworks are not always the most likely to understand the problems they cause or have the wisdom or resources to clean up afterwards by doing what you suggest.
  - The_Colonel 3y ago
    We can't design tools which are incompetent-manager-proof. There are companies with incompetent management having no clue about software development, but business selection should eventually sort them out.

cbm-vic-20 3y ago

There's a reason so many internal corporate applications are built as Excel spreadsheets: there's a lot less friction than having to get a development team involved.

olavgg 3y ago
This is so true. Oil & Gas loves data and excel. Everything starts with Excel, and when it outgrows Excel the next step is getting developers to build a better solution. I absolutely think this is the right thing to do. If ChatGPT can make basic programming eaiser, and Excel ships with easy and excellent Python integration, we will see more Excel.

willsmith72 3y ago

This is why we have product teams. Your experience is the norm, and no matter how much they may think otherwise, 90%+ of software teams are working in waterfall/delivery/feature teams. Product teams are the solution, but very few orgs are willing to completely flip their structures to get there.

josho 3y ago
I agree. But what happens when the project finishes and now any remaining work has lower priority/roi than other projects? Is there any guidance for that?
- willsmith72 3y ago
  product teams are long-lived, unlike projects if someone (say someone from marketing) has a need for the product, and it gets de-prioritised, someone has decided the marketing person's needs are less important. That's why product teams have to be cross-functional and have ownership. You can't just have a board of execs 5 levels of hierarchy removed switching and swapping people randomly. also why there are so few product teams. There aren't many execs willing to put the trust in their people to give them ownership of products/problems/opportunities/outcomes, without wanting a micro level of control on the solutions. Which is always hilarious because they hired these people in the first place (or the ones who hired them etc...)
  - c_o_n_v_e_x 3y ago
    > without wanting a micro level of control on the solutions. HiPPO attacks are real. Nothing like having countless customer interviews only for a dataless HiPPO to come in and maul your product. I feel like PMs are used as sacrificial anodes in some orgs. The HiPPO controls product via the PM. When the product inevitably flops, it’s the PM’s head on a spike.
    - Sylamore 3y ago
      Highest Paid Person?

afarviral 3y ago

This had been my experience as well. You can replace the low-code solution with a junior coder in a non-coding role. Creating a shadow-IT solution will be a fraction of the cost and time. The risks are the lack of governance and amateurishness, though. Solution: have vertically integrated agile teams so that developers are in the problem space with experienced peers and governance. Why don't more orgs do this?

marcosdumay 3y ago
We managed to move almost the entire shadow-development from our organization into a low code platform. It works great. The systems already starts in a usable format, and when they need intervention, they are in a very standard format that is easy to start working with. Besides, today we also send applications back to shadow-development, and they are able to maintain them until something big changes. Shadow-development isn't very shady around here anymore.
- cjalmeida 3y ago
  This here. Fully centralized IT is stifling, shadow/decentralized is chaotic. Good structures come from hybrid, matrix-like approaches.
- code_biologist 3y ago
  What's the platform? Something you'd recommend?
  - marcosdumay 3y ago
    We use Oracle Apex. The platform itself is quite good. But it only runs on Oracle, so I'm not sure I recommend it.
    - thorin 3y ago
      We used Oracle Apex for years with loads of complex business applications. If you already have Oracle licenses it's a must-use. It's definitely lo-code rather than no code as you really need a bit of db modelling, sql, and development skill to get it working well. It can also be hard to work out how to customise things but you can get it to do almost anything CRUDy.

silpol 3y ago

there is reason why John Woods wrote in 1991 Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability. https://stackoverflow.com/a/878436/499698 https://stackoverflow.com/a/878436/499698

HeyLaughingBoy 3y ago

I never really got this until I was talking to a scientist in our organization and she was bemoaning the fact that it was taking her team hours to do some basic analysis of files that our instrument exported. "So why don't you make a request for Software to add that data to the file? We could do it easily enough." "I did! but they keep telling me it's not high enough priority so it gets pushed out to 'the next release' every time" "OK, I'll write you an offline tool to process the data." Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature. And this was taking a biochemist on average 3 hours every day to do by hand!

BeetleB 3y ago
> Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature. The counter to this is that this tool now has no support (which may be fine depending on the tool). I remember my first job which was 30% SW and 70% other engineering. We wrote a few tools to automate stuff that our customers used. One of our customers came to my manager and told us he had a tool we wrote over 5 years prior. It was a small Perl script. Their data source had changed formatting a bit and now the script no longer worked. They wanted us to update the script. Several hours were spent between the two teams arguing. My manager did not want to own it. He said he had no record of it, and none of the people on his team had any memory of it. We did not own it. They kept insisting "One of the engineers in your team (who had since left the company) wrote it, so you own it!" I pointed out to the coworker that the request was so trivial we could have solved it in under an hour, and the company had lost more money by arguing. The counter was "If we fix it, they'll keep coming back to us and in the long run more money would be lost." Over the years, I've realized how right he is. I do occasionally write simple scripts to help our customers, but management always makes it clear to them that this is an unsupported prototype, and the customer needs to maintain it.
- hooverd 3y ago
  I think some teams could do really well to have an embedded developer- someone who can understand both fields decently enough.

ipaddr 3y ago

Then you want to use your data in an internal system and all breaks lose. Usually what happens the structure of your has to change because sales now wants to sale the product in a different way and your no-code tools can't support it. No-code tools are great for solo founders but terrible for enterprise anything

granshaw 3y ago

I’ve long thought of starting an agency where “we’re developers for marketing depts”, ie, we’re seasoned devs, hire us and we’ll jump into the dev side of things and the company’s codebase, make the changes needed that you want, keep us on retainer if you want updates, and that’s that. What do you think of that?

letsdothisagain 3y ago
Yes, it's called consulting and it's great work if you can get a consistent client base. I genuinely wish you the absolute best of luck getting a consistent client base.
asielen 3y ago
Some of those exist, usually billed as implementation partners that also can do whatever dev work you need. The problem is getting marketing leadership to believe they need those services. Usually you have a handful of technical marketers shouting from the rooftops asking for dev support. The CMO goes and talks to the dev team and they are reassured that there is no need to outsource, there is a perfectly good team in house that will get around to it eventually. I've had the best luck bringing in a firm as part of an implementation and then keeping them on for a few months to help with odd jobs in the guise of support. Executive leadership in sales and marketing is typically clueless as to what their teams need too be successful. It isn't in their job description, it isn't what they were hired for.
- granshaw 3y ago
  Very interesting and useful insight, thanks!

MuffinFlavored 3y ago

> Say it's an API hookup and some automation between some tools Why aren't companies better at putting requirements/user stories/whatever into Confluence/Jira tickets? Why do there have to be 10 layers in between, constant followups, repeating yourself? Why do there need to be meetings when you can just keep a ticket updated with all context?

deepsummer 3y ago
Because it's hard, unpleasant, and often 'invisible' work that no one wants to do. Often it's also frustrating, because if you write more than 3 lines, many devs don't read it.

bitwize 3y ago

As a developer, let me tell you how things go: 1) Marketer puts together something in their no-code tool of choice. For a while it does what is needed and becomes a critical part of the marketing workflow. 2) New requirements come in, maybe it needs to integrate with a new API or database. Marketer is too busy marketing to waste time with all that plumbing. Thankfully there's a department full of people whose literal job is dealing with all this crap: the developers! The no-code project is thrown over the wall and some coders are assigned the task of rat-wrestling with the no-code tool, as well as writing code against their crufty, idiosyncratic API -- code that cannot be tested using their usual testing tools because it must all live within the no-code runtime -- to fill in the gaps in the tool's functionality. Their productivity grinds to a near halt. This becomes their job for months to years because the no-code workflow is Mission Critical, Essential to the Business, and if it breaks or cannot be made to do what is needed billions are at stake. 3) That thing you wanted takes 9 months to complete because now the dev team has all the no-code cruft on top of their work building actual software for the business. Please, for the love of God, just do us all a favor and learn some Python. When you throw that over the wall for us to maintain, at least we can version-control it, test it, and integrate it with our CI/CD.

bennyelv 3y ago
Big assumption that! Code written by non-developers, or even by the type of developer who is a tradesman rather than an engineer is usually untestable. The biggest and only advantage is that you can read it and debug it in order to understand it, which you can’t do if it’s embedded in a mess of lines and boxes with logic hidden several clicks down in a low code platform.

droptablemain 3y ago

- Developer time is always the biggest bottleneck at any org I've worked with. Anything that let's you get around it is worth its weight in gold. To each their own I guess, but it's hard to imagine NASA going to the moon being led by a marketer or business analyst. Hard things are hard. And hard things done right take time and precision.

pas 3y ago
there's no need to do them right. and most no-code platform already constrain the solution space brutally anyway, and that's good enough in most of the cases.
nouveaux 3y ago
Nasa's biggest challenge is marketing. Their funding is dependant on public perception. Nasa does not get more money by having better engineering. Nasa gets more money when congress thinks it will get them more votes with their constituents.
- acuozzo 3y ago
  > Nasa does not get more money by having better engineering. But several catastrophic failures in a short timeframe can ensure it gets no money at all!
  - nouveaux 3y ago
    My point isn't that Nasa should prioritize hiring good marketing over good engineering. Nasa has good engineers. My point is that their biggest challenge now is their public perception. The general public does not care about Nasa's mission. SpaceX is far more popular than Nasa. If you stop to think about it, SpaceX is just making travel cheaper and it shouldn't be that interesting. If Nasa can make their mission more fun and interesting, they have a better shot at a larger budget.

austin-cheney 3y ago

No sympathy as this is entirely a self-inflicted wound. The problem is that very few people, at each stage, are qualified to be there. Let’s not kid ourselves with pride and self-congratulatory bullshit about how awesome we are. Most people require several layers of abstractions to do their jobs to cover competencies they should know but don’t both in technology and marketing. The reason this occurs is because there is no baseline of competence in software, so everything becomes wildly subjective and therefore biased. To solve for that business imposes tools to make things easier, but really it’s to commoditize candidate selection. That eliminates some amount of training costs up front but instead requires a larger labor pool with lower product flexibility. More people of lower competence with far less ability to pivot as requirements change and everything takes longer. No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before.

Nostromos 3y ago
It's easy to describe this as self-inflicted when you don't understand how large orgs work and have never had to consider how a security team deals with a large org, each piece wanting their own version (or multiple versions) of this solution. Qualification isn't the issue because we (the US, US tech, SF/NY, etc.) have a lot of qualified talent, both in eng and elsewhere. The issue you describe with competence IS an issue but not for this. Your final sentence is correct but not right. Basically, you're right and you're wrong and I should probably write something longer form but won't get to it for months. I'll give you an upvote in lieu of that for making me think deeper about the topic.
- Nostromos 3y ago
  And after re-reading my first sentence, I apologize for suggesting you don't understand how large orgs work. That wasn't fair and I don't know your background. I'm gonna leave the post unedited for honesty's sake.
lucasyvas 3y ago
> No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before. I don't want to dismiss this point, because it's real. But there is an alternative. I've been brought into these talks with other departments before, and I evaluate the tool from an engineering perspective. If they want to use a true no-code solution, we don't block it but raise to the director level that we will under no circumstances support the use of the tool - we are developers by trade and that's what we're paid for, so they are responsible for everything to do with it and bear all responsibility if it fails to adapt. If it's low code and has an API, we generally much prefer that because it means we can actually deploy and properly maintain the code that might be needed to support integration with it. We don't copy and paste fucking code and we don't drag around UI elements with if-else statements - it's simply not our profession. You wouldn't ask a carpenter to assemble IKEA furniture. It's a waste of money and time. So yes, the solutions might "need" a developer, but no sane director would allocate one. It makes no sense.

simonebrunozzi 3y ago

Also reason why Canva is worth a lot. Similar pain point being solved.

rodgerd 3y ago

> Developer time is always the biggest bottleneck at any org I've worked with. Also: you are an expert in something. Half the time the SME will spend a large chunk of their time being lectured by a developer with no domain knowledge, but a deep conviction that the SME is doing it wrong.

cm2012 3y ago
The worst thing here is when developer leads have strong personal feelings about things. I've seen a company sabotage its own growth for years because a CTO was uncomfortable with Javascript tracking tags. When they finally relented we were able to 2x our growth rate.

phpisthebest 3y ago

>>Anything that let's you get around it is worth its weight in gold. I have a novel idea.... HIRE MORE DEVS!!!!! I know, I am crazy

lghh 3y ago

Or, and hear me out in this, you just walk over to the developer and talk to them? Or go work for an org where that’s possible?

marcus_holmes 3y ago
Then the dev team never gets to write anything because they're always being interrupted. On top of the fact that developers are almost never in charge of prioritising their own work - that's what project and product managers are for.
cm2012 3y ago
That worked extremely well at a past org, I had a partner and we worked really efficiently. Until the project manager put a stop to any shadow dev work.

entontoent 3y ago

Every time this happens at the companies I’ve worked at, it’s been because the business didn’t think the need was worth prioritizing over the other business needs. I’ve never been in an environment where IT got to make the decisions about what gets prioritized. If the business doesn’t think something should be prioritized, but a marketer decides that they really want to have it, I’m not sure it’s a great idea to go around what the business has prioritized. Most of the cost in software comes from maintenance of legacy systems. I hope this new no-code solution is something a department has decided to maintain indefinitely! I my experience, after the marketing person quits, the no-code solution gets chucked across the fence to IT, the no-code provider stops supporting their tool, and IT is forced to build a new one as an emergency a few years later because “the business has been using it for years.” In a healthy org, if something is truly good for the business and will create global gains across the company, it should hop to the top of the priority list. Admittedly, I’m still hunting for this theoretical healthy org, though.

cm2012 3y ago
No time to write a full comment now, but I would compare the fully planned org to failed communist states vs the more chaotic capitalism that does better.
asielen 3y ago
Usually the marketer is stuck between a rock and hard place. A semi-technical marketer will report into a completely non-technical org led by a CMO who thinks pivot tables are black magic. But they same CMO has promised the CEO and the board that they can integrate their product analytics into their pipeline performance reports, and have it by next week. Sure the marketer can say no, but the CMO doesn't understand why it is a no because their buddy CMO's marketing team does it already (not understanding the work that went into making it happen at that company). So the CMO interprets no as a performance issue not a technical or process issue. And this happens all the time. So at some point the marketer is stuck between building a one off report in a spreadsheet or using the tools they have access to (usually something like zapier, or some marketing automation platform) to build a good enough solution that gets presented at the board meeting, and everyone is happy. Play this on repeat with, marketing, sales, hr, finance etc every month. The alternative to low code isn't code, it is excel spreadsheets.

marcus_holmes 3y ago

This is the reason we have desktop computers. Lotus 123 (and then Excel) enabled ordinary folks automate bits of their jobs. But it went through a pattern: - Spreadsheet was created to help do task X - Spreadsheet grew until task X was entirely contained in the spreadsheet - New hires were trained to just use the spreadsheet instead of understanding the task - The person who built the spreadsheet left the department - The business needed a change in the task, and that meant changing the spreadsheet. But no-one in the department knew how the spreadsheet worked any more. - The IT department gets a new urgent task to change the spreadsheet to allow for the change in the task. The spreadsheet is a complete mess of spaghetti, evolved over years with no documentation. It will take months of work to untangle it and make the necessary changes (and document it for next time). The developers pitch that they could build a VB app for the task in less time than solving the spreadsheet and that would improve the situation going forward. - The IT department kicks off a project to build the VB app. Immediately the business department adds a ton of loosely-related requirements because they've always wanted them in the spreadsheet but no-one knew how to add them. - The project founders under its own bloated weight, scope creep moving it from a couple months out to a year's project. - Meanwhile the business department works out another way of doing the task - 18 months later the IT department delivers the app as promised. But it's wildly out of date with what the business department is doing now, so no longer fits the use case it was designed for. I've seen this happen a few times. It'll be the same with Zapier-derived solutions - in two years you'll have left the organisation and then an API changes and the thing you built falls apart, no-one knows how to fix it, and devs don't want to look at it. Everything is more painful this way. It's worth its weight in gold until suddenly it turns to shit.

zubairq 3y ago
Describes a scenario I was in almost perfectly! :)
foxbee 3y ago
This is a great example. Low-code is not the solution to everything, like spreadsheets were not the solution to everything. With low-code, it really does help if the platform is easily extendible and open source. Also, it's important the IT team owns the low-code platform.

devoutsalsa 3y ago

Good for marketing now. Horrible for maintaining developer later. I was recently working on a marketing application and the it was the worst experience of my development career. There's was zero afterthought about what it would take to keep thing running once it had been launched. The only thing worse than the intractable bugs was the unwillingness to invest in its maintenance. I'm not usually fan of a complete rewrite, but in that case I wanted to nuke the site from orbit. It's the only way to be sure.

topkai22 3y ago
I spent years as a consultant following a basic pattern: a subject matter expert wrote a tool or series of tools in something like excel or access. The tool got popular but didn’t scale. My firm would get brought in to “fix that and then automate all the processes.” When I was a junior consultant I’d get angry at how kludgy and inelegant the original solution was. After a few projects I’d realized how hard producing software that business users actually use can be. My response now is “this is amazing, look how far you’ve come. Let me help you go further.” Yeah it stinks and yeah I often did from scratch rewrites, but the work done proving the idea/system was valuable was why I had a job in the first place and had delivered more value then I could as a developer.

xtracto 3y ago

You are so right. I've been CTO of several startups of different sizes , and the frustration of non-product teams to get ANY automation love was terrible on each of them. And the funny thing is that usually, very simple things would mean a lot to said teams. I saw it for marketing, compliance, legal, finance and even RH. But the blame is not the tech team but business/ceo office: they set the priorities . Otoh the comments here make me chuckle. How does the saying go? You can't make someone understand something if his life depends on not understanding it (or something like that in English o think)

brutus1213 3y ago

Not in this space .. is Zapier the same as IFTTT?

cdaven 3y ago
Yes, I think Zapier is a B2B version of IFTTT.

asielen 3y ago

As another marketer, this is 100% spot on. And it isn't a technical gap, but a process and priority gap. I have a ticket open for our dev team that would personally take me about half a day to do. The ticket has been open for over a year. It is impossible to get into their roadmap and they are not about to share the keys to the castle to let some random marketer do it, even one with a development background. I hate zapier, but it works and it is quick. Sure it may have to be rebuilt at some point, but having a 60% solution today is a lot better than no solution with the promise of a 100% solution (that will actually probably also only be a 60% solution) in a year.

leros 3y ago

The best escape hatch I've seen for this kind of organizational issue is UpWork. You get UpWork approved as a vendor, then you can spend your own department's budget hiring whatever random contractor you need. Yeah you might spend $1500 on a two hour dev task, but at least it's getting done immediately instead of blocking your whole project for 6 months.