Best Answer

Opinion - resolving technical debt and moving a system forward

  • 10 April 2022
  • 8 replies
  • 77 views
dklinger
Rank
Userlevel 7
Badge +6

For those that have not really considered the impact of technical debt? Know that software being developed and the teams that work on it can spend a significant time on resolving issues versus adding new features. Consider this graphic…

And so we have seen a shift in a few strategies by Docebo to wrangle their debt and make strides in the right direction. We have seen that with:

  • A shift to a monthly major release schedule
  • Dedicating development to the new ideas buckets
  • Strides of transparency in the roadmaps with CSMs

I appreciate all of this. Earlier in my career I worked for a custom software development group for a health system…so uniquely? I am poised to get it.

But when something feels broken. And we work “the machine” to document and get a reproducible bug recognized and addressed? Do we have any recourse and a way to escalate a concern to the right team?

A proposal - can we (the community) get some insight passed along into the deployment of unplanned changes and how we can escalate a situation so we can get it successfully addressed? I have worked that machine a little…but some may be frustrated and allowing them to hear how to address an issue I believe would be beneficial to the community.

 

icon

Best answer by Bfarkas 11 April 2022, 15:16

View original

8 replies

dklinger
Rank
Userlevel 7
Badge +6

I wrote the above because like any debt? It comes with a cost. For example, the cost of reorganizing to improve efficiency pays itself off in the long run. But for your consideration? There is a cost being applied to your clientele as well.

An opinion - as a client? We shouldn’t find ourselves in a position that we need to navigate escalations (and metaphorically? “work through the technology debt”) to get things done. It is important to find the sweet spot as you all continue to narrow the debt and become more agile with your product delivery.

Keep us in mind…your product is great..,keep hearing from your clients when we struggle with an issue.

gstager
Rank
Userlevel 7
Badge +5

I’m still stuck on the part about many organizations paying for 100 developers…

I would gladly welcome a second one any time now… 😀

Greg
dklinger
Rank
Userlevel 7
Badge +6

I’m still stuck on the part about many organizations paying for 100 developers…

I would gladly welcome a second one any time now… 😀

I didnt want to change the graphic - I wanted to keep it authentic. 👍🏽

Bfarkas
Rank
Userlevel 7
Badge +3

When I saw this title I was excited for the convo. I agree with many of your points but I think sometimes there’s a tough call between community/community building/community input and support and some of what you are mentioning I think squarely belongs in the support infrastructure. Pieces of it I think are trying to be bridged between the two places with the increase in known issues postings in the community area once something unexpected is identified, but still a tough call to figure out the right mix for sure. 
 

Tagging onto this idea though, there is another level of tech debt in the setups/choices/customizations we each make to our instances. Managing that level is important too especially when it is balancing options which docebo changes can impact and something to always keep in mind. 

dklinger
Rank
Userlevel 7
Badge +6

@Bfarkas- I want to give you the best answer? But I also want others to chime in...I think the way that a software group chooses their strategic approach? Groups can setup business related OKRs and KPIs….alphabet soup for how they are approaching the problem of attempting to mitigate technical debt - I dont want the customer to be on the losing side of the equation.

And you do make an awesome point - once we begin to configure? We make business decisions. Those decisions lead to outcomes. Those outcomes drive our feature requests when we find that folks want improvements that are beyond the scope of the system. If you think of your engagement as more of a marathon and not “finished because we deployed to the broadest audience”? I think an implementation can grow with the needs as well as “influence” the product with the right ear.

dklinger
Rank
Userlevel 7
Badge +6

…...Tagging onto this idea though, there is another level of tech debt in the setups/choices/customizations we each make to our instances. Managing that level is important too especially when it is balancing options which docebo changes can impact and something to always keep in mind. 

I wanted to cross link the other conversation to this one. @Bfarkas and I ran with it a little a week or so ago on what can be great tips to keeping your technical debt rather low.

For those sci-fi fans - forgive the metaphor - I think of a brand new LMS instance as one where space/time continuum is not disturbed - and everything works perfectly - in theory? It is a ready to do business for you. Once we begin to input our business onto it in the form of users, user experience, learning objects and learning records? We slowly distort and mess with the space/time continuum….and need to keep adjusting the implementation towards the needs of the organization. If we follow solid practices? We arent too disruptive - we keep going...the right LMS will keep your technical debt to a reasonable level - if we get too batty? Well? We run our technical debt high…and this is probably because the implementation is stretching itself into business domains it is not great at. So we take on the debt because of the cost of not having a better solution implemented.

 

TaviaRitter
Rank
Userlevel 4
Badge

 

Tagging onto this idea though, there is another level of tech debt in the setups/choices/customizations we each make to our instances. Managing that level is important too especially when it is balancing options which docebo changes can impact and something to always keep in mind. 

I wanted to tag onto this because this is where the set up process and on boarding become so critical tp set up a foundation of success. Ensuing that, fro the begining, the client understands all of the implications of their choices within the platform for their use case. I would even say that it is important to have a technical representative correcting the sales people who over promise and under deliver (oh, there’s reporting for that!  * grins like the Cheshire cat *…. sure, if you feel like digging through an excel spreadsheet and have an advanced excel users on staff?!?) 

I love that Docebo U, the knowledge base and Docebo Community are available - so we can self-serve the information.

However, the onboarding specialists need to listen more than they talk, understand that linking out to a KB article isn’t the answer to all the questions that don’t have an immediate answer, and teach more than they ask their users to read. 

Then, the Customer experience team needs to understand all aspects of this feature rich platform (and with features come bugs/tech debt) and at the very least be internally involved enough with their co-workers to understand who the SME are with each part of this massive platform - so when their client asks a question, there is someone to go to (in addition to sending the proper KB article).

Just my two cents from my experience thus far: As someone who was involved in the RFP process to select our LMS, completed the Docebo University Onboarding learning plan, worked thru a ton of courses in Docebo U, and was sent a KB article every time I had a question during my onboarding process (sometimes instead of getting answer, or a ‘here’s why I am sending you this article’ it was just a link...) ;)  



 

Tavia Ritter
dklinger
Rank
Userlevel 7
Badge +6

@TaviaRitter - thank you. I do think it remains to the implementation team’s advantage to have people at the table to make a version one of the implementation fit the organization well. I want to assert that technical debt for an implementation remains unavoidable. What the implementation team can do to minimize that for the organization will typically make it or break it. I would love to gather a statistic surrounding projected usage vs actuals by companies. I have gone to many of a user group / conference to hear about an implementation getting stuck and/or not going beyond a technical go live. Is it that the debt ran so high that the organization couldn’t adopt? Was it the L&D group that could not foster and push adoption successfully? Was the purchase not a good fit and it just stalled?

To yours and Brian’s point - I definitely think technical debt fits into a part of the story. A note - I hope that folks also realize that if they feel like they are so new to the learning management game and that the implementation is going awry because they feel like they are not seeing the engagement they hoped for from Docebos implementation group (which IMHO was really decent)?  That there are a wealth of partners out there that (at a cost) that can recognize the health of the project and offer ways to correct for it. I am a fan of ESKillz for years because they have not only been a third party implementation team…but they have taken on huge implementations with high levels of success and they thoroughly know the product…bring together the expertise and the know how with the right tools to get into what the use cases are is what sets up implementations for success…in the face of technical debt that can remain minimized…

Reply


Terms & ConditionsCookie settings