It felt good to ship finally. What we couldn’t finish before we embarked on a two-month long visit in Asia, we worked through in bits and pieces in hotel rooms and coffee shops while there. After we got back home, it took us a few more days to wrap up all the loose ends and hit go. Needless to say, this had been a very interesting and unique experience. 

Here’re a few of my learnings and observations from our casual encounter of the “digital nomad” lifestyle, and some fond memories.

Working in hotel rooms

Throughout my many years of various corporate jobs, I had done plenty of travel and working on-the-go. So I didn’t give it much thought beforehand (business travel vs. leisure) when booking hotels and B&Bs. Most of the locations we booked were optimal for sightseeing and leisure—they certainly provided for lounging comfort. However, the chairs, couches, chaise, beds, floors—no matter how comfortable by itself, we couldn’t use them for more than an hour of work before some parts of our bodies started to ache. Even when the room had a desk, the desk and chair looked to be more as a decoration rather than being practical for working.

Coffee Shops

When you are on the go, seeking out suitable coffee shops for work itself becomes an experiment and overhead for productivity. We avoided the often accessible options of Starbucks, Peet’s, McCafe etc. even though we already knew they’d fit our basic needs for work—we wanted to taste the local coffees and culture at the same time.

We spent time seeking out new coffee shops with good reviews for both the drinks and the vibes. Even then, the actual experience and outcome for working varied. Some had really good enjoyable drinks, but were too crowded or noisy to work, even though we had gotten pretty good about being able to work at just about any small surface that would hold our laptop and a cup of coffee.

Smoke is another factor we didn’t anticipate. One quiet morning, we had an outdoor sitting area of a coffee shop all to ourselves, when someone sat down at the next table and started smoking. Another time, we were inside a coffee shop, actually working on nice big tables, when we started smelling smoke—we hadn’t paid attention that we were close (but not too close) to the outdoor tables, and smoke had come in through the door.

On the other hand, dropping the lens for work suitability, we quite enjoyed most of our coffee shop visits. The coffee culture was quite strong across the three major destinations we visited: Japan, Shanghai (China) and Taiwan. In Hualien, Taiwan, we were fortunate to get some very freshly roasted coffee beans from the local Hualien coffee farm! 

One last note of observation—compared to what I’m used to, coffee shops tend to open later in the morning. I associate a fresh cup of coffee to the start of my day. Here at home, I could find plenty of options that open before 8am (many open at 6am, some as early as 5:30); whereas it was very rare to find a coffee shop that opened early; in fact, not uncommonly, you might find an interesting coffee shop which only opened in afternoons and evenings.

Internet Connectivity

Wifi at most places we stayed in Japan and Taiwan were reasonably good. In coffee shops though we preferred to use our own mobile data hot spots (as a general habit, for security and consistency).  We started with purchasing an eSim in Japan, but then quickly realized that both of our mobile setups required much higher volumes of data usage and we were hitting the eSim data cap very quickly. Using a local eSim was no longer cheaper than simply doing the international roaming on our own unlimited US mobile plans once we factored in our usage volume.

We didn’t attempt to connect to any Wifi while in China, partly because also it wouldn’t do us much good as most destinations we needed connections with were blocked off anyway. Every now and then, our Macs would “act up” and couldn’t reach anywhere via our phones’ hot spots, and required some rebooting on both the Mac and the phone. We never figured out more specifics.

Fond Moments and Memories

Walking along the ocean front going to a coffee shop …

Working on the make-shift “table” (by putting two high chairs from the balcony) facing the oceanfront…

Working in a coffee shop with a cat snoozing next to you

Working in a comfortable coffee shop waiting for laundry to be done next door

Getting room service of some very tasty beef noodle soup while holed up in the room cranking out work, with beautiful scenery right out the window.

