Changing from Structured to Unstructured Work Environments

egrizzly

For those of you that have successfully changed from structured work environments to unstructured smaller startups what methods or system allowed you to sufficiently shift to the new unstructured environment?

Structured environments are typically found in larger corporations which already have mature and established processes while unstructured environments are usually with small startups that are less than five years old which have few to no established policies/processes.

As always, thanks for your participation, tips, suggestions, and comments.

JDMurray

In a larger enterprise, people tend to be siloed in specialized areas of knowledge and skill sets. For example, firewalls are manged by one team, routers by another, and VPN, IAM, AD, etc. by still others. People will sit on the same team doing the same thing for years (i.e., wearing only "one hat"). In smaller companies, people have to wear a lot of hats because there are never enough people to do everything that's needed. You can't have a "that's not my job" mentality in a small company, which is probably necessary to have for survival in a much larger enterprise. When transitioning to a small company, "empty your cup" of expectations about the way things should be run and conform to what is considered to be "normal" at your new place of work. Once you have fit in, you can work to change the bad into better.

From a different perspective, I have suffered working in start-ups that were lead by former C-levels of very large companies who thought it would be fun and a great challenge to "get back to basics" by working in an exciting, young company. Unfortunately, these C-levels bring with them their penchant for corporate stodginess and bloat in the form of documentation, processes, committees, hierarchies, and every other thing that keeps a large enterprise from being agile. It's really strange to hear them talk of their former enterprise's long and unproductive meetings, incomprehensible budget rules, and needing to get multiple-levels of approvals to do anything--then they try to implement the same processes and frameworks found in a 200K-person corporation in a new, 20-person startup. The C-levels do this so they will feel comfortable and work better and not because it's the best thing for the start-up. When this does happen, you'll never seen the joy of working for an entrepreneurial dream company depart more quickly.

DatabaseHead

Honestly, my talents were the most helpful and work ethic when transitioning to an unstructured environment.  It was see a need fill a need mindset.  I discovered early on the scope of my role would be heavily project-based which is fine, but the needle would move around.  I had a few operational activities that were constants, staying in the mindset of being fluid was the most helpful TBH.  There is no methodology or framework that can overlay this type of work environment successfully.  

A lot of people didn't like it.  Our system admin was assigned a project to build an internal website and manage the project for the front-end component.  Totally out of his element but that's how the role went.  I was building/assisting/refactoring complex stored procedures for our reporting applications, which varied heavily when I first started.  I was more of a VBA Access developer when I first started but you can only build so many helpful utilities with desktop tools.  In the end at my age and the stage of life I was in, it was extremely helpful.  

It paved the way for several roles I have held, it basically taught me my single biggest skills.  SQL.