Tuesday, June 02, 2015

Dominating your career trajectory

Here's a copy of a note I sent out to my team @ VMware about continuous learning and being responsible for your career trajectory. 

I was having a conversation with one of the practice leads today about a potential new hire. I caught myself saying, "The candidate looks like a Chef/Ruby engineer. Are you sure that the person is willing to grow with us?" It led us to a discussion about how we need to equip our team for the next era of computing. With that in mind, I've assembled my list of twenty things that I think our team should know at various levels. Principals should know all of them; consulting architects should know the vast majority, and so on. With that, my list is as follows:

1.       Be able to explain map reduce, the implementation choices and use cases.
2.       Be able to explain the importance of CAP theorem, and examples of databases that have taken an opinionated approach.
3.       Be able to compare and contrast the differences between virtualization and containers.
4.       Be able to describe the core elements of Microservices and give examples of implementation technology.
5.       Be able to articulate the characteristics and importance of an idempotent service.
6.       Be able to explain how SDN and NFV complement and compete.
7.       Be able to explain block chains and their importance and usage in distributed systems.
8.       Be able to compare and contrast the two major consensus algorithms used in distributed computing and give examples of available implementation libraries.
9.       Be able to discuss the features & design tradeoff's of Google Bigtable and Amazon's Dynamo.
10.   Be able to describe open compute / open hardware initiatives, their goals and examples of available offerings.
11.   Be able to describe the purpose of a fault-injection framework and examples of where and how they have been successfully used.
12.   Be able to describe the elastic scale in/out pattern used pervasively in the Amazon cloud.
13.   Be able to describe the effects of container technologies as it relates to MTTR and overall high availability.
14.   Be able to describe the primary technical components found in a cloud native architecture.
15.   Be able to compare and contrast the PaaS offerings from Pivotal, Microsoft and Red Hat.
16.   Be able to describe all of the major steps in Continuous Delivery, and most common implementation choices in each step.
17.   Be able to discuss the most popular open source licenses and their advantages/disadvantages.
18.   Be able to discuss UI design concepts such as Material UI and Responsive Design.
19.   Be able to discuss modern engineering methods and architectural approaches in detail (e.g., Scrum, BDD, 12 Factor App, etc.)
20.   Be able to discuss the role of distributed computing cluster managers and schedulers, and examples of their usage.
I'll admit that this is a big list for even the most accomplished consultant. The observant reader will notice that the primary themes are distributed computing and modern approaches to software engineering and architecture. As the industry continues its aggressive move toward commodity gear, cheap middleware and fast-fail-fast-recover software, we need to be in a position to advise our clients on new tools, platforms, approaches and the business case. A sea of change awaits our clients and we will be called upon to lead them to the next phase of computing. In some cases our employer will have products that solve the problem, and in many cases we'll need to knit together solutions from the greater hardware & software ecosystem.

Again – this is my list, not the practice leads; I'm confident that they have their own ideas. I wanted to get my view in front of all of you to consider areas for capability development in 2015 and beyond. Of course, many of you have assignments right in front of you that require learning. My recommendation is to be careful not to get lost in the specifics of some product or technology and lose track of the greater change that is occurring. Each of you must dominate your career trajectory. Own it; be its master, not its victim. Learn deep; learn wide; it's not an either/or choice. Rely on your practice leads to help, or me if you feel I can, but ultimately lean on yourself.


Jeff Schneider, Sr. Director Professional Services, DevOps & Open Cloud