My decision to leave came as a surprise to many. After all, my work was well-appreciated and valued. Someone asked me what I would miss most about leaving my job at one of the farewell parties. I said, the people and connections of course. But also I will surely miss the continuous waves of exciting new initiatives or challenges, sometimes nascent or vague, sometimes super messy, always at mega scale, and never only the technical dimension.

For years I was like a kid in a candy store, excited about the wide range of things of all shapes, sizes, and flavors in front of me. At some point however, I felt like I’d worked on all major patterns, solutions, strategies, and lessons learned, even for what might be yet to come at this job. So, while figuring out what was next for myself, I quietly doubled my efforts in coaching and enabling others at work to succeed on their own, and took time to introspect my life to-date, my values, passions, and limits.

I had chosen safe paths to pursue “success” (which boiled down to a good family and a good career). These paths were by no means easy but well-explored and well-proven—I was amongst the 90% of the working population taking these paths. Though it may not be as adventurous, I feel good about what I have accomplished. Even better, it was these steady years of cumulative growth that gave me the tools, resources, and courage to explore and live out the next phase of my life differently.

So, for the first time in over 30 years, I’m not working for someone else. I am now self-employed, partnering with my husband developing indie apps. If you use a Mac or iPad for productivity work, check out TimeStory! We’re also actively evolving our app portfolio with intentions.

My priorities, as I look at how I want to live out the second half of my life, are very different from the first half. Being self-employed gives me the maximum autonomy to explore and pursue what’s truly important to me at this stage of my life.

The last 3 months have been wonderfully rejuvenating. I’m loving the excitement of working independently, at the opposite end of working in or with large corporations. I’m loving the mixed déjà-vu and stark contrast moments as I tackle similar problems but in a completely different world. I’m loving that I’m having to deal with everything from the right backup/restore solution, product design and delivery, balancing between desirable release goals and limited capacity, to marketing and AI strategies, on a much smaller scale of course.

I’m also experimenting with a new lifestyle, taking advantage of the total freedom I have on my own schedule. I might work on a weekend when there’s a good momentum going, or take a weekday off to enjoy the good weather outdoors. I’m looking forward to my upcoming 2 months of travel in Asia, integrating sightseeing and “remote” work (as in away from home), plus traveling with my mom to see one of her bucket list destinations.

More to come as I take one step at a time in my new journey. I’m not sure how/what the next thing might unfold, but I will share from time to time what I’m up to and my learnings and reflections. In the meantime, I’m taking these words of advice from The Book of Charlie:

Take a chance.

Enjoy wonder.

Savor special moments.

Practice patience.

Observe miracles.

Make them happen.

Cry when you need to.

Make some mistakes.

Learn from them.

Spread joy.

I wish to express my sincere gratitude to all who have coached, mentored, supported, helped, cheered, sweated with me in my first half journey—you know who you are, I feel privileged and lucky to have crossed paths with you.

It is these years in the US (particularly earlier on) that I learned who to be and how to be an adult. My identity, personal values and principles were rediscovered and reshaped from my childhood upbringing. Family value and work ethics were two things that stayed and strengthened from what I was impressed upon growing up; but my worldview, values, inspirations and all were heavily influenced by and cultivated in my American family and the surrounding societal and cultural environments in the last 35 years. For example, 35 years ago, the college-bound young me had a cynical worldview (not uncommon for my generation from China at the time)—this cynicism had been replaced by a much more constructive attitude, thanks to those early influential years when I started living in the US. (Unfortunately there’s a lot of cynicism in the current climate and it pains me to watch our next generation growing up under this influence.)  To all my family members, friends, mentors, colleagues and acquaintances—I am grateful for our shared experiences, your advice and support, brief or long-lasting, in the past 35 years.

Taking stock of the first half of my adult life, I can happily say that I fulfilled my American dream I had started with. Yet there’re so many things I wish to do that I had not given myself permission to, because they would take time and resources away from my steady pursuit of my main goals or might introduce too much risk—

