What's in a Name, Part I-Lost-Count

The Tridion Sites Public Content API has been on my mind lately. I've blogged about product names before, but this one may be a bit ranty. Hopefully I can help remind people about the difference between a product feature and how its implemented. And luckily there hasn't been a big name change lately.

Let's start with a question. What is the name of the Tridion Sites public content delivery API?

The cost of translation

Translation memory reduce the cost of translation, especially for previously-translated content.

Things you/I didn't know about RWS

It's been over a decade since I joined SDL, now RWS, and after all this time I'm still learning and helping others learn about our technology and services.

Orchestrating an online event: when my performance hobbies catches up with a conference for work

Convergence!

That was the feeling I had when preparing and delivering my lightning talk for the Tridion Expert Summit 2021 for the Americas earlier this year.

Mainly, in preparation for the TXS event, we practiced in our streaming backend system, which is distinct from the digital asset management used to deliver pre-recorded videos, which is also distinct from the event front-end.

It took a moment for some of us presenters to clarify the difference between the off-stage and on-stage (or backend and frontend) elements of the setup.

What's the context? A story about pairs.

We've finally found and purchased our "forever home" back in San Diego. We're now in Alpine, though we've considered places such as Fallbrook or Temecula. Some of the places prompt people to say, "that's far!"

We joke, "far... from where?"

Distance is a measurement of at least two locations. There's always an origin and destination, otherwise, you can't tell if something is near or far.

You don’t have to answer questions...

“You don’t have to blog (articles). You could share... code.” Those are the words that encouraged a colleague and friend to start yet another Tridion blog. He literally called it “Yet Another Tridion Blog” and has shared mostly, well... code.

After blogging hundreds of posts about Tridion, content management, and business analysis (over 300 last I counted), I’ve developed the rewarding habit of encouraging other people to share with their respective communities. This is typically about Tridion (Sites or Docs), but I’ve seen and (hopefully) helped others jump into other online communities.

New Year. New Role.

