Photo by Author in Provincetown, MA
I am a person of first principles. I like to take basic concepts and use those ideas to give me a way to behave. Attending "AWS reInvent 2018" in Las Vegas gave me a glimpse into the AWS culture. It resonated with my values as an Engineering Manager and inspired me to want more as a technical leader.
AWS Culture
This year, I earned AWS Solutions Architect, Professional certification. I wrote an article about it on Medium, and it is my favorite:
The AWS Architect Exam is a Marathon
Every day, I use my most lucid hours - early in the morning - for writing and delving into deep technical concepts. In this blog post, I give my testimony on the AWS Leadership Principles.
Customer Obsession
As an engineer, I love releasing features for my customers. I like seeing the challenges they face, and I enjoy interacting with people as they describe their business needs. It's a very human thing to want to feel needed and to contribute to the experiences of others. Awakening to the technology of the cloud gave me tools to address problems that were beyond me before.
Ownership
I find ownership of technical applications runs in two dimensions. My first taste of ownership in any new thing I build starts with the code. I write code to be excellent from a design and readability perspective and achieve the desired result. I also want to own what I do from the operational perspective. The end-to-end ownership of DevOps gives me feedback loops that let me take applications to the next level.
Invent and Simplify
I would argue this principle should be "Simplify, Invent, then Simplify." Back in my days as a mathematician, we had a saying on proofs that, "The first proof is the ugly one." If we do invent something, chances are, some aspect is less than perfect. So I simplify my solutions after first proving they are correct before releasing them into the wild.
Are Right, A Lot
I start every day by solving chess puzzles. Chess puzzles are a good litmus test for quick decisions. You have to look the board over thoroughly, think about the consequences of several possible moves, and pick one. I start decision-making by choosing a good decision and then think hard if there is a better decision.
Unless it is urgent, I never make important decisions late in the afternoon. A quick meeting is an excellent way to start the decision process if someone is pushing for a decision. Still, a better method is a brief meeting to get the facts (look at the board), wait overnight (let my brain think), meet again in the morning (accumulate the thoughts of the team), and then decide.
Learn and be Curious
My learning style is: I see, and I forget, I hear, and I remember, I do, and I understand. My learning is writing this blog and developing code.
I learn by writing. An obscure personal blog gives me a level of privacy to write publically and learn about new topics and myself. I organize my learning with Trello and checklists.
Hire and Develop the Best
One of the best compliments a colleague gave me was saying that I have a natural eye for talent. I was joking with my kids about how their teachers will brag about former students and their accomplishments. As if the valedictorian earned their achievement because of you, a 7th grade English teacher. However, with teachers in my life who changed me, maybe they did. I certainly owe my successes to individual teachers and career success to mentors - senior, peers, and direct reports. The best make everyone better, and I strive for that.
Insist on the Highest Standards
A development team should have a "Zero Defects" policy. Much of my daily development work focuses on preventing defects, writing tests to discover flaws. For every problem in production, I always organize my team to do my favorite Root Cause Analysis - the 5 Whys.
High standards also apply to behavior. I have always loved the Philosophy of Immanuel Kant. It formulates ethics with precision worthy of a software engineer.
Act only in accordance with that maxim through which you can at the same time will that it become a universal law. -- Immanuel Kant,
Think Big
I love mission statements. Any project I own gets a mission statement and a big goal. I've done some unique things because I dared to think I could. I founded a Fencing Club. I was a crucial founding engineer of Retail Solution Inc, which is now a part of IRI. I'm very proud of both of those accomplishments. When I focus on doing something big, I keep in mind the overall goal and develop something I can do every day to get to that goal.
Bias for Action
When I was studying for the Solutions Architect exam, I liked the concept of "two-way doors." I believe in spending time upfront to make sure you can undo a problem quickly and try a new solution even if it may not be perfect.
Frugality
I pay for my AWS account and a Snowflake account. I scrutinize every charge on both. The process of knowing exactly how much every operation costs teaches me about each service. I ran a 4 million a year budget for a health care company and worked on a team that budgeted team costs on mergers and acquisitions. I saw firsthand how frugality at the budgetary level is complex, and frugality without study is foolish.
I love Italian clothes, and they aren't cheap. Sometimes I choose to spend more on things that make me happy. I like to buy the best I can afford and take excellent care of it.
Earn Trust
Earning trust is an exercise in Emotional Intelligence. One of my favorite books is Emotional Intelligence: Why it can Matter More than IQ by Daniel Goleman. Trust is fundamentally a social contract: it binds together honesty, respect, kindness, and empathy and forms a feeling between myself and my colleagues. For that reason, I value emotional intelligence in myself higher than any technical competence I have.
Dive Deep
As an engineer who rose into leadership roles, I had the advantage of starting with deep knowledge of the missions of the teams I managed. I also struggled with diving too deep when my team's mission became very broad. As I have progressed, earning trust in myself and not being insecure, I have learned when to dive deep and focus on the big picture - the quarterly goals versus the sprint goals.
In problem-solving, I use the method I learned as a math bum. If I can't solve a problem, I find a precursor problem to solve. If I can't solve that, I simplify again until I solve the problem, then work my way back.
Have Backbone; Disagree and Commit
If someone disagrees but stays silent, I wonder why. Does the person not trust me enough to speak their mind? Do they not respect me enough to be transparent with the truth. As an engineer, I want a lively discussion when there is conflict. I will say what I think and will not facts or my beliefs. I will also embrace the group decisions when the debate is over.
Deliver Results
When I have a project, I write out the overall vision, then work out individual tasks. I work best when I deliver multiple incremental results toward a goal. Even before agile was a buzzword, I focused on the release. We called it "lightweight" back then, and it meant putting something good into the customer's hands to use.
Comments