• I hadn’t contributed or paid forward as much as I wish I had.
• I hadn’t tried to be my own boss.
• I hadn’t tried my hands in all the things that intrigued me.
• I hadn’t traveled to all the places I wanted to visit and experience.

Even between my two main priorities (family and career), I often had to make trade-offs. I wish I had as many shared memories with my kids when they were growing up as my husband does. I wish I could be more emotionally there for my mom after my dad passed.

For what I have achieved, I must also reflect on what I made to work vs. what worked naturally for me and my preferences, as I look forward to the next phase of my life—

• I produce my best work when I can “marinate” on it over time.
• I value slow, sustained long-term progress on a hard subject over superficial or short-lived quick wins.
• I am bad at multi-tasking, though my job demanded a lot of that and I probably came across as being pretty good at it.
• I’m bad at separating my mindshares between my job at work and my personal life—the former often sucked too much energy out of the latter.

The clock is now ticking. I have a new set of priorities, very different from the first half; while I’m ever more cognizant that my time and energy are now my most precious resources.

Unfortunately, the more I progressed along in my corporate job career, the less control I had on my own time, and the more demanding the constant context switching. So, I ended my corporate career (a month before this anniversary date), as a wrap for my first half; and as a kick-off for my second half, I’m joining my husband and the 10% working population (US) to be self-employed.

With this new-found maximum autonomy, I’m experimenting with and adapting a lifestyle design that will more harmoniously integrate my whole self—my values, interests, strengths as well as limits, while aligning my time and energy to what’s truly important to me in my second half.

This time I don’t have a pre-defined, proven path. I’ll let each step unfold the next, and along the way, enjoy wonder, savor every moment.

My uncle and aunt came to the US for graduate school 10 years before, under much harsher conditions. When I came to the US, they had just finally settled down to stable jobs in their 40s. My uncle is not the talkative kind. Neither was I. But he made a point to say this to me very early on after my arrival to the US and left a big impression on me. I think about it often to this day. He said (my paraphrasing)—

This country is very open and accepting of immigrants. They don’t have to be and it’s not the case everywhere else in the world. Appreciate the opportunity you have—the fact that you are able to come to this country and hope to make a better living—it’s because this society and the people are open and welcoming. It’s a privilege to have. When you’ve made it, don’t forget that. Be part of this openness and kindness, pay forward.

• We closed over 100 tickets (about a third of all open tickets) through disciplined review and deliberation—no details were left, no handwaving for the sake of moving through tickets quickly. This was a mix of product decisions on what to pursue and simple cleanup of redundant or obsolete tickets.
• For each of the remaining open tickets, we estimated a value/impact score as well as a cost/effort score. With this data at hand, we were able to quickly identify candidates for our next release (based on the Impact-Effort matrix).

It had been a while since I had last done detailed product-level ticket triaging (the last time I was accountable for a specific product delivery was over 6 years ago, in a corporate setting). After we had been at it for a while, I couldn’t help but notice, especially after a few hard or picky customer requests, how tempting it was for me to resort to an “easy” solution—just make it configurable. If we didn’t really have more context or understanding of what motivated the request, by making it configurable, we no longer needed to figure out the why and how exactly a user would use the new function for their own benefit. We’d simply give them the ability to implement their own use case.

To be clear, Aaron and I have always felt strongly that a software product should be opinionated, though we value every customer question, request, and interaction and use those to inform that opinion. But I caught myself a few times being tempted by the idea of “just make it configurable” so that I could move on to the next ticket. Just coming off my corporate job, I knew the symptoms and the consequences all too well. In large systems or large companies (that offer solutions for many markets, businesses, or users), configuration can be one of the most misused, most overlooked, least-governed, and the most problematic product/system areas amongst product, design, engineering and architecture teams.

