First, if you are hoping for specific internal information about Meta, this isn’t that. Professionally driven privacy and discretion is my first responsibility.
This is more an explanation of how I approached my work and interacted with customers, peers, and others in the Meta environment. There are lessons to be gleaned.
I spent the better part of the last year on contract to Meta. My title, Collaboration Apps Engineer, was mostly a vague catch-all, that provides little insight into the work I performed.
I maintained that a more accurate title would have been, Productivity Apps Developer or Productivity Apps Specialist.
Additionally, I ended up developing PowerApps/PowerAutomate solutions, as well as using internal tools to automate business functions across a variety of departments.
I enjoyed the work immensely, finding the professionals I worked with, both on my team, and across the company to be engaged with their work and sincere in their desire to deliver excellence.
The most recent layoffs notwithstanding, the tone across the organization was solution-oriented, fun, and imbued with excitement. That makes building productivity tools a pleasure.
Background & Perspective
I’ve been building solutions going back to my time at Blue Cross/Wellpoint, starting in the early 1990’s. My first contract (document) assembly system was built using Microsoft’s Word for DOS & WordPerfect with a Clipper Database as the back-end. This was, over time, re-developed in WordBasic and then VBA, with an Access front-end/SQL Server back-end.
I worked in that environment for nearly six years. During that time I was NOT in I.T. Instead worked in the Contracts and Large Group Underwriting departments as a Business Analyst, Senior Business Analyst, and finally Project Manager.
I’m grateful for the perspective this offered me. I worked directly with those who used the solutions I built. Rather than submit a change order to fix or improve an issue, when what I created did not match their needs, they walked up behind me, slapped me on the back of my head, and said, “Hey.. you are making our life difficult!”
Okay, I jest. There was no violence. But I was given a first hand view of the impact of what I developed - both good and bad. I believe this made me uniquely aware of the need to immerse myself in the department and listen, really listen, to what the customer, in this case, my co-workers, needed.
It helped me learn to better analyze a business challenge and, more importantly, have empathy for those using my solutions.
And, it is what led me to write, Concept Over Process. We’ll write more about COP at a later time.
It also taught me, or at least confirmed, that every environment, every business, is similar to every other. And that every environment, every business, is unique.
Lessons From Inside The Metaverse
Perhaps nothing earth-shattering here but having the experience working inside one of the world's major technology companies confirmed the efficacy of some key truths and exposed me to a few interesting tools and processes.
I offer these three ideas.
1. Explore the Internal Tooling
Every company, even small businesses, have internal systems that have been developed over time. Meta has some interesting internal tools to help all employees do their jobs. Many of them automate processes that are performed daily.
Become familiar with those tools. Seek out others who have done interesting and useful things with them. There is a good chance that those tools will help you with your internal work and that they can perform important functions to integrate with the solutions you develop.
Fortunately, our team leadership and Meta, in general, allowed for such exploration and learning.
If you are working in an environment with some internal automation tools or templates, add time to your calendar to learn and put those tools to use.
2. Transparency Provides Clarity
Meta operates with a high degree of transparency. You are encouraged to set meetings and create relationships within your department and across the organization.
The organizational structure is easily determined with their internal website. Tasks and calendars are open to anyone, at all levels, in the organization; with the rare exception of those that involve medical or other privacy information.
This allowed me, as a new solution provider, to look at the solutions, including code, that my peers, other employees, and former employees built.
This is beneficial in a few ways:
- It helped expose me to prior conversations - their tone and content. This provides cultural insight.
- It exposed me to innovative thought. There are smart people working there. You can learn something from those people.
- It helped expose me to the tools inside the company. I mentioned tooling above. Looking over completed projects and tasks allowed me to follow how those tools integrated, or did not, as the case may be. This reduced time searching for solutions when similar challenges were presented to me.
3. Wiki-ize Your Organization
Meta has an internal Wiki. It is the first place to look for answers. Everything from technologies, personnel issues, company culture, departmental focus, etc.
Of course, this requires the Wiki be maintained. There are certainly challenges with this in an organization the size of Meta. You would run into dated material from time to time. But, even that was better than trying to glean everything via back and forth email conversations.
I’ve started using Notion to document some of my processes. Previously, I have used a series of linked Google Docs.
Both systems can work. Some of the layout, linking, multimedia, and search features make Notion interesting and worth exploring. However, as with our weekly task maintenance meetings and allocated time, internal documentation requires a similar approach. You must set time to maintain that documentation.
I’ve certainly not mastered this. However, it is a task I find interesting and important. I’ll write about this at a later time as well.
Missing: Collaborative Blog
One item I found missing in Meta was something akin to an internal blog. I build solutions in App Script & PowerApps and would often answer questions from others attempting to utilize those tools. Perhaps it could have gone on the Wiki but I wanted a place where I could outline some of the solutions built and provide access to the code.
My hope was to make this a collaborative effort, allowing others developing solutions with the same tools, a platform to publish their approach and code. Properly tagged, such a tool could have a huge benefit for learning and avoiding duplicated effort.
Cut and paste remains one of the greatest tools a solution developer has at their disposal.
While I explored doing this with a Sharepoint site, I was unable to put it into play before our contract ended.
As I indicated above, every organization is the same and every organization is unique. It has always surprised me when going to work with a large organization how refined and elegant many processes are. It is also surprising how many gaps or ineffective processes there are.
When you are on the outside, it is natural to assume that a dynamic and growing organization has it all together. Naïve, but natural.
But dynamic means growing. Growing means stretching boundaries. Stretching boundaries means new areas where processes are underdeveloped. Add to this the normal day to day changes within established processes and opportunities for productivity and workflow improvements abound.
Hopefully the lessons provided are interesting and prove helpful.
How does this insight correspond to the organization you serve? What lessons have you gleaned from your organization - whether big or small?