After a crazy 2020 and my family's move back from the Netherlands to the US, I'm ready to start a new role as a business architect within SDL Professional Services in our NASA division (that's North America / South America and not, well, NASA) .

Crossroads are overrated

SDL Tridion Sites 9.5 is released! Read the announcement on SDL Community.

Having moved back from the Netherlands to the US, this will be a long post as I reminisce my earliest moments with Tridion Sites, thank my team in a GDPR-friendly way, and ask you one more time to keep working with the product and development team to continue improving my favorite product.

Memory lane

I still remember asking our implementer (the same guy who coined the term, “The Fifth Tridion Environment,” what was the difference between embedded fields and a link. A few weeks ago we shared drinks one more time in a COVID-19 socially distanced outdoor venue, not far from the SDL Amsterdam office, which is still awaiting to open following company and government guidelines.

Back around 2008 or 2009, I recall how I fell in love with content modeling when a developer asked, “wait, how will the editor enter the markup needed for the page?” That’s the beauty of it. They don’t.

I remember explaining where to put Web Page metadata into the CMS and reminding my former colleague from the Bronx with the great demeanor and cool accent to check-in that Schema and be sure to associate any Templates needed to it.

And I was right when I said that commit error message meant there was a duplicate binary. Yeah, I knew "my" system.

The Classic UI is polished and nuanced

Yet, I’ve been humbled several times over when I realized how much I assumed I knew to only to (re)discover icons for BluePrinting actions in Tridion Sites. Favorites in the item selector showed organizational items rather than everything, at least until the new UI. An item in use in older items doesn’t actually prevent deletion most of the time, with an exception for when you attempt to delete Schemas). If you try very carefully, you can intentionally break a reference. That's a trade secret. I won’t say how.

Oh and apparently you can choose to create a Multimedia Component even a folder has a default regular Schema set. And in the Schema drop-down you'll get both the regular Schema set, pulse the available Multimedia schemas.

Up to right before the release, I’m hearing a refreshingly different kind of response after a few years of making new UI-related features, but not much changes to the basic experience of creating and editing content. Rather than suggesting all the improvements we've now added into the product, people are noticing what’s not there (yet).

I’m confident to say paradoxically yes, this release is going to be refreshingly welcome and different while many will want more.

My main job

My job as product owner wasn't to put a decade of my experience with the product into the product. That was a happy coincidence and motivation to improve the product.

My job has been to bring some of our best, experienced, newest, brightest, and occasionally stubborn (in the right way) people you’d ever love to work with to prototype, research, build, test, and validate improvements to the product and specifically the editorial experience.

Yes, we needed a new editorial experience and the technology to support it. Our ahead-of-its time custom HTML and JavaScript framework was still amazingly flexible, but required, well HTML, JavaScript, and vendor-specific skills when frontend expertise has moved into frameworks such as React, Vue, and Angular.

Everything you would assume is easy was likely harder than you could imagine. We never (rarely) debated on button color. But we could spend some time considering placement, language, and order; you do not want to hear about the dozen iterations of what “back” means, where it should go, and what icon to use.

I won't detail the lengthy discussion about the word, "screen." While I recognize the nuance, I stand by my choice to drop the word from "View in explorer." :-)

The team

But these are minor inconveniences compared to how the team brought their best talents to the mission. I have one dev who really considers what editors needed keeping in mind what issues have come up before. He’ll mock up working prototypes with a bit of HTML and JavaScript and kept our (my) ambitions in check, reminding us to focus on the mission at hand.

I have another who both loves tools and abstraction, yet is willing to do the dirty work, unit tests, and gnarly bugs I have a hard time understanding let alone explaining. I bet no one (except perhaps this guy) could explain how Favorites in the item selector should actually work. With BluePrinting. But my dev likes those kinds of challenges. Coincidentally he also likes pushups. 

I have a QA engineer who joined and immediately found bugs in third-party components that have since been fixed. You're welcome, un-named third-party component. Oh and he programs video games for fun.

I have a QA lead who has a keen sense of how stable something is at a given moment, aware of when requirements need to be adjusted, and who, when finished building one of my LEGO “morale” projects, asked why there were "leftover" pieces. Note: it's a standard LEGO practice to leave a few extra pieces in a set, but it's a nice reflection on the care in the statement, "but Alvin, there are extra pieces in the bag. Is this to be expected?"

I had a designer start with an early initial assignment to design a "better date picker," who has since grown to design the new page and multimedia experiences. Alongside him, we brought on other UXers more familiar with other SDL products to then bring the SDL Graphene design system to Tridion Sites and then interactions in Sites back to products like Docs.

And I have a researcher who reinvigorated our customer and UX research program which now includes “days in the life of” sessions, usability tests, customer workgroups, customer journey workshops, and our latest, an early access program supported by management, the System Team, and Community.

Joiners, leavers, and rejoiners

Over the two-year project, we had people leave, go, and at least one to return. The hidden catch with modernizing an element of your system is the popularity with the given technology. 

We had one dev who would respond to work with either a "yeah, sure," or "you sure?" He would fearlessly build something on requirements as simple as, “you know, like when you add an attachment.” 

"Done."

Oh wait, that’s supposed to have some filtering.

"Okay. Parameterized."

We had another team member kick off the project and get us to a good spot, even making a debut as a technical conference speaker. Though he's working on other things, he'll still take the time to answer a question on Tridion Stack Exchange.

And along the way, we had some jump in on shorter contracts and others that have returned. Each saw the mission, did what was needed, and we’re now close to the finish line.

Through most of the project, we had an amazing guide, guru, and friend who not only built a good amount of the experience and supported multiple teams in multiple UI projects, he would even create break down interaction designs when needed to answer a question, challenged us to be better than we thought we could, and still gathered people together after hours for drinks to relax and welcome joiners or thank leavers.

Oh and thanks very much for arranging the photography session parting gift. Here is one of the wonderful photos of our family.

Thanks to Florencia Jadia for the wonderful photos!

One last project

I first had a chance to work with product management and development a few years back but in professional services as one of the stakeholders. That was until KnewKnow got me to Amsterdam as a Technical Product Manager. I eventually moved into a proper Product Owner to focus on integrations and then the new UI for Tridion Sites.

So my family's "2-3 year" stay in the Netherlands became, “at least until we ship the new UI.”

The company's mission was a new editorial experience. My personal mission was to make sure this team was more than prepared to do this without me. 

Though the project officially kicked off early in 2018, before that we recognized a challenge with getting the recently-introduced notification API to work nicely with the publishing queue. I actually had to fail a story that automatically updated the Publishing queue because it didn't react fast enough to changes. Though Anguilla was built a decade ago for extensibility and a proper separation of concerns, it was originally created back when polling was perhaps a more standard practice. This was a bit before "one-way data binding" and more modern approaches my devs tell me about.

In 2018, we started with a small team to quickly set up a prototyped back-end, compliments of one of the architects at the time, to quickly enable us to set up a new front end. We needed to confirm we could get an end-to-end setup with a REST API and React front end. We didn't know how fast and far we would get but knew we had to focus on the editor's experience, which is something that isn't as visible in our online community compared to technical topics.

For example, in the rich text editing survey from a while back, editors specifically favored features like full-screen editing and clean paste from Word, which didn't show up as strongly in survey results from technical users.

Assuming it was smaller than the entire content manager explorer, we started with just Experience Manager. This was the in-context editing UI that many customers have seen but didn't always have the right setup or time to take advantage of. But with the setup more out-of-the-box in more recent projects, customers were finally starting to use it and request improvements in usability or performance.

But as soon as we (especially architect Likhan) saw that we already had an item selector, a list view of items, and the ability to edit content, we had a choice. We could stick with the plan, release yet another UI update to SDL Tridion Sites alongside the existing UIs. Or we... could pivot and focus on the main editorial experience, the CME. So mid-project we chose to instead focus on the Content Manager Explorer.

The pivot

And unlike previous approaches, we now had a perhaps not-so-secret weapon. Me! I'm kidding, but I do bring a bit more transparency and eagerness to share what we've been working on with customers and partners who would listen and provide feedback. Based on your feedback and a clear prompt from leadership to focus on the editor's main experience, we pushed out the date a bit further and started bringing on more teams who then turned that initial backend API to a production-ready system, added Content Manager caching to benefit all UIs, changed the time stamps to user time for proper cloud deployments, and finish the remaining editorial UI work in parallel across 2-3 teams.

To be perfectly honest, this is incredibly challenging yet rewarding work. My role, however, isn't to do the work but to prepare my team's work, represent our personas, and align with everyone else's work.

If you appreciate things like the new page and multimedia editing experience, recognize that was definitely us, but not "my" team. Like I hinted at before in a previous post, the surprisingly best part of the project wasn't when I got to create requirements for some interaction, it was in supporting and cheering on others to make those changes while also doing the research, taking in customer feedback, and incorporating feedback.

I can't take credit for the actual work in researching, designing, building, and testing this new experience, but I am proud and glad to have played my part as a good steward in bringing people together, representing our personas, and sharing the progress along the way.

Feedback welcome!

And when you see what we built and have an opinion, suggestion, or question, please bring the feedback. Let us know. I rebooted Tridion Sites Ideas and worked with our awesome Community team to reboot all of SDL Ideas for a reason. Aside from the fact that I was volunteered (voluntold), it was also to move the thousands of emails, messages, and tickets from wishlists and spreadsheets to a transparent list of requests and feedback from the vendor. There's no way we could ever get to all of them. But now we have a regular process and transparency on which of the community ideas align with the rest of the community and product management.

If I were to do it all over again, I might have even prioritized even more for an even sooner and smaller release. I could say "no" a bit more often than I do. But then we'd just have a new new Experience Manager rather than a new content explorer!

Ultimately, whoever cares the most or touches something first gets to decide. So if you really want to shape a community, product, or experience, feel free to MidasRule your way to offer ideas or even apply to the company.

This is one of my last posts in the current, soon-to-be-former role of product owner. I have a chance to work a bit longer with SDL now that I'm in the US so this wasn't a cross road so much as a literal flight across the Atlantic and homecoming of sorts. ;-)

