My daughter's elementary school has this thing called the Growth Mindset Program. I didn't really pay much attention to what that meant when I first heard it. But as she progressed through a year or two of school, it came up more and more. So I figured it was probably time to figure out what it means.
I asked my wife, the teacher. She told me it can be explained simply as "the power of yet." When children struggle with something, instead of thinking "I can't do it" we help them frame things differently so they say "I can't do it...yet." See how that works? Now they know it's just a process and they'll get there eventually.
That was enough for me to feel like I understood it. It makes sense for developing young minds to think that way. I felt lucky that my kid was in a school that had such high order thinking.
Then it came up again. My wife and I were helping our daughter navigate some challenges she was facing due to some perfectionist tendencies, and we came across a book called Bubble Gum Brain. It's a tale of two kids with different brains. Bubble Gum Brain likes to stretch his mind and learn new things without worrying about mistakes, but Brick Brain figures there's no way to change things so it's not worth trying.
Riveting fiction. But it actually helped. And in case it's not obvious, it's about Growth Mindset. (I also discovered a good book called Giraffes Can't Dance that has a similar message in a slightly more subtle fashion. It could more accurately be titled Giraffes Can't Dance...Yet.)
So that was that. Now my daughter was better able to manage her bouts of perfectionism by thinking about bubble gum and giraffes. Parenting achievement unlocked.
Then it came up again. Except this time, it wasn't the eight year-old. It was Twitter. And it actually came up a lot. My Twitter feed is primarily filled with cloud computing and tech pundits and professionals (with a smattering of comedians and baseball reporters just to confuse and entertain). So I was surprised to see an elementary school education concept come up with some regularity from this crowd.
IMO the most important skill to have in the tech industry is a Growth Mindset. The list of technology you "should know" is constantly changing. The most valuable skill is learning how to learn.
I'm sure you're way ahead of me here. My brick brain had taken this long to realize that this wasn't just for kids. In fact, maybe there was something to the fact that my own kid had been struggling with perfectionism. Have they found that strand in the human genome yet?
Yes, Growth Mindset is a thing. Once I began down the internet rabbit hole, I realized just how much of a thing it is. "The power of yet" isn't just something my wife made up to explain it to me. There are gobs of research, books, articles, and videos about it. And it's something that requires real cultivation. If getting everything perfect on the very first try is something frequently lauded, it's not a great environment for growth.
Thankfully, I've been lucky enough for the past several years to work in organizations and for managers that heavily value learning and actually do embrace a Growth Mindset. I just never put a name to it. (I've been in the opposite situation too so it's nice to have some perspective on it.)
So despite me burying my head in the sand about it for so long, I've been attempting to tap into my bubble gum brain as much as possible. I'm working on being less affected by a fear of failure and trying hard to celebrate my mistakes as part of the learning process. I guess what they say is true. You can learn from your kids.
Why am I writing about this now? Because at the start of this new year I've taken on a new role at VMware, leading a small team and focusing on developer engagement to help enterprise developers learn about and get started using VMware Tanzu. I've been a developer before, but this particular experience is a new one for me. And some days I feel like I don't know how to do it...
In a sea of overloaded terms, it seems to me that the word "hybrid" is perhaps one of the most often used. Whenever we want to convey that we are combining two [or more?] different elements into one, we stick the word "hybrid" in front and call it a day. It all started with genetic cross-breeding - plants and animals - in the biology world. But then the vehicular world joined the fun - hybrid cars and hybrid bicycles. In the last few years I haven't been able to stop hearing about hybrid clouds or hybrid IT. And not to be outdone, the financial industry is in on the trend - you can of course invest in hybrid securities. (There are even hybrid golf clubs, in case you can't decide between that 7 iron and your 3 wood.)
As I reflect on my professional past, and in a continued effort to overload the term, I sometimes find myself describing my career in terms of hybrid jobs. (Indeed, I am notthe first oneto coin this term.) I like to think of myself as a little left-brained and a little right-brained; a little technical, a little business; a computer geek with people skills. I am definitely most happy when I have a job that lets me build things, write some code, and potentially get into the weeds on technical stuff, while also allowing for me to analyze, synthesize, collaborate, and share information with a wide array of audiences from sales people to customers to engineers. I like sitting in that nice spot inside the middle of a venn diagram.
When I last changed jobs after spending so long working in various areas of Enterprise IT, I was very lucky to have found a position that seemed to combine my skills and interests into something that felt like a perfect fit. Even more than the job definition itself, I was able to hybridize my career as I moved from a monolithically slow enterprise IT world to a lean and agile product team in an organization with a startup sensibility.
The growth and knowledge I gained during my tenure there has been invaluable, but the time has come to once again expand on the hybridization of my career. So today, I'm very happy to report that I've joined Pivotal as a Product Marketing Director.
There's something about Pivotal's mission -transform how the world builds software - that appeals to all parts of me. I've lived the problem from both sides. When I worked in enterprise IT, we were constantly challenged by everything related to the development and deployment of software. It just wasn't a core competency of the company, and things often took too long and required too many people with too many different skill sets. On the other hand, even in a product development organization where building and shipping software is supposed to be the core competency, it was still challenging dealing with the complexities of engineering and large teams of developers who have various areas of expertise and experience.
No matter what kind of organization you're in, building software is a difficult thing to do, especially as you constantly face the rapidly changing technology [and business!] landscape. Except nowadays, every company is a software company. It's not just the Silicon Valley startups who need it. Every company these days undoubtedly has a lot of software - whether internal or customer-facing (or both) - to build and manage.
That's what makes Pivotal's mission so incredibly intriguing. Companies (perhaps the biggest ones especially) need to rethink and revisit how they design, develop, and deploy software. In today's arena, that often means they need to be more cloud-native. But it's bigger than one technology or a single tool - it's truly about transformation. That's why I really love how Pivotal tackles it not just with a strong portfolio of products (from the flagship Pivotal Cloud Foundry, to the open source Spring framework, to the more widely known Pivotal Tracker, and even a Big Data Suite), but also through Pivotal Labs, where they partner directly with customers and guide them through the change.
As for me, I'm particularly fired up about that one word in my new title that I haven't fully experienced in my career yet - marketing. I'm thrilled to be able to work with a truly incredible group of professionals as I discover how to sprinkle that bit of marketing in along with my passion for the technology and my enthusiasm for communicating about it. I'm eager to get started. Let's do this!
It was exactly one year ago today that I became a Product Owner (née Manager) at CenturyLink Cloud, and as a colleague of mine likes to point out, that's a really long time in "cloud years." As I reflect back on the experience I've had so far, it feels good to know that the me of today knows a whole lot more than the me of one year ago. Just as a college student wishes he could go back in time and educate his high school self, I now find myself thinking about the helpful things I could share with my enterprise IT self and all my former colleagues. So with that BuzzFeed-esque premise, here are some things I'd let the trapped-in-IT-purgatory version of myself know about how life could be.
You Don't Know The Cloud
Everyone I worked with in IT used to talk about "the cloud" as if they knew what it was and had used it on various projects. Sure, there were plenty of times that a vendor would sell services branded as "Cloud" to attach some buzz to what was really more analogous to a traditional application service provider or legacy hosting model. In reality, almost nobody in IT actually understood or took advantage of cloud for any practical purpose.
My favorite definition to use now when describing the cloud is Dave Nielsen's O.S.S.M. acronym: on-demand, self-service, scalable, measurable. Before, all the cloud really was to me was a series of "as-a-Services" — Infrastructure-as-a-Service (Iaas), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS) — and we seemed most comfortable with SaaS (a familiar story for many enterprises). I complained plenty about how long it took to get a server stood up and I thought the move the company was making to colocation might begin to solve things. I didn't recognize how much IaaS would have helped with that, or even more how the power of PaaS may have eliminated that need altogether.
The barriers for entry to the cloud were the usual ones — security concerns about data not being on premise, the question of whether our regulated/qualified systems could live on cloud, some perceived lack of control — I've heard them all by now. Except they aren't barriers, they are just challenges. Tides are turning and enterprises are embracing cloud, from public to private to hybrid cloud as well. It's exciting to be working at a cloud company right now.
Lesson: Have your IT organization seriously explore a cloud migration. Consider PaaS along with IaaS. Hybrid cloud may also be the way to go. Don't be discouraged by the challenges — there are ways to work through them.
Your Project Management Methodology Is Broken
Most of the projects I worked on in my former life lasted more than a year and yielded little to no value for the business. By the time the original requirements were being delivered, they had already changed and probably weren't even right in the first place. The project methodology we used, RUP (Rational Unified Process), was supposed to handle this problem with iterations. In practice though, this was mostly lip service as the project invariably fell to using a more traditional Waterfall method.
On the team I work on now, we use Agile. There is a wealth of information to be found elsewhere online about what Agile methodology is and how it was born. There are many forms of Agile such as Scrum or eXtreme Programming to name just two. One of the key elements of Agile is its flexibility in allowing for rapid respond to change. It's about shorter development cycles (called "sprints") and it encourages early delivery and continuous improvement. We do 21-day sprints, though some teams have even shorter iterations (1-2 weeks) depending on what makes sense for a given product. Each sprint is focused on the progressive refinement of new features — delivering some level of value with each release, starting with the Minimum Viable Product (MVP). This creates a constant feedback loop and allows the team to fail fast and course-correct quickly as needed. Every morning there is a "standup" meeting where the whole team stands up and talks about what they are working on. At the end of each cycle we have a retrospective to discuss what went well, what didn't, and what actions we can take to improve the process.
I can already hear some former colleagues pooh-poohing these ideas with utterances of "that doesn't work in a big enterprise environment" or "what about documentation and compliance?" or "it won't fly with the way we do budgeting." Not true. It can work. One of our engineering leaders likes to say something like, "This is the best way we know how to develop software today. If we find a better way tomorrow, we'll do it that way instead." Find a better way and make it work for you.
Lesson: Use Agile. Forget about "services" and "projects" and build products. Fail fast. Ensure feedback loops. Embrace change!
For a few months at my old company, I was on a small team tasked with delivering SharePoint. It started out experimentally and wasn't widely used so we were able to fly under the radar a bit and follow our own processes. We did pair programming, frequent releases, progressive refinement, and just the right amount of documentation. Looking back now, we were exhibiting certain Agile characteristics without even knowing it. On top of that, we were responsible for both building and running the whole stack and we embraced automation wherever possible. (I have fond memories of "Redeployer" — our ASCII-art-infused command line tool.) At the time, I'd never heard of DevOps, but I now know that these are some of the key characteristics of DevOps organizations.
One of my first assignments in my new job was to read The Phoenix Project and it was a completely eye-opening experience. It's a great way to be introduced to DevOps if you're unfamiliar with it, as is Richard Seroter's Pluralsight course, DevOps: The Big Picture. Just like with Agile, the resources you can find online about DevOps are endless and will all do a better job defining it than I could. Sticking with the theme of four letter acronym definitions, John Willis coined C.A.M.S. to describe DevOps: culture, automation, measurement, sharing. In a way, it's kind of an extension of Agile for the Operations world...but it's really more than that. To me, it's about the idea that everyone is on the same team, working together towards a common goal. No more "us vs. them" mentality.
Unfortunately, our small, Agile-ish, DevOps-ish SharePoint team did not last long. It got sucked into the enterprise IT vortex never to be productive again. For an organization to truly adopt DevOps it must completely change the way it thinks, starting at the top with upper-level management and cascading all the way down to the boots on the ground. There's no tool for doing DevOps, but there are DevOps-y tools that have gained popularity like Chef (infrastructure as code), Docker (containers), and a bevy of continuous integration (CI) tools.
Lesson: You probably can't change your organization to magically embrace DevOps, but you should at least try to adopt whatever DevOps principles you can within your own team...and maybe you should slip a copy of The Phoenix Project under the door of every executive at the company and hope they get the DevOps bug.
There Is Database Life Outside Of SQL
One of my favorite computer science courses in college was the relational databases class. Throughout my career in IT, particularly during my days supporting the Finance organization, no skill served me better than my knack for writing complex SQL queries. So the first time I heard about "NoSQL" databases, my brain wasn't ready to comprehend what that meant. Nobody I worked with was ready either. Every application I worked with in enterprise IT had an RDBMS backend. The only "choice" was whether to use SQL Server or Oracle.
I realize this is still largely the case for many organizations. I see plenty of customers now looking for ways to put their critical relational database workloads on the cloud. Still, NoSQL and Big Data are some of the biggest buzz words around, and while enterprises have been relatively slow to adopt them, this could be the year they really start to pick up. Admittedly, my experience with NoSQL databases is still relatively limited, but becoming familiar with some of the different types (like key-value stores or document stores) and many of the primary use cases (distributed, horizontal scalability, extremely large data volume, schemaless data structures) has me thinking about data storage in a way I never used to.
Towards the end of an IT project, just before go-live, we used to retroactively write a Non-Functional Requirements (NFR) document (because it was a mandatory artifact) and usually it would contain made up numbers about performance or load requirements, most of which could never be tested or actually met in the real world. We always tried to scale the app, usually by adding more servers and a load balancer. Of course this was never enough because we were a global company and we put most of our apps in a single location in the United States. (Plus, we usually had a single database server behind the app servers anyway...see above.)
Enterprise applications don't have to be on par with Facebook or Google, but large organizations still need to build apps that scale for both heavy load as well as for a global distribution of users. Just about every application I built during my IT tenure used a basic three-tier architecture and a simple load balancer. In today's modern environment with the convergence of enterprise and consumer apps — users expect things to work just like they do on their web browser at home and on their smartphones and tablets — this just won't cut it anymore. Since leaving the one-track mind of the enterprise, I'm just becoming familiar with some of the emerging architectures (twelve-factor apps, microservices, containers) that scale better and are more suitable for running in a cloud environment.
Lesson: Applications should be designed for scale from the start. Global accessibility and consistent performance across geographies should not be an afterthought. If the tool you select or build does not support your scalability requirements, it will be a failure regardless of how well it works. Consider a more modern architecture and leave the three-tier apps behind.
As Bob Dylan wrote, "the times they are a-changin'" — and one thing I'm glad about is that in this past year I've finally begun catching up with the times. I know big companies usually have large enterprise IT organizations that always seem to have a stigma for being behind the times. Well, here's another quote for them from German author Eckhart Tolle — "awareness is the greatest agent for change." If you're trapped in an organization like the one I was in, don't wait for your future self to travel back in time and educate you. Educate yourself now and start changing the way you do IT.
It's been three weeks since I began my Product Manager position at CenturyLink Cloud, and it's been a great experience so far. I've learned so much already and am really enjoying my continuing journey from the enterprise IT world into the cloud computing space.
The most frequent question I've gotten from all of my family and friends since I took this job has been, "So...what do you do?" Of course, when I was working in IT at my previous job, my answer was often just, "I work with computers." I imagine they pictured me helping people fix their computer problems like Jimmy Fallon's Nick Burns character from SNL. With this new job, it seems to have become even harder to describe what it is that I do as it seems people often have no idea what the "Cloud" really is or what a product manager does. In fact, even when I accepted the position, I had only a rough idea of how exactly I'd be spending my time on a daily basis. Thankfully, it hasn't taken me too long to figure out. While I was up in Seattle meeting the team last week, we had a very productive discussion about precisely this topic.
As product managers, what exactly do we need to know and what are we actually responsible for doing? First, it's important to understand what we need to know to be an effective product manager, and we learned that there are three key areas of knowledge: product, market, and accounts.
What a Product Manager Knows
Product. Of course, product managers need to know all about their product. I mean, it's in their title — if we don't know the details of the product we are managing, we can't rightfully be called a product manager. This means we have to be intimately familiar with all of the features of the product, including how they work and how to use them, as well as why they were designed a particular way. It also means we need to have some sense of the product roadmap, ultimately being aware of what features are on the near-term horizon as well as at least a broad understanding of where the product is headed over the long term. In the case of our team, this includes all products in our portfolio (though I've heard some teams have product managers assigned to individual features or to one specific product within a portfolio).
Market. In order to help us develop our product roadmap and also better understand how our features compare with those of our competitors, we have to stay aware of what's out there in market, what the industry trends are, and where there are gaps, both in our product and in the market in general. For our team, this means keeping up with all the news that's out there about cloud computing — competitor press releases, thought leaders blogs, research articles, white papers, presentations, anything that will let us gain insight into who is doing what with cloud services and where the technology is headed. This means reading...a lot. I've already discovered that consuming so much content and determining what is important to retain can be pretty overwhelming. Luckily, I've found that using services like Pocket, Flipboard, Feedly, and Evernote really help me to track lots of information, glean what's important, and save it for reference.
Accounts. While it's helpful to see what our competitors and others in the market are doing, there is perhaps nothing more valuable than understanding what our customers are doing with our product(s). Keeping up with the end users is an important part of a product manager's job. Having regular calls or meetings and just maintaining a positive and open relationship with users is a great way to do this. While end users will likely have a relationship and regular interactions with a sales representative or account manager, making sure their channels of communication are open with the product management team as well can make a big difference here. I think this is probably the most challenging of the three knowledge areas to keep up with because it requires such active participation and frequent communication with end users.
Okay, so a product manager has to know a lot...now what do we do with all of this information?
What a Product Manager Does
In general, a product manager does a lot of information sharing. All of that knowledge we have about the product, market, and accounts, we have to share with various audiences who are interested and need the information to do their jobs. This includes internal evangelism where we need to help others in our organization understand what our products are, how they work, how they are evolving, and why we are (or aren't) building a particular feature. It also includes public engagement as well — talking about our product, or even our industry in general, on social media, in publications, and at conferences. It's about promoting the product both within the company as well as to the broader community, and since we know the product better than anybody else, what its place is in the market, and how our customers are using it, we are often in the best position to do this.
What I've found most interesting about the product manager role is that it seems to sit right in the middle of so many key functions within an organization. In the case of our team, we are part of Engineering and already work closely with the developers, but we also have to interface very frequently with Operations, Marketing, Sales, and even the end users. Ultimately, all of these various groups are our customers. In order to help gain all of that knowledge we need, we need to interact with all of them and keep them engaged and as happy as possible. This can prove to be a difficult task, of course, given all of the competing priorities.
Given that we sit in Engineering, perhaps our most important job functions include backlog management and sprint planning. It is the product management team who is primarily responsible for determining if we are going to build a feature, and when we are going to build it. In other words, it doesn't get into the product unless we say it does. Of course, we look to all of our customers to help us make the determination, but the decision is essentially ours.This may result in some healthy debate as part of the planning process, and so it helps to be armed with facts (what we know) to support these decisions. If a developer is curious about why we have to build a feature, it helps if we can say something like "all of our competitors are doing it" or "our top five clients asked for it." Conversely, if an end user asks why we don't have a feature, it's nice to be able to say "we are working to get it into the product soon" or "we will never be able to support that because it doesn't fit with our vision of the product" or even "have you thought of using this other feature instead to accomplish the same thing?" Sometimes we may even do some feature prototyping first to help understand what to build and how it might work.
Along with our engineering team, we need to support our sales and marketing folks as well. We may do some more thorough competitive analysis, not only to help us determine what to put into the product, but also to help them better understand our specific value proposition or what the differences are among the feature sets in the market. In the case of our team, we are also tasked with product definition as well as potentially helping to determine product pricing. This means that we have to work with Finance, Operations, Engineering, and others to find out what it will take to add products to our portfolio so we can figure out the specific details of what the product will look like when it goes to market (i.e. what are specifications, prices, features, value proposition, etc.) Additionally, we may be called upon to help with sales support if there is a need for some deeper technical knowledge to help win over a potential customer. It also falls upon the product managers to take responsibility for analyst briefings and make sure they have all the information they need to accurately reflect the product offerings in their research papers and market analysis. (CenturyLink Cloud was recently recognized by Gartner in the Magic Quadrant for Infrastructure as a Service.)
Finally, let's not forget that there is also the need to continually engage with the end users, not only so we can gain insight into how they are using the product and what features they are interested in, but also to keep them informed on what's coming, as well as helping them get as much as they possibly can out of the product. This can be achieved by writing release notes, knowledge base articles, and keeping them up to date with customer briefings.
One thing I've heard from multiple people is that being a product manager is hard. I'm definitely starting to see why, as there is so much to know and so many decisions to make that have a real impact on all of our customers. I'm up for the challenge, though, and excited to continue to learn and develop all the skills and knowledge necessary to be a great product manager and contributing member of our product team.
When I was hunting for my first career job as I was winding down my college years, I remember suiting up (though this was a couple of years before How I Met Your Mother aired, so that term may not have been around yet) and going on some interviews offered at the Cal Poly career center. I got through to the second round for two of them. One was for St. Jude Medical in Sylmar (where a few of my Cal Poly Engineering brethren ended up working for a time), and the other was for Amgen in my hometown of Newbury Park.
The entirety of my experience with Amgen at the time had been the lectures that I attended at the conference center there to earn extra credit for my 9th grade biology class. It seemed strange to even consider working there. I figured with my computer science degree, I'd end up in the Bay Area working for some major software development company, or maybe I would join a small startup and get to work with some really innovative, cutting-edge technology or something. I never imagined I'd take a job working in information technology at a large biotech company. Let alone basically going back home to do it.
And yet, as hard as I tried to stay away, there was something appealing about being close to my family, having the kind of benefits that Amgen offered, and still getting to work with technology in some respect. Sure, I wouldn't be flexing my programming muscles as much as I would at a Microsoft or a Google, but it would still be a great opportunity to learn and grow. It's not like I was going to be there forever.
Well, I wasn't...but it sure felt like it. Today will be my last day at Amgen after nearly eleven years, six positions, eight bosses, and only three previously used laptops. On Monday, I start a new job at CenturyLink Cloud as Product Manager. Though based in Seattle, I will be working remotely from a home office and traveling up there occasionally to check in and be with the team.
This is a pretty big change for me, both from a career and also a lifestyle perspective. It honestly wasn't even something that I was actively looking for at first. But when presented with the opportunity, it became increasingly clear that it was going to be virtually impossible to pass it up. Though I've been very happy at Amgen, particularly in my latest role there, I have watched the company over the past few years and seen it progressively enter a place where technical skills aren't as valued as they used to be and the thirst for innovation is hard to come by. I've successfully navigated a number of job changes there that all helped me grow and learn so much, and I'm extremely grateful for that. But I like to be able to see the next job that I'm going to take, and I just started having trouble finding it at Amgen.
Thus, when the possibility of joining a high-performance team in a more tech-focused space was pitched to me, hard as my risk-averse self tried to ignore it and stay in the comfort zone that is Amgen, my desire and thirst for something new and different ultimately won out...and I could not be more excited to get started. The real challenge is going to be trying to explain to my daughter that Daddy is still "at work" even though he's physically "at home" also. That, and getting work done while hearing Frozen playing in the other room. But I'm looking forward to it.
favorite definition to use now when describing the cloud is 
Sticking with the theme of four letter acronym definitions, 
