DEV Community: Israel Carberry

Dear Manager of Managers (The Revised Version)

Israel Carberry — Mon, 18 Jul 2022 00:27:46 +0000

Dear manager of managers,

I may or may not be interested in your open position for engineering management. Let me be more precise. The model of the manager you intend to hire that currently lives in your head is simply that, a creation of hope and imagination. That image is good to have, and sets a course for your search. Like all mental models, however, it can only represent a perception or expectation of reality, not reality itself. I am not that manager. Chances are good that neither is anyone else.

In that context, I may or may not be interested in attempting to prove myself to be exactly like the manager in your mental model. Chances are just as good that you or your organization don't want that, either. By holding strictly to that expectation, you could be missing out on a range of skills, experience, and ways of thinking from any number of candidates that don't live up to the manager in your mind, yet might very well satisfy your needs and exceed your expectations.

Let's explore what you are likely imagining, and I'll tell the story of the manager I believe I am now. Perhaps then we can find alignment on the manager I could be for you on day one, ways of addressing the immediate and long term needs you are intending to solve by hiring an Engineering Manager, and a shared direction for continuous improvement.

Qualifications You Are Likely Prioritizing

I've been on the hunt for an Engineering Manager role for a while now; I have seen a variety of requirements and nice-to-have's in job postings, and have uncovered as many unstated expectations through interviews. In the aggregate, these reveal that what is generally meant by "Engineering Manager" is "A Clone of Our Best Staff Engineer Plus Some People Skills".

Based on this definition, when I'm stacked up against the handful of other candidates who have also reached final interviews, the deciding factor is often that one of the other candidates is "slightly better at" or "has more experience with" some specific technical operation. That could be a particular code language, a specific infrastructure stack, or a modern engineering process ~~religion~~ ritual.

Interview Intent and Design

We should pause here to consider what interviews for this role are attempting to accomplish. I have experienced a significant number of interviews, on both sides of the table, that could be considered successful except that whatever was accomplished had little to do with either competency for the role or culture fit.

Interviewing is challenging, and I have conducted my share of less than ideal interviews. I have made candidates uncomfortable, have wasted both our time, and have delayed when I should have acted. By critiquing those who have interviewed me, I'm putting myself in their shoes, and trying to learn the less hard way myself. I have attempted to learn how to better design and react during an interview, whichever side of the table I'm on, to maximize for what I believe is the intent of that specific interview.

Why, then, are technical qualifications such a deciding factor so often for an EM role? Does the company lack senior levels of engineering talent? This need for the EM role to wear the tech lead or principal engineer hat is common at small companies and startups. Is that your org? Or the concern may be credibility as a leader. Is any decent senior level experience enough to secure that respect? Or does everyone on the team absolutely need their manager to be the smartest person in the room?

There are no right answers to these questions. They will, however, have a huge impact on the direction of your interviews. Are technical contributions by this role critical to your business? Or is the management role solving other priorities, such as process transformation, employee retention, performance accountability, or some other elephant in the zoom call?

Disparities Between the Role and the Qualifications

In one memorable case, I took the lead on every interview, and guided the focus of the conversation with each interviewer, including the director who would be my boss, senior engineers who would be on my team, a product manager with whom I would be coordinating, and a c-level something or other to whom I would be indirectly reporting. Each of these individuals arrived at the conclusion that the primary need I would be solving was communication - visibility, clarity, and alignment - up, down, and sideways.

The result? A rejection email arrives in my inbox offering feedback (an appreciated rarity in rejection emails), which turned out to be that I just didn't have enough experience firing engineers. I'll let you ponder the layers of disparity there; it's okay, take your time…

To be true to what was stated, it was about confronting poor performing engineers with accountability. I'm extrapolating that out to the ultimate threat that is the undercurrent in all those conversations, even if only because that is what the poor performer thinks of first. The times I have had those conversations, a mutually happy direction and commitment for improvement was reached. Termination was necessarily brought up, but only to communicate that we were nowhere near that, and that it would be discussed early if it did become a concern.

