Skip to content

Lifehack

What It’s Like To Lead An Engineering Org: Thoughts On “CTO In The Loop”

I just read CTO In The Loop by Balki Kodarapu. It’s free on Kindle through July 20th, so if you want to give it a read, go do that now.

It’s a narrative arc following a developer, “Sam”, who starts as a software engineer at a startup, and ends up a fractional CTO after a career that includes engineering manager, director of engineering and VP of engineering at a company that IPOs. The book was a fun read, and does a good job describing what it’s like to build a company and a software business from the early days to a more mature organization.

The realities of Sam’s growth ring true: he starts out focused on features and clarity, and then moves up levels of abstraction. He loses touch with tasks and areas that used to matter, but gains higher level views and more ability to influence the organization. As a director, if you’re still reviewing PRs the way you used to, you’re basically breaking your organization

We also see the evolution of several other characters, including Priya the project manager, Mei the UX designer and Jack the senior developer. Some of these folks stay with Sam across companies, while others pop in and out, just like real world colleagues.

Some details felt a little forced; for example, locking down a GitHub repo and preventing merges to the main branch are treated as a major effort, when most software shops do that pretty early.

I especially liked the portrayal of the thorny moments of management that Sam encounters:

  • firing a team member
  • multiple rounds of layoffs (and subsequent hiring)
  • changing his understanding of the constraints and goals of the engineering org he is in

I also really enjoyed the emphasis on integrity, and how the protagonist was repeatedly challenged to hold onto it through different stages of business growth. I think integrity is an easy thing to write about and much harder to actually live. In the moment, you tell yourself that just this one tweak that you might feel uneasy about will move the business in a positive direction. But doing this repeatedly only works in the short term.

The benefit is immediate and the cost is deferred, and avoiding these kinds of decisions is a constant challenge as an organization grows.

The hard part is that it’s rarely obvious where the line is. Most people agree you shouldn’t commit fraud. But there are dark UX patterns that benefit the business. For example, you could make it much harder to unsubscribe from a service than it was to subscribe; every organizational incentive points that direction.

Another example is the integrity in making it easy for a customer to leave: making it easy for people to export their data and take it with them. That’s a frustrating tradeoff for whoever’s job it is to sell the product, but it’s a pretty clear-cut example of integrity. You want to earn people’s business, not hold their data hostage.

There are other places integrity shows up over the course of a career, but the author does a good job of showing how it is hard to maintain, especially when you are focused on the day to day of building a software business.

CTO In the Loop is a fun, easy read. I read it on the Kindle app in about 2 days while on a vacation. I’d highly recommend it to people early or mid-career in software who are curious what life looks like at a different level of the org chart. When I was younger, I assumed people at higher levels had a lot more control, agency, and power. That’s true, but they are also further from the customer, removed from knowledge of how technical systems actually work, and have a lot less clarity about the day to day. To say nothing of many competing demands that folks at the director or higher level have on them.

Writing code, or telling an AI how to write code, is one thing. Thinking about what the company looks like in one year or five, how to bring different teams together, how to manage investors and understand the market, and how to keep every department rowing in the same direction: that’s a tremendously difficult job. This book is an accessible narrative of those tensions, to which I don’t think new or even mid-career developers usually get exposure.

So go check it out. Did I mention it’s free on Kindle through July 20th?

Balki, thanks for writing this excellent, interesting fable of a software developer’s career.

What I Don’t See When I’m Envious

I’m getting to the age where peers have accomplished a lot. I’m not talking about people who were exceptional out of the gate and did great things in their 20s and 30s. I’m talking about people that felt like genuine peers, but now have done things like:

  • made a boatload of money
  • built a business such that they have all kinds of freedom
  • are well known in their fields

These folks have things that I want. And I feel like I’m just as talented. I could be where they are and have what they have.

In my mind I often think “why does <X> have that and I don’t”. This envy is not constructive, but that doesn’t stop it from popping up from time to time. I think I’m getting old enough that status and legacy are starting to matter in a way they didn’t a decade ago.

