VP of Emacs is a blog series about using Emacs as an essential tool in my job as the VP of Software Engineering at Carbon Lighthouse. I’m a software engineer trying to cut it in a job that has required me to be more organized, communicative, strategic, and personal than ever. Emacs helps me get more done and keep it all connected. It has become the application I use every day to unify note-taking, emails, task management, writing, programming, and more.
This edition is a step back from Emacs and the details of my configuration. I wanted to talk about what my job is and how I approach it. I believe it is important to know what I’m trying to achieve and why, before a tool, even a tool as versatile as Emacs, can be used to its full potential.
People, Process, System, Strategy
A technical advisor of mine shared these four aspects of the VP of Engineering role with me, People, Process, System, and Strategy. When I heard them laid out like this, it resonated strongly with me. In a startup environment, the work of the VP role is often oscillating between developer, architect, product manager, coach, counselor, strategist, and diplomat. This should be expected, because the small team needs its leader to cover their gaps and be the glue that keeps things running smoothly. It is exhausting, though. At any given time, it is going to feel like one or more of these aspects is on fire. Even though they are all essential and important to the organization’s future success, they can’t all be equally important at any given time. I strive to be honest and forthcoming, both up and down the chain, about why I’m intentionally letting one aspect slip in order to focus on the others.
People
Supporting, hiring, and growing the skills of people in a software organization is essential for high performance. As a leader, I support people and I direct culture. My job is to provide an environment in which leadership, cooperation, accountability, and learning flourish. The behaviors that lead to better software for customers, and a lower cost of change, need to be the default behaviors of the organization. If doing the right thing can be easily resisted, it will be resisted. It’s my job to define what the right behaviors are.
Process
In every software company, there is a flow of work from idea to delivery. The production pipeline for code and the mechanisms of daily operations, are what I call “process”. Building a production pipeline can be as complex or more complex than the technological system and architecture it delivers. The organization’s lessons need to be constantly fed back into its process. Making sure the flow of critical information is present between the executive level, and every individual software engineer. When the executive level makes a shift that is out of step with reality at the engineering level, it is process which must amplify a feedback signal. Similarly, it is process which must ensure that what the engineers are doing is continually adjusting toward the strategic needs of the business and its customers.
System
The system is architecture, frameworks, tools, automation, infrastructure, and monitoring that must all work, and work well, in order for the team to build something customers continue to use. A technical leader needs to do more than understand the system. They have to guide and inspire change in it that leads to meaningful improvements in stability, malleability, velocity, and impact. Occasionally I do code-level spikes to understand, question, or measure what is good and bad about what we’ve already built or to discover new paths forward. People trust leaders who have done their job, or could do their job. If I lose touch with the work, I lose credibility too. There is a fine line here though, to not step over and do things that should be carried to completion by the team.
Strategy
It takes a lot to figure out the above three items, but it’s not enough. In this role, I’m the person that must be looking ahead to where the organization needs to go. Is there a business change coming soon that will require drastic changes? What are the next important improvements to make, and how do we sequence our growth to be where we want to be in 2 years time. What’s truly important? How do you communicate it and educate every person in the organization so they know it, feel it, and can act on it with intent?
Managerial Economics
- I can’t go do all the things I want done, I have to bring others into my reasoning and empower them to carry it out in their own way.
- Everything I do, that someone else could have done, was something I overpaid for while also robbing the team of a learning and growth opportunity. Double loss.
- 80% of the work is done by 20% of the team. This means high performers, not low performers, should receive the majority of my focus, coaching, and guidance.
- Efficiency is accomplishing higher output with fewer resources. Productivity is doing more valuable work in the same unit of time. Delegation to the edges of the organization is what drives every member of the organization to focus on valuable work, while also increasing their capacity.
Hiring & Recruitment
Hiring well is the most important responsibility of any manager. No hire is ever perfect, but a bad hire can be truly catastrophic to culture, communication, and productivity. I could write an entire blog on this subject, but here are my brief guiding principles on the subject.
- Don’t hire, delegate more.
- Okay, you’ve decided to hire. Define the role, as well as the skills and behaviors that are necessary to perform in the role exceptionally.
- Build your hiring and interview process around finding reasons to pass on candidates, not reasons to hire them.
- Design your interview to investigate past behaviors and simulate the work of the role. There is no better predictor of future performance, than past performance.
How Emacs Helps
Emacs is my tool for thought and data gathering. It forms the connections between my ideas and lets me recall them when I need them. My org mode index/inbox file is where every task I need to keep on top of lands by default. Org-agenda reminds me of things I deferred and helps me prioritize. Working in a single app affords me the advantage of doing less context switching and having higher integration between my notes, tasks, and email. I enjoy the freedom of being able to evolve my system of work, limited only by what I can configure or write in elisp. Most importantly, Emacs makes the work more fun because I enjoy using it.
More in this series
VP of Emacs series
Thanks for reading. Please get in touch if you want to talk about engineering and leadership in your role, I’m happy to lend my perspective and learn from yours.