It's yet another step towards the product becoming what it ultimately must become. And yet another step for me to bring together a touch of art, some content, some hopefully on-target humor, and lots of sharing into the next adventure.

Do thank my colleagues on a job well done and sure, offer them some good feedback. :-) I'm thankful and impressed to have had a chance to be yet another good steward to Tridion Sites in the dream job abroad at the "mothership!"

Edit: Mentioned our Amsterdam photographer, Florencia Jadia. Do reach out to her if you're looking for your own photo shoot in the Netherlands.

About April Fool's

I'm intentionally not following what everyone else might be doing for April Fool's day, though I suspect many are focusing on a bit of levity amid the current global situation. If you're finding this post out of context, look up "news in 2020."

I will instead write a few thoughts on what has helped me sell a plausible practical joke while keeping it in good fun.

First of all, make the topic relevant and something that others might expect you to do. My past April Fool's post included:

• SDL Tridion Lisp Mediator (Templating)
• Managing a blog with Tridion, directly connecting to the Content Manager Core Service
• X-box Kinect to manage content

I think these were mildly successful (one colleague flattered me by saying he thought the Lisp mediator was real!) because I've previously shared examples, good practices, and "fun" posts. These also followed a few trends popular at the time such as custom templating frameworks, "headless" CMS before the term became popular, and augmented reality interfaces.