Here are strategies I use to combat envy:

  • Remind myself that I don’t actually know everything they have. I can see certain aspects of their life, but even for close friends I don’t know everything, just what they choose to share. The friend who is a professor who works with interesting projects and gets the summers off might have to deal with horrible politics or a low salary. I just don’t know. That means I don’t know enough to know if I’d actually want to trade places. I am idealizing what they have and not understanding the downsides.
  • Even if I would want to trade places, I don’t know what they went through. When I see a friend with the thriving business who has flexibility and can work when he wants, I don’t see everything. I don’t see how he had to be tethered to it for years, or the risks he had to take, or the multiple years of 60+ hour workweeks and the stress that wrought on his body, family and friends. I try to imagine the late nights and the worries in the same way I imagine the benefits.
  • Remind myself that I have agency and can work toward what they have. Even though I’m mid-career, if I wanted to adjust things to move towards what someone I see has, I can do so. As mentioned above, I need to be willing to make sacrifices, but I am lucky enough to have the space to consider it. With sufficient focus and effort, I can do most anything, I just can’t do everything.
  • Even if I want to trade places with a friend, know what would make me happy, and would have been willing to make the sacrifices to be where they are, I am still discounting my current situation. It’s very easy to think “oh, <Y> would make me happy” but if I can’t look at where I am and be grateful, I might be kidding myself. And when I do take a hard look at where I am, I do feel more gratitude and satisfaction. One of my hacks when I’m feeling down is to just list 2-3 things that I like about my life.
  • Related to feeling grateful for what I have, I also try to remember that just as I am looking at people and saying “why can’t I have what they have”, other folks might be looking at me and saying the same. In fact, I might have said the same 20 years ago if I was looking at someone where I am now. It’s easy to discount what you have and focus on what you don’t, but thinking about these folks makes me more grateful for what I do have.

I’d be surprised if I’m alone in feeling this way. Do you feel envious? If so, how do you deal with it?

Top Professional Accomplishments

Not to get maudlin, but it is fun to think about accomplishments over the years. The days are long, but the years are short, and I can’t believe I’ve been working in software development for more than two and a half decades.

My top professional accomplishments include:

  • Writing a book for a known publisher
  • Co-founding a startup that is still alive and kicking (5+ years after I left)
  • Running my own consulting business for about 8 years, and making a decent living from it
  • My time at FusionAuth; I’ve worn a bunch of different hats with real impact on the direction and culture of the company
  • Presenting at marquis conferences like Identiverse
  • Co-organizing the Boulder Ruby for about 5 years
  • Supporting the website of one of the biggest sporting events in the world
  • Keeping this tech blog running for over 20 years

Say Goodbye

In this time of increasing layoffs, there’s one thing you should do as a survivor. Okay, there’s many things you should do, but one thing in particular.

Say goodbye.

When you hear someone you know is let go, send them a message. If you have their email address, send them an email from your personal account. If you don’t, connect on LinkedIn or another social network.

The day or two after they are gone, send them a message like this:

“Hi <firstname>, sorry to hear you and <company> parted ways. I appreciated your efforts and wish you the best!”

Of course, tune that to how you interacted with them. If you only saw them briefly but they were always positive, something like this:

“Hi <firstname>, sorry to hear you and <company> parted ways. I appreciated your positive attitude. I wish you the best!”

Or, if you only knew them through one project, something like this:

“Hi <firstname>, sorry to hear you and <company> parted ways. It was great to work on <project> with you. I wish you the best!”

You should do this for a number of reasons.

It is a kind gesture to someone you know who is going through a really hard time. (I wrote more about that.) Being laid off is typically extremely difficult. When it happens, you are cut off from a major source of identity, companionship, and financial stability all at once. Extending a kindness to someone you know who is in that spot is just a good thing to do. It reaffirms both your and their humanity.

It also doesn’t take much time; it has a high impact to effort ratio.

There may be benefits down the road, such as them remembering you kindly and helping you out in the future. The industry is small–I’m now working with multiple people who I’ve worked with at different companies in the past.

But the main reason to do this is to be a good human being.

Now, the list of don’ts:

  • Don’t offer to help if you can’t or won’t. I only offer to help if I know the person well and feel like the resources and connections I have might help them.
  • Don’t trash your employer, nor respond if they do. If they start that, say “I’m sorry, I can imagine why you’d feel that way, but I can’t continue this conversation.”. Note I’ve never had someone do this.
  • Don’t feel like you have continue the conversation if they respond. You can if you want, but don’t feel obligated.
  • Don’t state you are going to keep in touch, unless you plan to.
  • Don’t say things that might cause you trouble like “wish we could have kept you” or “you were such a great performer, I don’t know why they laid you off”. You don’t know the full details and you don’t want to expose yourself or your company to any legal issues.
  • Finally, don’t do this if you are the manager who laid them off. There’s too much emotional baggage there. You were their manager and you couldn’t keep them on. They almost certainly don’t want to hear from you.