Often, when it comes to anything configurable, it’s assumed to be an engineering responsibility (since configurability is also one of those “ilities” or “non-functional” system quality attributes). But as soon as you make the configuration available via UI for users to configure (as opposed to system internal configs that engineering teams manage), that configurability itself becomes UX/UI, and needs to be approached with the same product & UX design discipline as any other user feature. Unfortunately the recognition and clarity on the nature of the configuration and accordingly the shifting of primary responsibility to product & design are often missed.

Even when a user-facing configurability is led by product and design, it is harder than it seems to keep up the same rigor as other features. When it comes to a customer request, especially when the request is worded very specifically by an experienced user, almost in solution or design terms, it’s especially important to go beyond the literal ask and go back to the basics of product rigor: What’s the underlying pain point or use case? Did the user frame the request only based on existing system constraints, workflows, or even work-arounds in that very narrow context? Should the product be opinionated in this feature area, rather than leaving it to users to customize? Would a new setting cause more confusion or overhead for adoption? …

For our own products, every configuration is weighed carefully. Even as the request itself is legit, new configuration feature design may also be coupled with ease-of-use functionalities (e.g. pre-configured templates or personas). More often than not though, specific configuration requests are clarified, reframed or merged into a better problem to solve that is consistent with our product vision and principles.

I finally paid a visit to the Chicago Starbucks Reserve Roastery (the largest in the world).

Walked the beautiful Chicago riverwalk. And got to see how bridges are repaired over Chicago river.

Enjoyed some “do nothing” moments, soaking in the breeze and view of the river, the people strolling, magnificent buildings and the reflections of them, and the L passing through every now and then. Wrapped up in the west loop Timeout market, with some cold noodles and beer.

The main function of a feature … is often the easiest part.  It’s everything around the feature that makes it harder: UI design, localization, refactoring, accessibility, state restoration, getting new artwork (for a toolbar button, for instance), dealing with errors, testing, updating the documentation, etc.

What consists of “everything around the feature” may vary from one type of software products to another (e.g. UI apps vs. services vs. data-centric apps), but the needs and principles of engineering a real product don’t change.

I often say to people that it’s easy to showcase a Proof-of-Concept (PoC).  Name any technology buzzwords (AR/VR, AI/ML, Blockchain, automation, …), and it’s easy to turn around a PoC with those buzzwords attached.  But don’t be carried away by the bells and whistles you see! A demo itself is not proof of a usable or reliable product; a PoC is not a demonstration of how easily or quickly one could go from a PoC to a real product.

It’s everything around making it a real product and consistently reliable subsequent product updates that require time, effort, and most importantly the care and art of engineering.  The inherent engineering focus and prowess is what differentiates one product and vendor’s viability from another in today’s markets.

I changed my job in January.

At the beginning of the year, I left my consulting agency, where I was leading large distributed engineering teams, to join a global Fortune 500 corporate as an individual contributor in a newly created Chief Architect role. Every aspect of this new role was in stark contrast to my old one: from the nerdy and sometimes deeply specialized engineering communities to the broad spectrum of business, marketing, and operations communities; from staring at debug logs and discussing design patterns to explaining relevant microservices and engineering concepts to the eager non-tech business and operations audience; from pitching new ideas and proposals to being on the receiving end of a diverse range of pitches and deliberating on them…

Life often turns out to be quite peculiar.  In all of my professional career, I viewed anyone that called herself an “architect” with a bit of initial skepticism and avoided wearing a pure “architect”-only hat myself.  To me, it tends to paint someone who likes to draw on paper only and often has no idea how things are built in reality (and consequently has no real influence over the actual engineering process and the outcome).  I decided to take on this job only after I had been repeatedly assured that I would be as close to the action on the ground as I wish and have equally easy access to the CIO.

Looking back on the year, my “chief architect” experience has been highly stimulating, gratifying, and rewarding. Given the scale of the business, never have I learned so much and gained such broad perspectives of technology innovations and offerings across so many disciplines. At the same time, never have I felt my work was so broadly respected and influential in so many aspects of the business, especially given that this was more of an advisory role than an operational one.

