Hello, I’m Jim
20240604
This is meant to reduce your anxiety over getting a new boss.
This is weird, I know.
I want us to work well together and I’m trying to get off to a good start.
It shares some of the ways I work and think.
I hope it is the beginning of building trust between us.
Disclaimer: This deck in no way pertains to any other manager or team here.
About
I taught myself to write code in 1982, when I was 15. I loved it!
I wanted to do it for a living. But when I graduated college (Rose-Hulman, 1989) the country was in a recession and coding jobs were scarce. I landed a job writing user manuals in a software company and felt lucky to get it. Later I built test automation and performance tests.
When I was 30 I moved into management and really found my calling. I’ve led testers and developers ever since. I don’t really code anymore; haven’t in years. Leading teams rewards me far more richly.
My wife and I have seven kids between us, all adults. In my spare time I make photographs with old film cameras, and I write. If you’re curious, I share my work at blog.jimgrey.net.
Me in my early code-writing days.
Some of my core beliefs
I’ve come to believe these basic things about delivering software:
People problems are harder than technical problems. Engineers can do pretty much anything you ask, short of developing a telepathic user interface. They will work hard at it and they may struggle to get it right. But those struggles pale in comparison to how hard it is to get agreement on what to build, how to build and deliver it, and what it means to be done.
A passable solution delivered now is better than a great solution delivered later. In this era of SaaS and CI/CD, we can build tiny increments of functionality, put them out there, get feedback and data, and then decide what to build next based on that. At all times, think in terms of what you and your team can deliver to Production this week that will let us get feedback and data.
“A teams” beat “A players” every time. While true “A players” can deliver amazing work and I will turn down hiring one only if s/he is a jerk, I’ve seen it over and over: the best work comes from teams that choose to work well together. Through spirited collaboration, a team can become better than the sum of its parts. A group of B players can become an A team.
It is a superpower to understand the business of software. Business realities often frustrate engineers. The more you learn about how software companies grow and thrive, the less frustrated you will be. You may not always like how business works, but at least it will make sense and you will be able to work more calmly and confidently within it.
My job
If I do something that harms my ability to retain you, you will do me a huge favor if you tell me right away.
If I do something that feels more like telling you how to do your job than setting context, removing roadblocks, and creating structure and standards, you will do me a huge favor if you tell me right away.
What I think I’m good at
Building, improving, and running systems and processes in which people can do their best work
Influencing alignment among leaders so everyone can collaborate effectively
Leading teams to deliver results beyond what they thought they were capable of
Managing and leading people, and taking the best possible care of my team�
What I’m not good at
Writing code. This may sound strange coming from an engineering leader! I’ve focused my career on management and leadership and that’s how I want it. I don’t code anymore, period. But I still have far better technical skills and knowledge than the average person on the street.
Chaos. I need there to be at least a thin plan for, and some semblance of structure to, the work we do. Without those things I can’t tell what’s going on, and I become ineffective – and crabby.
Recognizing when I’m telling one of my stories for the umpteenth time. You won’t hurt my feelings if you stop me and say you’ve already heard it.
Building trust
I consider myself to be a professional leader of technical people.
This is as much a skill as coding or testing, and I have practiced it for years.
It’s a rare genius who can be an excellent leader and an excellent technologist. I am not that rare genius. I can’t do your job. So I place a lot of trust in you.
Trust is everything at work. Just as I extend trust to you, I want you to trust me. Our mutual trust will build over time.�I strongly believe that my success depends on yours, and my boss’s depends on mine, and so on. So I want to create conditions in which you can succeed.
You have a valuable perspective based on your role and position in the company. I need to hear your perspective to be able to create the best conditions for your success, and therefore the company’s success.
Therefore, listening to you is among the most important things I do here.�
Let’s talk
You and I will have regular 1x1 meetings to just talk.
1x1s are a time for you to tell me what’s on your mind, whatever it is. People use 1x1s to seek feedback, or talk about their career, or share their perspective, or air grievances, or seek clarity, or even talk about their outside interests. It’s up to you. Your 1x1 is not meant to be a status update meeting, unless you have a pressing need to update status.
I’ll also use your 1x1 to tell you what I know is going on around the company, especially as it affects you, so you can operate confidently and effectively.
If you report directly to me, we will meet weekly. If you report to someone who reports to me, we’ll meet two or three times each quarter.
If you ever need extra time to talk with me, message me or put time on my calendar. If it’s urgent and my calendar is full, I’ll bail out of a meeting to make time for you.
Telling you the truth
I bias strongly toward transparency and candor.
Generally, I tell you everything I know that’s happening. The exceptions are when company leadership explicitly asks me to keep something to myself, or when it involves someone’s private business.
The company can’t require me to lie to you. I can’t imagine anyone here would ever ask me to do so, but even if they did, I wouldn’t do it.
I’m committed to telling you the truth. Ask me anything. I’ll answer. Most of the time, I’ll answer directly. If I don’t know, I’ll say so. If I can’t tell you for some reason, I’ll say so.�
The Cone of Silence
Sometimes I’ll tell you we’re under the Cone of Silence.
What I say under the Cone of Silence is confidential. Do not repeat it until either I say it’s okay or it’s officially announced. This keeps rumors from starting and lets other leaders tell their teams in due time.
I use the Cone of Silence in the interest of transparently giving you information you need to operate confidently.
But I take a risk every time I use the Cone of Silence. It’s imperative that you honor it. When you don’t, it could cause me difficulties with my peers, my boss, or with senior leadership.�
The term “Cone of Silence” is a reference to the 1960s spy-spoof TV comedy Get Smart.
Failure and recovery
You may make choices I disagree with, but we get to disagree and maintain a positive relationship.
You will occasionally make a decision that doesn’t turn out. I expect that you’ll own it, fix it fast, and learn from it.
A persistent pattern of poor judgment or of failing to own, fix, and learn will make me rethink whether you’re a fit for your job.
The waterline
You might sometimes feel unsure about whether you should make a particular call. Here’s a way to think about decisions to help you sort that out.
Pretend that we’re all on a big ship. That ship can be our team, our department, or the whole company.
Every decision that goes bad will blow a hole into the hull.
If you blow a hole above the waterline, you can patch the hole, learn from the experience, and move on.
If you blow a hole below the waterline, water gushes in and the ship starts to sink. If the hole is big enough, the ship goes down faster than the hole can be repaired.
If you think your decision is above the waterline, make it and move on. If you think your decision is below the waterline, talk it through with your peers and your boss first.
Feedback is vital and goes two ways
I’ll give feedback to you, of course. That’s part of the manager gig. But I also expect you to give feedback to me. I crave it, especially when you think I’m not doing very well what I consider to be my job.
These three dimensions are key to both giving and receiving feedback:
Safety should be high – the unlikelihood of being punished for giving feedback.
Effort should be low – it’s easy to give feedback because the receiver takes it well.
Benefit should be high – the likelihood that receiving feedback will materially affect behavior.
Let me know if I don’t do well in any of these dimensions. I’ll let you know if you don’t do well in any of these dimensions.
I care about kindness and I want you to like working with me. But when I need to give you feedback, my first goal is to make sure you hear and understand it. If necessary, I’ll be blunt.�
Tight collaboration
Even though software development has long, solitary stretches, our best work happens when we work together. Some things can be done asynchronously, but spirited collaboration happens most easily when we work at the same time.
Please choose more-or-less regular working hours that overlap well with when the rest of your team works and allow you to be present at team meetings and ceremonies. Balance getting your work done with being responsive on messaging channels.
My more-or-less regular working hours are 8-5 ET. I’m often available on Slack at home as early as 7. I’m just sitting at my computer sipping my coffee anyway.
Work, rest, family, hobbies
When I started my career, 60-hour, 70-hour, even 80-hour weeks were the norm. Thank heavens we’ve learned that nobody delivers good work that way. It leads straight to burnout.
I love what I do for a living and am happy to work hard at it. But I also want to have plenty of time to rest, to spend time with people I care about, and to enjoy my outside interests. I want you to have that, too. I’m staunch about it.
There will be crunch times. But if you routinely put in heroic hours just to keep up, tell me and I’ll work hard to fix it.
When I leave for the day I switch work off. I wish the same for you. However, once in a while I might send you a message after your normal work hours. Unless I explicitly say it’s an emergency, you may ignore me until you start work the next day.
Handling time-off requests is a pesky aspect of my job and I click Approve without thinking much about it. That’s because I know you’re a professional and you will manage your time and availability so you can collaborate fully and fluidly, keep the delivery commitments you make with your team, but have the time you need to recharge and be with the people you care about.
One final note
I hope we work together happily for a long time.
But these days nobody works for one company for 30 years and then retires.
If you ever decide that it’s time for you to move on, I hope you will feel comfortable enough to tell me.
Actually, I hope we talk frankly all along about how you’re doing, and that I help you resolve frustrations or limitations as much as I can so that you always see a viable path forward here.
If you feel like you need new challenges, I will help you stay here in a role that better matches your desires, if we can find one.
But if we can’t make that work, I will help you find a job elsewhere as best I can. After you go, I hope we will stay in touch.