Be a good human being. When someone gets laid off, say goodbye.

Ask for no, don’t ask for yes

I think it is important to have a bias for action. Like anything else, this is something you can make a habit of. Moving forward allows you to make progress. I don’t know about you, but I’ve frozen up in the past not knowing what the right path was for me. Moving forward, even the smallest possible step, helped break that stasis.

One habit I like is to ask for no, not yes. Note that this is based on my experience at small companies (< 200 employees) where a lot of my experience has been. I’m not sure how it’d work in a big company, non-profit, or government.

When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadline.

Let’s see how this works.

Suppose I want to set up a new GitHub action that I feel will really improve the quality of our software. This isn’t whimsy, I’ve done some research and tested it locally. I may have even asked a former colleague how they used this GitHub action.

But I’m not quite sure. I want to let my boss know that I’ll be modifying the repository.

I could say “hey, boss, can we install action X? It’ll help with the XYZ problems we’ve been having.”

If you have a busy boss (and most people do), this is going to require a bit of work on their part to say “yes”.

They’ll want to review the XYZ problem, think about how X will solve it and maybe do some thinking or prioritization about how this fits in with other work. Or maybe they’ll want you to share what you know. It may fall off their plate. You will probably have to remind them a few times to get around to saying “yes”. It might be a more pressing issue for you

Now, let’s take the alternative approach.”Hey, boss, I am going to install action X, which should solve the XYZ problems we’ve been having. Will take care of this on Monday unless I hear differently from you.”

Do you see the change in tone?

You are saying (without being explicit) that you “got it” and are going to handle this issue. The boss can still weigh in if they want to, but they don’t have to. If they forget about it or other issues pop up, you still proceed. This lets you keep moving forward and solving problems while keeping the boss informed and allowing them to add their two cents if it is important enough.

You can also use this approach with a group of people.

By the way, the deadline is critical too. Which would you respond to more quickly, if it was Jan 15, all other things being equal and assuming a response was needed?

  • “I’m going to do task X.”
  • “I’m going to do task X on Jan 17.”
  • “I’m going to do task X on Feb 15.”

I would respond to the second one, which has a deadline in the near future. I think that is the way most folks work.

Again, pursue this approach for problems you feel are in the scope of your role but that you want to inform the boss about. It’s great when you want to offer a chance for feedback, but you are confident enough in the course of action that you don’t need feedback.

What I wish I had known when I was starting out as a developer

As I get older, I wish I could reach back and give myself advice. Some of it is life advice (take that leap, kiss that girl, take that trip) but a lot of it is career advice.

There’s so much about being a software developer that you learn along the way. This includes technical knowledge like how to tune a database query and how to use a text editor. It also includes non technical knowledge, what some people term “soft skills”. I tend to think they are actually pretty hard, to be honest. Things like:

  • How to help your manager help you
  • Why writing code isn’t always the best solution
  • Mistakes and how to handle them
  • How to view other parts of the business

These skills took me a long time to learn (and I am still learning them to this day) but have had a material impact on my happiness as a developer.

I am so passionate about this topic that I’ve written over 150 blog posts. Where are these? They’re over at another site I’ve been updating for a few years.

And then I went and wrote a book. I learned a bunch of lessons during that process, including the fact that it’s an intense effort. I wrote it with three audiences in mind:

  • The new developer, with less than five years of experience. This book will help them level up.
  • The person considering software development. This book will give them a glimpse of what being a software developer is like.
  • The mentor. This book will serve as a discussion guide for many interesting aspects of development with a mentee.

The book arrives in August. I hope you’ll check it out.

Full details, including ordering information, over at the Letters To A New Developer website.

The lifechanging magic of a separate work computer

Man performing magic trickFor a span from 2002 to 2019, I almost never had a work computer. There was one or two times where a contract provided a computer. But primarily my work computer where I did, you know, my work, and my home computer, where I worked on side projects and did my writing and personal internet access, were one and the same.

At Transposit, where I recently started, I have a separate work computer and a personal computer.

This is huge.