We traded one lucrative income source for the pursuit of an app idea.

At the end of 2018, Aaron made the decision to stop his lucrative consulting gigs completely, to devote 2019 (and beyond) in pursuit of an app idea.  It was a joint commitment, as we both envisioned its many potentials, while fully prepared to embrace its implications financially, especially when we also had 2 college students to be paid for at the same time.

After 6 months of dedicated development (along with setting up the web site and all other things you have to do running an indie app), Aaron launched TimeStory 1.0 in July, averaging 1 major update each month since.

Last time he wanted to do an app, not two months after he quit his job, he was persuaded by a startup co-founder to join their venture.  This time is different.  He has already turned down multiple offers/opportunities this year to stay invested in this app vision. Indie app development is a hard and sometimes lonesome journey that may lead nowhere, but while at it, it’s an adventure rich with ups and downs, with the pride and pressure of shipping a high quality product on high velocity to a diverse global user base, and with the chores and insights of marketing and support.  2019 is just the beginning.  We have a lot to look forward to in 2020.

I became an empty-nester this year.

On the family side, the youngest of our two kids graduated from high school in the spring, and started college in the fall.  While it was gratifying to observe her rapidly maturing into adulthood, we also didn’t waste any time starting to formulate our own new, “empty nest” lifestyle norm.  Cooking became a lot less stressful and a lot more experimental — imagine not having to worry about having enough of the right kinds of food to feed an always-starving tall teenager any more!  In the mornings, evenings, and weekends, we went from revolving our life around kids’ extracurricular activities, to filling up calendars with our own extracurricular activities.  It seemed as if I were envious of the opportunities the kids had when growing up and now that they have moved on it’s time for me to start.  The kids have noticed too.  Their Christmas gift for me was an Alfred’s piano book and a “daily practice” bear (yet another irony?).

On the decade past and the decade ahead

2019 is the year it seems, I took not one, but at least two major leaps of faith.  Reflecting more on the decade, they were actually the culmination of previous years’ earnest though unwitting personal and professional explorations.  For example, the year-long Chief Marketing Technology Officer program (an executive MBA-style leadership training program) I went through in 2016-2017 forever changed the lens I used to conduct myself and my life, and to view beyond the current events of technology and society.  (I would have never guessed from the face value of the program name itself.).  The hypotheses and big ideas I formulated during that year and since, I was able to test and validate to some extent this year in my new job; the skills I learned in those years became my secret weapon to navigate and be successful in my new role and new environment.

In many ways, this moment in my life feels like a juncture point, where one chapter ends and a new one begins.  There’s a feeling of lightness, excitement of many ideas and possibilities, and a sense of experience, maturity, and preparedness to weather what may come of the adventure ahead.

I’m not talking about just those 3rd party products that we integrate to deliver our customer experience (e.g. a loyalty management product). I’m talking about every B2B service or product that we use to keep our operations running smoothly and to keep up with the demands from the emerging digital organization (as it goes through its own transformation), for example, store operations & execution, labor operations, crew training & certification, staffing & scheduling, inventory management, supply chain distribution and logistics, workplace engagement, etc.

Just like consumer-facing businesses, incumbent B2B vendors are equally at risk of being disrupted by digitally native startups or the big technology platform players.  The criteria and lens we are accustomed to use to evaluate and select vendors and their solutions for our business operations are no longer sufficient to predict their ability and viability to sustainably meet the dynamic demands from the ever increasing pressure of business operations process improvement across the board, as a result of our own digital transformation.

For example, common practices in vendor selection look at product capabilities as compared to business functional requirements, cost/pricing, services & support, financial & organizational viability, product position in the market, etc. However, product capabilities and market position are static snapshot views reflecting how the product (and its vendor) performs at the time of assessment. Instead, we need to assess and predict a B2B vendor’s evolution fitness for weathering market disruption dynamics and meeting our digital transformation needs, by evaluating its product engineering practices.  In today’s world, this proves to be an important viability predictor.