After looking at plausibility for both the topic itself and whether you might post about it, I then try to avoid humor at the expense of individuals. I have been able to What seems to work well if you can joke along with a community you're a part of, in a way that either celebrates admirable aspects of your colleagues or is so silly no one should take offense.

See some of my posts that I've labeled under "humor." You can determine if they're actually funny, but most should be good-natured posts, appreciating community member contributions.

Apologies for the times I may have crossed the line. I believe I've fixed any particular issues, but feel free to let me know and I'll gladly fix, remove, or otherwise update any of those posts. One lesson I've learned is you don't know how things will be received until you actually start publishing. Community norms and expectations grow and evolve over time. It's good to follow, but it can take some practice to find your way in a given environment or community. 

Finally, and the main reason to avoid an April Fool's joke today, is I try to avoid topics that if taken seriously, could be misinterpreted or disappoint people. This is where it's good to avoid crying wolf on topics about negative or even positive results, expected deadlines, or unrealistic promises.

Being in a product role, I'm careful to avoid jokes about features, deadlines, or user feedback unless the context is quite clear. And even then, it's good to separate perhaps a valid observation (e.g. "customers keep asking for features that we have!") from the just-as-valid requests (e.g. they're asking because the existing features aren't clear).

In summary, I think I've done okay joking in a somewhat professional context by trying to be respectful while using plausible, yet sensitive topics. Stay safe, thanks for reading, and use humor as needed. We probably need a bit of fun for a while longer.

Yet Another Post Pondering Business Analyst vs. Product Managers

You may have heard there are many paths to product ownership or product management. I'd like to help encourage people interested in product roles by sharing some of my own observations in my own journey into product management. This post ponders titles and roles, the overlap between responsibilities across various jobs, a nod to Maslow's Hierarchy of Needs, and a reminder that evolution is not a ladder.

I'm most familiar with the version of the business analyst (BA) that bridges the "gap" between the business and development teams. In internal and external roles as a business analyst, I would be responsible for discovering and documenting anything from business problems to detailed user stories and the eventual requirements for the technical solution.

Research

My own journey started as a Web development intern with a side responsibility for research. That evolved into an "internet research associate" position focused on all kinds of research.

As an example prompt, I would research and evaluate competitors and internally share a summary of their products and services. I've investigated health-related technologies such as heart rate monitors or fitness trackers at a time before they became mainstream. Web accessibility and other compliance topics would come up. The prompt that shifted my career path was a search for "a CMS that didn't take over your websites."

That led to questions to various vendors, demos, and the eventual selection of SDL Tridion (Sites) to manage around a dozen websites covering both public websites and a partner extranet. To help understand and implement the solution, I was offered and accepted a “Web Business Analyst” role.

At the time, I assumed the next step for a BA would be something like Project Manager or some kind of "leader of teams." In some ways, I would eventually be right, but not in the ways I imagined.

A Proliferation of Titles and Roles

First of all, my company had different departments, some of which had their own BA roles, independent of my group. So the expectations, meetings, and career paths for people with similar titles in the same company don't necessarily align.