But I digress. The disparity throughout the series of interviews was such that a single immediate need that the hiring manager wanted (understandably) to find help in addressing dwarfed the greater dysfunction across the company that the role was also intended to address. If the latter was resolved as the top priority, how might that have impacted motivations and incentives for those causing the former? Might there have been other hardships and roadblocks frustrating those who would otherwise shine in their work that were as yet uncovered? I'll likely never know, yet I've faced this enough to know that poor performance is rarely as simple as a case of the lazies with a one step solution.

This is but one example of many disparities between what was advertised, what was discussed throughout the interview process, and what was ultimately the deciding qualification that manifested as a rejection of my candidacy. Let's make a stab at mitigating future disparities should we meet in an interview; I'll give you my take on the role, nuanced as it may be in your particular situation, and then we can take another look at qualifications.

The Role

My take on the role of Engineering Manager is that I am ideally focused all day every day on lean process improvements, one on one coaching and career discussions, value stream flow, value delivery and observability, aligning product + engineering + security + infra + ops + compliance + business, reducing risk, leading long term change, guiding collective rethinking, recruiting and hiring, continual monitoring of psychological health and safety, and encouraging a culture of learning.

Are there times when an EM should shoulder technical work? Again, that depends on your org or the needs of the team. Given the ideal, that is always a tradeoff. It may be freeing someone else to complete another priority task, but more often than not it removes as much or more value than it adds. Any task that shifts my focus to solving problem X with technology Y as an individual contributor is detracting from my ability to do what I see as my job. Am I willing to reprioritize to meet immediate needs of the business and my team? Of course. If it becomes a pattern or habit, however, that is a clear signal something else is out of alignment, which implies a deeper solution.

Rethinking Qualifications

If the picture of the role that I am painting is more in alignment with the business need you are hiring to solve than can be met with a more technical lead, what qualities are you really looking for? What will be the deciding factors when choosing one candidate over another? How can they be demonstrated in an interview? How can they be measured, analyzed, compared? Again, these are challenging to consider, and there are no right answers.

The skills that I bring to this role involve the ability to build trust with many personalities, systems thinking, story telling to reveal what could be, tactical questioning to guide and discover solutions not my own, communicating complexity for clarity, applying mental models and knowing when to discard them, crafting conversations and decision frameworks, using silence, choosing and interpreting measures, balancing empathy and accountability, identifying incentives, celebrating the successes of others, turning failures into learnings, and understanding the customer. To name a few. And always maintaining what is best for the business is the thread that runs through them all.

Should I be technically savvy and conversant? Of course. Should I be determining the specific X for deploying microservice Y? Probably not. Rather, I should be asking tough questions of the engineers, product owners, and designers to make sure their exciting and shiny new trees will help the forest grow. I should provide context that isn't easily visible about downstream impact or mission alignment. I should bring in other stakeholders with whom I've invested time building a foundation of trust. And... and... and....

Do I know anything about React? Sure, I spent a couple days playing around with it, and have a very broken public repository on GitHub. Do I know anything about systems architecture? Some, enough to contribute to discussions with engineers who live and breathe and implement such things. Do I give two shakes about React? Or Ruby? Or Java? Go? PHP? TypeScript? K8s? Azure? Jira? Dynamo node replication and failover configurations? AWS / GCP Thing One? Thing Two? Nope. Well, only in the sense of does this technology bring value to the end user, execute on the mission, and benefit the business.

Whatever the tech and my personal experience with it, or lack thereof, can I lead a team of _______ engineers? All. Day. Long.

Back to the Beginning