Over the course of this year, I used the same principles we apply in digital transformation, in DevOps, and the same engineering KPIs we use to measure our own progress, to evaluate a variety of vendors across several B2B market domains on their respective product engineering practices.  Some of the evaluations were for the purpose of selecting new solutions to address gaps or needs in business operations, while others proactive on-going “fitness” assessment based on our growth needs.

The results were quite telling.

Sometimes, it felt like a mini live-play of disruption, watching the young, small startups easily catching up on functionalities against establishments in a matter of a few months due to their abilities to push new updates many times a week (or day) and their abilities to “co-evolve” experiences with end-users directly by sending them “what-if” features and collecting instant feedback for the next iteration.

Other times, I could see where each established player was at in their own transformation journeys along the whole spectrum – some stuck in their past success, and unaware of the risk and pressure coming from platform players; some aware of their own challenges and competition in the market, but didn’t truly understand the nature of the new “agile” game and what needed to be transformed at their cores.

To be clear, startups are not automatically better at engineering new products.  I’ve observed a common misconception by startups and long-time incumbents alike when showcasing their solutions’ architecture, scalability, and reliability etc. aspects.  Being in the cloud is by no means any proof of the organization’s own agility or engineering maturity for scaling their product.

For big or small players alike, it’s easy to choose one of the cloud platform providers to build out the initial solution.  There’s so much out-of-the-box platform-provided capabilities to be leveraged right away, almost anyone can have “something” built quickly these days.  The question is: is this truly a “product” (albeit MVP) ready to be iterated quickly in the field with real users?  How quickly can the vendor roll out new functionalities and scale up in a consistently reliable manner?  When the only answer I got back on the question of “what’s your approach to scaling your solution” is, “the underlying Azure platform will scale for us”, it was clear there’s no deep architecture or engineering thought behind the solution (possibly due to the lack of experience or understanding of product/solution-level architecture & engineering needs for scaling).

To effectively support large business customers and their increasingly more rapid transformation needs, B2B SaaS providers must understand what it means to scale the product, the experience, and the engineering team itself, sustainably.

There are a few areas of probing I rely on for clues into the maturity level of a B2B provider’s product engineering practices:

1. Trunk-Based Development. Many vendors were surprised when I probed about code management, branching and merging approach used in development. Based on my experience over the course of this year, it’s amazing how directly and accurately it correlates with a vendor’s product release agility.  For a sizeable engineering team, any vendor who is not doing trunk-based development almost always are the ones that can only release once every 4-6 months or longer. They are also more likely to run into last minute release stability issues, resulting in further delays in releases.

2. Test Strategy and Approach. The level of automation (and where & how automation is done) and sophistication in testing methodology directly reflect an organization’s engineering maturity.  I’ve been presented plenty vendor talks of surface-level automated tests (e.g. using UI drivers) and boiler-plate statements on unit tests, whereas those that truly get it right demonstrate working test executions and outcomes with more and more sophisticated tests layered along the entire DevOps tool chain. Testing in their universe is at the core of engineering & tool chains.

These two areas, along with DevOps, enable the engineering team to keep their product in an “always deployable” state as much as possible, which is the foundation for being able to iterate and evolve the product in the field quickly.  (I refrained from using DevOps as a primary source of probing, as I found that CI/CD and DevOps, just like “agile”, have been talked about so much and so universally, it’s hard to differentiate one from another just by description and discussions in a limited amount of time.)

3. Demonstrated commitment in product observability as part of foundational solution elements, e.g. telemetry implementation & tooling. Understanding the importance of observability and subsequently having the ability to proactively prevent production issues or to troubleshoot quickly improves production availability and reliability. This provides the foundational confidence for pushing frequent software updates (i.e. product iterations).