I've seen these differences come from product, department, or location. I've also learned to not worry about such inconsistencies. As an employee in a large enough organization, you might ask and encourage the company to align, but roles and people change. Focus on the problems you're solving, help and encourage those with similar problems, and go from there.

In a broader sense, I have also seen an overlap between user experience (UX) activities and those that have traditionally fallen under business analysis. Similarly, there is an overlap between Product Manager and Product Owner roles and responsibilities. For a good comparison, see Melissa Perri's distinction that "Product Owner is a role you play on a Scrum team. Product Manager is the job.".

If I were to suggest some hypothetical expectations of a few information technology roles, it might look something like this.

This is just an example to suggest product-related roles may work more across the business and deal with customers more than user experience and business analyst roles. The actual mix of skills and expectations will vary by company, title, and your own contribution to a given role.

This post by Brian de Haff on this blog post for Aha! suggests similar differences in that product managers are a bit more outward-facing than business analysts, whereas BAs focus more on technical specifications rather than business requirements.

In practice, across the projects I've run, these aren't rules but rather guidelines. As a software consultant in a BA role, I've had to work with stakeholders and work with customers. Conversely, now as a product owner, I will still address technical specifications when needed.

Hierarchy of Roles and Team Members: Basics First

I see titles and roles split based on how the industry has evolved as well as the size of organizations.

For small organizations or start-ups, you might start with a few “do-it-all” engineers. Go back a decade or so and all web-related activities fell under "webmaster."

When an organization is big enough for more of a cross-functional team, you might start adding roles to get to the following roles within a team.

• Product Manager or Product Owner
• Designer
• Engineer
• Quality Assurance

As an organization scales up, they will add more teams, possibly mixing in more roles for cross-functional and multidisciplinary teams. This might progress, in an order such as:

1. Just engineers
2. Engineers plus quality assurance, QA
3. Engineers, QA, plus a part-to-full-time Scrum Maser
4. Etc.

We can visualize this kind of hierarchy of team needs with something like this, where it makes sense to fill out roles in the bottom before adding more on top.

The point here isn't to suggest a hierarchy of importance, but rather that it doesn't make sense to add testers if there is no code. Nor do you need more processes and connections to the business if there isn't much of a team. 

To grow this out, we might have more granular roles such as the following, though not necessarily all within the same team:

• Product Manager
• Product Owner
• Scrum Master
• User Experience (UX) Researcher
• User Experience (UX) Designer
• Front-end Engineer
• Back-end Engineer
• Quality Assurance (QA) focused on functional testing
• Quality Assurance focused on automated testing

A more internally-focused team might have a BA instead of a designer. And a large-enough organization might have both. Many teams I’ve worked with have people with a range of skills as “hybrid” team members with a particular specialty, but a broad understanding of technology as individuals with “T-shaped” skills.

When in doubt, I've learned to always start with good, solid engineers. A mix of backgrounds and experience is good and I prefer enthusiasm and attitude over experience. If you don't have enough engineers, the QA manager might not let you have more QA engineers. :-) Without proper testing, then the pressure for comprehensive, prescriptive requirements upfront increases while it gets harder to identify edge cases and issues during design and build phases.

I've seen QA also work well as a path to product roles. By understanding how something works and asking "why" enough times, the curious and inquisitive will eventually end up at the customer.

Finally, as the industry recognizes that good UX design can and should also be applied to internal systems, I expect the blur between UX and BA would increase.

Experience

Let me be clear that similar to evolutionary theory, stages in career development is not a ladder. Over a decade ago I had the misguided notion that certain roles were the next natural step after other, more junior roles.

In this post by Laura Brandenburg, she concludes that the BA role could be an interim step to Product Management (PM), to which I agree. Similarly, Kevin Brennan suggests product management might be a good fit for a BA interested in executing their own vision.

However, it's not the only path for a BA, who might continue in an analysis role, work as an external resource as a consultant, or perhaps move into a management role. Personally, I went into cross-functional Project Management and then Project Management within IT operations before I realized I enjoyed working with customers slightly more than vendors. Ultimately, your own path will depend on your interests, aptitude, and opportunities while you might adjust the dimensions mentioned above to focus more or less on working with stakeholders, requirements, specifications, or customers.