Here’s what it means. (I work from home, so boundaries are a bit more fluid.)

  • I’m no longer tempted to work (not even look at Slack) when I pick up my computer to say, write a blog post.
  • I can set down my work computer at end of the day and feel “done”.
  • When I pick up my personal computer to work on a personal project, I’m more focused.

Working is such a endorphin rush sometimes. Having a separate work computer and not installing any work software (not email, not Slack, not nothing) on my personal computer helps me maintain work life balance. This means when I’m working I am working and when I’m not, I am not.

 

What do I do when someone’s doing something wrong?

Driving in the rain
Uh, I think you’re in a little deep

Somewhere, sometime, someone will do something wrong. It happens more often than you think. (That person might even be me.)

When they do, I have an innate desire to correct them, to show them the benefit of my mistakes and to enlighten them. This is, in itself, wrong.

What should I do instead? A couple of things.

  1. Make sure I really understand the issue they are facing. Sometimes I can gain an appreciation for their choice once I have more information about the situation, and sometimes my questioning can cause them to make different decisions or to revise their thinking.
  2. Think about whether I have all the context. (This one’s easy; I don’t.) So remember to consider that from their perspective choices make more sense than from mine.
  3. I consider the ramifications of a poor decision. It’s better to let someone choose an obviously wrong course when the stakes are low. We’ve all made mistakes (I deleted an entire table from a production database!) and that’s the best way to learn. However, if the stakes are high, that means a discussion is more warrented.
  4. Contemplate my role. Is this a peer? An old friend? An ex-colleague? A mentor? A mentee? Someone I’ve just met? Each of these types of people have different tolerance for my opinion.

In short, rather than just explaining to someone why they are wrong, I need to stop and think about the entire context of the situation, including what I’ve missed, what the consequences of the action are, and my role.

Imposter syndrome

This article resonated with me. I became familiar with imposter syndrome when my SO spoke on it several times (she’s available to speak to your group if you’d like).

When you are deep in a discipline, it can be very easy to “know what you don’t know” and downplay your expertise. I often am asked to support desktop computers because I work in software (a la this post). But I know how little I know about the problem.

I think the issue is also exacerbated by the continuous flow of information that we are all offered by the internet. This makes it very easy to compare ourselves with what other folks choose to share (typically, though not always, their best side and successes). This makes me, I will be honest, feel inadequate. Why didn’t I learn more about k8s? Why haven’t I built a successful saas business? Why haven’t I worked at scale like that? Why haven’t I built a react native app? And so on and so on.

And when someone asks me “can you do that?” I always have that moment of fear and have to force myself to say yes.

My answer is to breathe, take chances, remember that failure is an option, and recall that while we see other people’s successes, we rarely see their failures. It isn’t fair to me to compare my “inside” with someone else’s “outside”.

“Someone Else’s Problem”

Fingers pointing at each other
The bad kind of SEP

I remember when I first heard the acronym SEP. It was way back in the dawn of my career, and a grizzled old contractor was talking about some aspect of a project.

“The flurbuz is janky. Welp, SEP.” – him

“What does that mean” – me

“It’s ‘Someone Else’s Problem’ now.” – him

“Oh.” – me

It has stuck with me all my career, but as I think about it a bit more deeply, I realized that there are two different kinds of SEP declarations–one good and one bad.

The bad type of SEP is when a problem doesn’t have an owner and everyone is ducking it. You know, that architectural original sin no one wants to face, or the client who is late but no one wants to cut off. If everyone is saying SEP, then the problem will never be solved. No good. The remedy here (in small cos, at least) is often to have everything “fall up” to the CEO. She can be the utility player who owns everything not otherwise assigned. Of course, tackling all of these orphan problems can prevent her from focusing on her main job, but at least she has the clout to make the problem someone else’s if need be.

The good version of SEP is also known as delegation. This means you’ve handed off the problem to someone else, whether on your team, an external contractor, or a client who wants to take some part of a project in house . And when you say SEP, you are trusting them to take care of the issue. This allows you to focus on other tasks. It does require you to trust that they can do what was agreed to. (They did agree to it before it became their problem, right? If not, this may be an example of the bad type of SEP, or at a minimum a chance for a ball to be dropped.)

For me personally, delegation is a skill I struggle with, even though allows me to be more effective. So saying “SEP” and letting the other party own it is a great way for me to practice that skill.