4. Demonstrated thoughtfulness in the selection, definition, and implementation of KPIs that measure user experience performance. One of the manifestations of great product engineering is the data-driven feedback loop of how the product (through its features/functionalities) is performing in users’ hands.  It’s easy to simply track service response times, or even just various page, screen, or UI element load times as reported by the underlying frameworks; it’s much more work to figure out meaningful user-centric performance metrics, implement them, and then optimize user experience accordingly. Engineering team who are not close to user experience feedback tend to optimize the raw performance times for certain areas of code in isolation – these numbers would often look quite acceptable or even good, whereas in real use, one can pull out a watch and count to many seconds or even minutes before the product is loaded or usable.

This sets the foundation for engineering-enabled, data-driven, test-&-learn product evolution mindset.

5. Approach to product evolution.  “Tell me what you want and I will build it for you.” I hear this quite often from vendors eager to satisfy prospective customers.  End users often request and describe a feature/functionality request based on his/her prior usage context or experience; or simply, what they thought they wanted.  Blindly building out a product’s feature/capability set based on end-user requests can become a detriment to the provider and its product itself. I once asked what was the rationale behind supporting windows mobile devices, the answer wasn’t that there was any user base of windows devices, but rather that they posed the question “should we support windows devices” to customers and customers said “sure why not”.  The consequence was that the team significantly diluted precious engineering resources that could have been used to make the experience for the real user base better.

6. Product thought leadership, recognizing and prioritizing those capabilities that are quickly forming the new ways of working in the digital economy and digital ecosystem, e.g. self-serviceability, APIs and rich interoperability features, visibility and clarity of data usage and compliance, etc.

7. Engineering leadership and culture. Engineering leaders must be close to the code and team operations on the ground; and engineering team must be close to the customer and close to the field performance and feedback.  While I’ve seen very successful distributed engineering team setups, I’ve also seen product and team paralyzed due to layers of lost translations, which directly affected the agility and quality in engineering a product.

It’s also interesting to pick up clues of engineering excellence by the team’s attitude towards technology selection and use in the product. In the engineering community, there are always plenty passionate debates around languages, libraries, components, tools platforms of choice.  At the end of the day, no matter how “superior” a particular technology may be, bad engineering can make the resulting product many times worse performing in every aspect than if a less flashy technology is used but with better team engineering expertise and confidence.

Finally, just like interviewing candidates for potential hire, conclusions or predictions drawn from interview sessions could sometimes be misled.  When we want to minimize such risks, companies often conduct a test phase with short-listed providers to evaluate the products (and vendors) through simulated or real-use scenarios.  When you can afford such an approach, I find that capturing and tracking DORA‘s Software Delivery and Operational (SDO) performance metrics are invaluable engineering performance indicators during this phase. A promising startup who struggles to implement and report on these KPIs is a risk sign of whether they will be able to scale the product and team successfully.

To summarize, when comparing vendors and their solutions, consider trade-offs towards better product engineering practice rather than more complete functional capability coverage:

• Rethink requirements on product capabilities and differentiate what’s core or foundational vs what’s easily evolvable. A vendor with strong product engineering practices can easily and quickly catch up on some missing functionalities in a short period of time and provide better experience and innovation of new capabilities in the long run.
• Elevate the importance of “digital ecosystem” capabilities, as increasingly a product is interacting with other systems. Open, transparent, and inter-operative (or collaborative) product characteristics such as data access APIs, self-serviceability, programmability, event streaming/messaging/notifications, etc. reflect the B2B product team’s inherent understanding of where the world is heading rather than where the world has been, consequently a better prepared product and vendor.

Don’t mistake use of cloud platform alone as being modern and agile.

Reliability, resilience, observability and insights into how a product is functioning is a prerequisite to get right and get very solid, to enable product to evolve quickly.

If the engineering team is not able to keep their code in an “Always Deployable” state, they are likely not going to meet our “agile” business needs, regardless how complete their current functional capabilities are.

• So far I’ve finished 11 books in the last 10 months, that’s about one book a month.
• Out of the 11 books, 7 were audible books, 4 were kindle.  I listened more than I read.