You might also opt between a more individual contributor versus a more managerial or leadership role. There are developers, leads, and subject matter experts who have years of experience in their respective roles as invaluable team members. You might opt to fight Peter's Principle and find the role or work you love, without worrying about the specific title. Though when in doubt and to keep things interesting, find a way to grow years of experience rather than the same year, several times.

Headless Does Not Mean Page-less

I've heard confusion over pages, (modular) content, and "dynamic" content for as long as I've worked with content management.

To revisit the topic, I want to be clear that "headless" does not mean page-less. There is a legitimate and quite familiar use case for "dynamic content" without pages, but we shouldn't ignore some critical points about content management, human perception, and the nature of the internet or specifically the World Wide Web.

Stuff I've Learned About Product Management

Nearing four years into product roles for "enterprise product management," I've learned a few practical lessons that the product, UX, or leadership books, websites, and podcasts seem to gloss over or assume.

Specifically, remembering your audience creates a strong pressure on your communication skills. Roadmaps expire and you'll recreate them over and over again. And you have to be willing to break the "rules."

Forget Like and Subscribe, Could I get a Recommendation, Please?

Hi my extended family, friends, and colleagues.

If you're one of the dozen or so fans of my blog or had the chance to work with me, you might know that I've had the fortune of accomplishing more than I ever dreamed of when I started this blog. #humblebrag

This is a personal post reflecting on how I ended up with the dream job and an ask for your help in shaping my next Big Thing.

Tree Behavior: Context Switching, Open in the Context Menu, and "Standards"

Sometimes a change makes sense, until you remember the details and revisit the use cases.

You Should Blog (Again)

I recently gave the same message to share, but for a different community, at the Amsterdam UX Bar Camp.

I volunteered to join the other 23 presenters at UXCampAMS! I'm that first paper in the 12:00-12:45 sessions. #MidasRule

It's Already There...

In recent user research and product feedback I've noticed long-time users of our software suggesting improvements that were already there.

I suspect it's the combination of perhaps three things.

• The way we asked
• The user expectations from knowing the software
• Not wanting to ruin things for others

Ask and You Shall Receive a Response

We've asked, "what would you expect on this screen?" or "would you need this kind of information?"

I'm trying to avoid leading the interviewee, but this kind of question to solicit a response based on the desire to answer. Perhaps the person asked isn't sure or might have a few ideas, but the question itself encourages perhaps a single answer.

Maybe I can leave things more open ended questions and work with our UX researchers on how I can ask better questions.

Midas Rule

As a new customer, I remember asking my first Tridion trainer the difference between an Embedded Schema and a regular Schema ten years ago.

As a new implementer, I remember creating my first Schema(s) and the reaction of my editorial team when they finally had control over their content library a few months later. No more requests to IT to deploy something to Staging to then re-approve on Live!

They eventually explained to me that, "No, we don't publish to Staging. We just publish to Live and fix anything if there's a problem."

As a new consultant, I remember my colleague asking me how I knew all the "best practices." I had four years of experience with the product by then and a few years "managing" content before that.

As a new Product Manager, I remember telling another colleague four years after that, "well, Tridion doesn't work that way." He reminded me that we could change it.

After a decade in the industry and about 13 years in IT, I'm also realizing I'm not so "new" anymore. :-)

Now as a Product Owner for the DX Suite, I'm remembering last week's demo where dozens of UI improvements were implemented in a sprint for the new Graphene User interface (due after Sites 9.1) as well as a "yass!" reaction from an editor to some small, but significant page editing improvements for Tridion Sites 9.

And today I'm letting the Tridion Docs content model slowly sink into my brain after a great session with our lead technical writer.

By the Midas Rule, many of my colleagues and I were not the first to touch this software, nor will we be the last. But we do care enough to be proper stewards of the previous vision, while we work on forging a new one... in Graphene. ;-)

Passing on the Donut

It's already (only) been 2 years since the move to the Netherlands and I'm saying goodbye as the Donut Product Owner and Hello as a POBA.

After joining SDL Professional Services in 2011, moving from my hometown of San Diego to San Jose and meeting many great Tridionauts from across the pond, my original dream was to learn even more about our other products and our customers at the "Tridion Mothership" for at least 2-3 years. Before that, I wondered if I could do Tridion at least part-time.