Now we arrive where we started (a good hero's journey storytelling move). Do our goals, aspirations, and assumptions regarding the Engineering Management role for which you are hiring align? Has this inspired any rethinking? I hope so, even if you have arrived at the same perspective you had previously. Does this reveal an alignment between what I bring and the gap you're hiring to fill? Or misalignment such that neither of us would be satisfied? Either way, I hope this serves your choice whether or not to invest time exploring that fit further with me.

This is the revised version of this article after receiving a lot of great feedback from Plato mentors and amazing folks in Rands Leadership Slack. I present both on the off chance a reader is interested in analyzing how I’m able to receive and act on feedback, given the purpose of the article itself.

Dear Manager of Managers

Israel Carberry — Fri, 01 Jul 2022 03:39:12 +0000

I may or may not be interested in your open position for engineering management. To be more precise, the model of the manager you intend hire that currently lives in your head is simply that, a creation of hope and imagination. I am not that manager. Chances are good that neither is anyone else. In that context, I may or may not be interested in attempting to prove myself to be or even willing to become like the manager in your mental model.

Let's explore what you are likely imagining, and I'll tell the story of the manager I believe I am now. Perhaps then we can find alignment on the manager I could be for you on day one, and a direction for mutual continuous improvement.

Based on this definition, when I'm stacked up against the handful of other candidates who have also reached the seventh interview, the deciding factor is that one of the other candidates is "slightly better at" or "had more experience with" some specific technical operation. That could be a particular code language, a specific infrastructure stack, or a modern engineering process ~~religion~~ ritual.

My take on the role of Engineering Manager is that I am focused all day every day on systems thinking, lean process improvements, one on one coaching and career discussions, value stream flow, value delivery and observability, aligning product + engineering + security + infra + ops + compliance + business, reducing risk, leading long term change, guiding collective rethinking, recruiting and hiring, continual monitoring of psychological health and safety, and encouraging a culture of learning. Any task that shifts my focus to solving problem X with technology Y as an individual contributor is detracting from my ability to do my job.

The skills pertinent to this role involve the ability to build trust with many personalities, story telling to reveal what could be, tactical questioning to guide and discover solutions not my own, communicating complexity for clarity, applying mental models and knowing when to discard them, crafting conversations and decision frameworks, using silence, choosing and interpreting measures, balancing empathy and accountability, identifying incentives, celebrating the successes of others, turning failures into learnings, and understanding the customer. To name a few. And always maintaining what is best for the business is the thread that runs through them all.

Should I be technically savvy and conversant? Of course. Should I be determining the specific X for deploying microservice Y? Good grief, absolutely not. Rather, I should be asking tough questions of the engineers, product owners, and designers to make sure their exciting and shiny new trees will help the forest grow, and bringing in other stakeholders with whom I've invested time building a foundation of trust, and... and... and....

Do I know anything about React? Sure, I spent a couple days playing around with it, and have a very broken public repository on GitHub. Do I give two shakes about React? Or Ruby? Or Java? Go? PHP? TypeScript? K8s? Azure? Jira? AWS / GCP Thing One? Thing Two? Nope. Can I lead a team of _______ engineers?

All. Day. Long.

This is the first draft of thoughts that had been brewing for a while, and the revised version is here. This draft coalesced at a coffeeshop after a fantastic conversation with a newly met fellow engineering manager. He was facing the same frustrations after being hired into the role for the first time.

Feedback on this draft was solicited from mentors and colleagues in my network, which is paraphrased and summarized as follows:

Realistic but idealistic to expect EMs to only focus on people management and for interviewers to be awesome
Sounds like you’re opposed to adapting to the needs of the team
Intent is unclear - commentary on hiring practices, your hiring experiences, your view of the role, or the type of job you’re not interested in?
Overwhelming impression of anger and hubris, pretty sure not your intent
All engineering leaders should strive to remain connected to the work, so you can continue to connect with the people you’re managing
The best EM’s are engineers who become leaders
EM’s deal with less than ideal situations much more than an IC does, and should be willing to do whatever is necessary
I hope your future boss doesn’t read this
Your lists of priorities and skills are two or more steps away from results, and not everyone will see the connections and value - a hard sell
Titles and positions are vague, and expectations and competencies for a role can vary, depending on size or state of the org, defined by business need
Non-technical management has been rejected generally, and technical credibility is important

Engineering You

Israel Carberry — Fri, 30 Apr 2021 14:51:22 +0000

You’re comfy in your cubicle ¹ or safe and well at home ²
Poking keys and making memes and engineering code
When an email To: You ³
From: your manager, Sue
Flies flapping out of the blue,
“Congratulations, you’re promoted! You’re now a leader too!” ⁴

“I don’t need this,” you mutter, in a tone so dark and bitter ⁵
As you seek for empathy from your followers on Twitter.
Among the literal sighs ⁶
One calm succinct reply ⁷
Catches your twitchy eye
“You’re a great engineer so engineer you, and you’ll be fine!”

“What a neat perspective,” says you while thumbing Like,
“A truly epic case of self improvement I will write!”
You make a list or two ⁸
Of general things to do
Thus is born Project You
As you swear to make the best of this challenging snafu.

You search every keyword, watch all the webinars, ⁹
Add every mentioned book to your growing TBR. ¹⁰
“Manage people this way!”
“Be mindful what you say!”
“Respect mah authoritay!”
Battles rage over how Leadership should be portrayed. ¹¹

You start to experiment with the team that you now lead ¹²
But is it really work if it’s not engineering? ¹³
“I’m such an imposter!”
“Should I be on the roster?”
“I’m feeling lost and loster…”
You spiral into the dark like a Kuiper Belt space lobster. ¹⁴

You slowly feel more settled as ideas coalesce ¹⁵
Working more in the ethereal and coding less and less
You network with peers ¹⁶
And grapple with fears
The fog starts to clear
Mentors join you on your journey to challenge, guide, and cheer. ¹⁷

What is most important? Is it increasing velocity? ¹⁸
Improving culture, the value stream, or productivity? ¹⁹
Hunt for the constraint!
Empathize! Evaluate!
Metrics cogitate!
You juggle initiatives, get feedback, and slowly iterate. ²⁰

Out of the murk and muddle, results begin to form. ²¹
Feeling safe and failing fast is now the new team norm. ²²
You see people grow ²³
Faster flows the flow
Hardship is trending low ²⁴
Dunning-Kruger kept in check with a bit of imposter syndrome.

“My! How you’ve grown!” beams your manager, Sue, ²⁵
As a warm glow radiates from your performance review. ²⁶
“You’re empowering your team
The pipeline is growing lean
Consider now your own journey
What will you do when it’s you having leaders to lead?”

So now you’re helping others wherever they may be ²⁷
Giving talks and writing blogs and zooming with mentees
The path has been a struggle
Worth each gripe and grumble
New challenges attainable
Poking keys and making memes and engineering people.

There are a bunch of footnotes. Gobs. Oodles of them. If this is your first time reading through this, ignore these, please. Enjoy the story! Come back around to catch all the snark on a second pass. These will still be here. ↩
(See? Told ya.) Hero’s Journey: The Ordinary World - Throughout this piece, I’m annotating the milestones of the Hero’s Journey storytelling framework as they are encountered (of which there are a gazillion references, of which the one from the Reedsy blog is a personal favorite, the headings of which I quote here). Storytelling is a significant skill in a manager’s toolkit, for use in guiding those on your team as well as in driving initiatives in the broader scope of your company. A great book on the topic is The Storytelling Edge by Joe Lazauskas and Shane Snow. ↩
HJ: The Call of Adventure ↩
Forbes quotes a CareerBuilder.com study to say a lot of people are promoted into management because they’re good at what they do, not because they are good at managing, and then aren’t given any management training (e.g. your’s truly). I couldn’t find that study, but did learn that searching https://press.careerbuilder.com/ reveals a glut of studies to quote in one’s up-management status reports. Only, please don’t be like Forbes; link your sources. ↩
HJ: Refusal of the Call ↩
This is a literal (and actual) correct use of the word literal. Hat tip to the pedantists. ↩
HJ: Meeting the Mentor ↩
HJ: Crossing the First Threshold ↩
HJ: Tests, Allies, Enemies ↩
TBR = To Be Read. It’s that stack of squarish objects made from pulped trees that your wife thinks is a horrible waste of decoration space. ↩
Speaking of leadership and battles, even the US Navy has figured out that top down authoritarian leadership is counterproductive. Turn the Ship Around! by L. David Marquet is mind blowing. It will rock your boat. Blow you out of the water. Torpedo your presumptions … okay I’ll stop. ↩
Radical Candor by Kim Scott, and Sooner Safer Happier by Jonathan Smart. Yes, experiment, but don’t throw darts at the wall. The latter will give you the absolutely essential worldview to know where you’re going with trying new things, and the former will give you the mindset for working with your team individually without losing them or ruining them in the process. ↩
If you’re in engineering, and you haven’t yet read The Phoenix Project or The Unicorn Project (or both), either (preferably both) will blow your mind answering the question What Is Work and revealing the impact that management has Improving Work. The related technical guide is The DevOps Handbook. (The authors for these are, respectively, Gene Kim, Kevin Behr, and George Spafford; Gene Kim; and Gene Kim, Jez Humble, Patrick Debois, and John Willis.) ↩
If you’re a scifiavore, and haven’t yet read Accelerando, you’re welcome. ↩
HJ: Approach to the Inmost Cave ↩
This is an absolute survival necessity. Meetup.com is an easy first go-to. Online conferences are learning to host a community; the best ones have a dedicated Slack org or Discord server. Even companies are starting to get in the online community game (e.g. CTO.ai). ↩
Seek out a good mentoring platform, which your company may agree to pay for. Plato offers a lot of free content and public events, in addition to a fantastic paid program. Tupu is a non-profit mentoring platform, free to underrepresented groups in tech. ↩
HJ: The Ordeal ↩
The answers to these questions are in Sooner Safer Happier. I know, I already mentioned this above, but I can’t emphasize enough the importance of getting this book. If my job was my religion, this would be my scriptures. ↩
Call it LifeOps if you will. The principles and practices of DevOps (which, if you’ve already ordered Sooner Safer Happier like you should have by now, you’ll soon read are the tools to accomplish the goal, not the goal itself) apply to non-dev improvement as well. In other words, All The Things, hence: LifeOps. And that’s really what this story is all about. ↩
HJ: Reward (Seizing the Sword) ↩
There will be failures; if you aren’t failing from time to time, you’re not experimenting enough. For a mindshift from fearing to embracing failure, read The Obstacle Is the Way by Ryan Holiday. ↩
HJ: The Road Back ↩
A good roadmap for this transformation can be found in Engineering DevOps by Marc Hornbeek. Study the pillars, ways, and rubrics, and you’ll be able to pinpoint pretty accurately where your team or organization falls in that matrix. This can help you wield the tool of DevOps in the journey of continuous improvement as depicted in Sooner Safer Happier. Did I mention you should get that book too? You should get that book. ↩
HJ: Resurrection ↩
Remember how Sue delivered the promotion in an email? Horrid. Don’t ever do that. One on one talks are absolutely, existentially critical to managing, and an email like that should come as a follow-up to past conversations and as no surprise to anyone. We can hope here that this isn’t Sue’s first go at giving feedback, during a performance review. 1:1’s with direct reports should be as often as possible, never to be used as a status report, and the agenda should be set by the understudy (I’m trying to avoid Tayloristic words like “subordinate”), not the manager. ↩
HJ: Return with the Elixir ↩

Robinhood Rides a Phoenix and a Unicorn

Israel Carberry — Thu, 11 Feb 2021 02:51:38 +0000

In the seminal novel on DevOps, The Phoenix Project, the fictional guru character Erik claims that he’s “long believed that to effectively manage IT is not only a critical competency but a significant predictor of company performance”.¹ He then goes on to describe a hypothetical hedge fund that takes long positions on companies with great IT organizations and shorts those with failing IT. In the 2.0 version of that work, The Unicorn Project, that same Erik says to someone else in roughly the same timeframe of the story line that “middle managers are your interface between strategy and execution”.²

I devoured these books in May and June of 2020 as part of an effort to wrap my head around the delivery challenges we were facing in our engineering team. They have been instrumental in the transformation of our team culture and implementation of process changes. This is not a quick and easy path to tread, and even now, as of February 2021, we are only starting to see some small successes and breakthroughs. But successes they are, and they help confirm we are on a track of continual improvement.

Simultaneous to applying insights from these novels in my work life, I also took hold of the above quoted ideas, and decided to play the stonks game³ accordingly. As an engineering manager myself, I figured, I should be able to evaluate publicly traded companies using free, online platforms to ascertain the quality of their IT organizations.

I had long poo-pooed investing in the stock market, and felt vindicated in that stance with stories of entire retirement funds being wiped out by the dot com and housing crashes. I tuned out from any family gathering conversation that wandered into stonkyness. So I found myself needing a place to start. I remembered seeing a vlog interview of the Motley Fool founders, and had thought at the time, “these are the only people I’ve heard actually make it sound like it makes sense.” A few clicks and $99 later, I had Step One done; get good advice, check.

I also decided to approach this as a game, nothing more. I would only “invest” my spending cash as already budgeted,⁴ so if I made stupids, the cash was already “spent” in playing the game.⁵ This completely removed the money emotion from the equation, to be replaced with game play excitement or disappointment, and the stonks themselves are just in-game currency. That took care of Step Two; get perspective, check.

Step Three is the Erik Play. I put several of the latest Fool recommendations through my most amateurish analysis; Step Three A, look at each company’s list of employees on LinkedIn filtered by titles with the keyword “engineering”, and Step Three B, look at reviews by each company’s employees on Glassdoor.

Not surprisingly, the general consensus of Three B aligned with what I found in Three A. Companies with lots of Engineering Managers like myself, as well as Directors and VPs of Engineering, that had profile and job history descriptions that championed a culture of learning, empowerment of their direct reports, and a love for devops had, without exception, shiny reviews on Glassdoor. Likewise, those that exhibited pride in jargoned knowledge, specific tech stacks, and sacrificial heroics aligned directly with complaints on Glassdoor of toxic environments, high turnover, and general assholery. Step Three, do my own smartypants stuff, check.

I duckducked the available amateur trading apps, read some pros and cons and opined opinionated opinions, and eventually installed Robinhood. This choice really had no impact on the game;⁶ it has a decent HUD with dark mode, an intuitive weapons selector, and a solid inventory system.⁷ I’m sure other apps work just as well. I started putting in $25 to $30 every payday, picking just one stonk each time. Step Four, game on, check.

So far, not even a year in, I’ve leveled up with quite a bit of XP. I keep a list of recommended stonks I’ve turned down, labeled appropriately BMM (Bad Middle Management). I’ve also added other sources of advice, and picked a few stonks of my own liking. I don’t follow hype, don’t try fancy backflips or finishing moves, and so far have held on to everything I’ve picked up. A fun spreadsheet project tracks all my capital input, stonk amount and value, and gain or loss.⁸ This I only update on the weekend to see how I’m doing and plan my next move. Checking the app during the week is reserved for the end of the work (and trading) day, resulting in either an “Ooh, neat!” or an “Oh, that’s interesting”, but never ever ever a reactive game play.

There really is no Step Five. I’m playing the game, having fun. And so far, Erik seems like a pretty smart guy.

The Phoenix Project, 5th Anniversary Edition, 2018, by Gene Kim, Kevin Behr, and George Spafford, p. 335 ↩
The Unicorn Project, First Edition, 2019, by Gene Kim, p. 288 ↩
Absolutely nowhere in this article is any statement meant to be construed as investment advice. This is entirely anecdotal expressions of personal experience. ↩
I use Mvelopes, and highly recommend it to anyone. It’s the budgeting tool your great gramma used, upgraded from pulped dead trees to an app. It won’t bake pies, though. ↩
It was pandemic lockdown time. Who needs falafel wraps or new socks? ↩
It made for a clever title for this article, which is really the only reason I mention it. ↩
I’m being snarky and metaphorical here, duh. The point is, this is a game to me, remember? ↩
It also tracks crypto transactions, but that’s a whole different game with different rules. That has allowed me to see both together as a “portfolio”. I know, gross, using adulty words like that. The caveat here is that when I put in cash I specifically planned to take out again a short time later, a jump in crypto meant I could pull it back out entirely from there, leaving the stonks bought with the original cash as entirely “gain”. But that’s another game map, irrelevant to the main thread here. ↩