When I plotted them out in a TimeStory view, some other interesting patterns came out.  For example,

• I finished more books in the 1st quarter of this year than the total sum of the rest of the year;
• I definitely lost interest in one of the books (the 1st long blue bar crossing the today line); and,
• there are too many books (4) in progress right now, although it seems I never start another audible book before I finish the one already in-progress, but it doesn’t bother me to start on another kindle book when there are already several in progress.

When I showed this to my husband, his immediate question was: how did you know when you started reading each book?

Well, I’ve been logging the start and finish date of each book since the end of last year, for the purpose of understanding how I’m doing in my reading objective.

There’s a lot more I’m curious to know about myself – what’re my reading patterns?  For example, how long do I tend to read each time?  Does it vary based on the type of book or topic?

Then I started thinking.  As someone who’s been in the business of mobile app development for a good variety of consumer-facing brands, I know all too well how apps collect usage data on just about every impression, touch, events.

Kindle and Audible must have all the information I’m looking for already, and much more!  Moreover, because Audible and Kindle are my go-to apps for books (yes, I almost never read paper books any more), I ought to be able to get all of my own usage data back from these 2 apps, to learn about my own book habits.  It would give me a lot more insights than what I can manually track for myself.

Checking into both apps in the areas I don’t normally look, this is what I found:

Audible

• Audible has a “me” profile area, where it provides some “gamification” experience to incentivize more reading.  But I could care less about them.
• I found some high level stats that are somewhat interesting to me, i.e. the total listening time by month for the last 5 months, and the daily listening time for the last 5 days.

Kindle

• Kindle provides a “Your Reading Insights” feature, which tracks and reports how many days in a week and month you have read (on Kindle).

While some of these “insights” about me may be mildly interesting to me, they are designed to bring more engagement between me and the app.

As businesses are racing to paint a full picture of each customer, assigning attributes to each of us (e.g. which product affinity), and trying to be better at predicting (therefore influencing) our next decision or action, we are at a point where everyone else (who’s trying to selling us something or to profit from our activities online, e.g. searches or social media interactions) know us better than we know ourselves.  If they don’t, they have the mechanisms to collect detailed information on our behaviors through first-party channel interactions as well as obtaining through 2nd and 3rd parties.

What I know about myself is what each business chooses to tell me about me:

• Amazon.com tells me what products I like to browse and what movies I like to watch
• Audible tells me I’m a “Weekend Warrior” along with other badges awarded to me
• Headspace tells me what my average meditation duration is
• LinkedIn tells me what jobs I’m a good match for
• …

Not counting any predictive aspects of the analysis each business is trying to perform about me, I know that there’re still plenty of the basic “facts” data (such as events recording) collected about me (e.g. every touch in an app and every dwell second on a screen, location, etc.) by each business, compared to the highly curated data points that have been provided back to me.  It’s understandable that no one is in the business to invest in my learning about myself, rather, what’s been provided about me to me is what’s relevant of me for me to know with respect to that business.

BUT, if I have intentionally or unintentionally allowed my behavior (my data) to be collected and studied, I want to have the same ability to access that data as any internal consumer or business partner, in real time, for example via APIs or meaningful data exports. This is much more than the right of access to personal data, which companies can satisfy with batch downloads of unprocessable files that take days to prepare.

The right of access to personal data generally is focused on my ability to discover what data collecting businesses know to find errors, to understand the scope of their data collection, etc. But not to be a participant in the data exchange platform, and not to have the real-time, detailed, raw access to my own data.

Whether we like it or not, we are all digital citizens of today’s digital society. Data, in real-time consumable form, or API integration capabilities, should no longer be only a business-to-business interest.  Personal Data, must be facilitated between businesses and users bi-directionally, in a modern, digitally interoperable manner, for us to be equal and full participants of the digital society, rather than a one-sided business-to-consumer exploitation.