However, we already had a great Functional Consultant in Amsterdam while at the same time Product Development had an opening for either a Business Analyst or Product Manager with a chance for to focus on the User Interface.

So I thought of course! Coincidentally, one of the interview questions when I first applied to SDL was what might I be interested in doing beyond consulting. My answer was something like:

"Training or maybe development (well not as a developer, but rather, perhaps, maybe... as part of the development team?)."

Getting the job was like being that Excel geek that gets a job with Microsoft.

That first year was about understanding Dutch home/work culture, learning even more about customers, and even changing work culture through new roles and processes while continuing to share, but from within development.

FT1ntegrations

I also had a chance to work with (in) the Translation Manager team for a bit before kicking off the Second Year with even more product add-ons.

Though we started with the safe and boring Team 1/Team 2 format, by #MidasRule, I dubbed our team, "FT1ntegrations" and also brought Legos to the office, to umm... emphasize the metaphor that we connect modular pieces of software. Yeah.

Proper tea has been replaced by a coffee cup to properly anonymize individuals. No, my colleagues aren't actually Minifigs.

Three Little Pigs

There is a story about agile practices and 3 little pigs. This is not that story.

There were three little pigs who wanted to live somewhere near wolves for some inexplicable reason. Astro Naught the Pig planned to make a design that had a plan for a two-story brick house. A. Gile planned to make a wooden single-story house and would iterate, not increment, on the design to make a great home. Scrappy wanted to face the wolf but only had a straw budget.

Day 1

Astro Naught had designed the ultimate house-designing plan designer and had his first prototyped brick when the Wolf appeared.

The wolf bellowed, "I'm going to..." but Astro threw the brick at the wolf's head and ran to his neighbor. The Wolf scampered away.

Day 2

Astro and A. Gile were having dinner in a single-story wood-framed house when the Wolf appeared at the front door.

The wolf knocked and demanded, "Let me in, let me in, little piggies!" But then he noticed the walls were not quite complete and he was able to slip into the house between some unfinished planks.

The two pigs squealed and ran away into the night in different directions, leaving the Wolf alone, disappointed, and hungry.

Day 3

Hungry and tired from chasing the first two pigs, the Wolf spied the small straw hut of Scrappy Pig.

"Now's my chance!" he thought as he started running to the small house.

As he huffed and puffed from the sprint, he entered the already-open front entrance. It wasn't quite a door, because... straw. Suddenly the straw floor gave out from under him and he fell into a fairly deep trap hole made by Scrappy Pig.

Scrappy Pig continued to solve harder and harder problems until he was renowned and praised for business books like The Way of the Straw and The Night the Wolf Fell.

The Morale of the Story

Iterative designs are good. But not when there is a Wolf at the door. A perfect, expensive architecture is great, but not when you don't have time.

The pig that wins is the one that creatively makes do with what it has, focusing on the biggest problem first. It also helps to be lucky enough that the Wolf didn't appear on the very first day.*

*Successful people work hard. But not all hard work is rewarded by success.

Care to read more? Try sausage.

---

Thanks to the kids and BSMSO for helping inspire and revise the story of Astro Naught, A. Gile, and Scrappy. Credit to Joel Spolsky for "Architecture Astronauts." I'm not sure if he coined the phrase, but I first learned about it from his blog. I muddle his point on abstractions of abstractions, but couldn't resist the pun.

Getting Started with SDL Tridion Sites Community in 2018

If you’re new or haven’t seen them in a while, here are some great places to (re)start with the SDL Tridion Sites Community:

1. The SDL Tridion Sites group on SDL Community, especially the Developers group if you’re technical (start with Jan Horsman's Community Review posts).
2. The SDL AppStore for extensions and the community-created Alchemy Web Store.
3. Tridion Stack Exchange for Q&A from the implementer community
4. Blogger or Wordpress to start or revisit an old blog.
5. TridionDeveloper.com if you want to blog with other Tridionauts, but outside of SDL (not my first preference, but no problem for externals)
6. Consider attending or presenting (again) at the Tridion Developer Summit.

The hardest part of participating in the community is realizing you have something to contribute and then giving yourself permission to share.

The second hardest part is doing it again. :-)