Skip to content

Career

  • in Career
  • 4 min read

Career Update and a New Chapter

A couple of months back, I announced on LinkedIn that some opportunities fell through and I found myself unexpectedly on the market looking for work. It has been a while since I've given an update on what was going on and what I've been up to.

The Search Begins (Anew!)

After watching both opportunities fall through, I began my job search again, leading to me applying to over fifty different companies, focusing on leadership roles (think Team Lead, Engineering Manager, or Director of Engineering). Even though I have quite a few years of recent experience (I've been leading teams in some capacity since 2018), the most common piece of feedback is that it seemed like my recent roles were more technical than leadership.

That's fair feedback as my leadership style is that I wouldn't ask a member of my team to do something that I wouldn't do and I'm naturally curious about how things work, so there are times when I've rolled up my sleeves to help the team get projects done and/or be the technical lead that the team needed.

So, let's try a different approach.

I retooled my resume to highlight my technical accomplishments and applied for more experienced technical roles (think Senior Software Engineer, Staff Software Engineer, Principal Engineer, and Architect). Given the first round of feedback, I figured this would be a shoe-in, right?

Not quite...

Most of the feedback I got for these roles is that I wasn't hands-on technical enough (though my most recent engagements had me coding the vast majority of the time), though my leadership skills were solid.

What Do You Want To Be When You Grow Up?

Not going to lie, it's a bit frustrating to be told that you're too technical for leadership, but not technical enough for engineering, especially when you've helped companies launch new products and new offerings.

My theory (potential cope) is that companies don't know what to do when they find someone who's both a strong technical leader and a strong engineer as they don't come across them that often. Most of the companies I've seen typically want their leadership to be able to understand concepts (i.e., what is continuous deployment pipeline), but not enough to implement or fix it when there are issues. For the engineering side, my experience was that they wanted people who were deep in the technical weeds (we're talking edge cases, knowing the docs cold), but didn't ask a ton about how the work fits into the bigger picture of the business.

For me, I need a combination of both to be happy. I enjoy doing the technical work, building new tools/products to solve problems as I'm great at finding issues with a process and making it smoother.

On the other hand, I thoroughly enjoy leading people and coaching up a team. That was one of the original inspirations for this blog, The Software Mentor, a way to give back and be an (unofficial) mentor to those who don't have someone to level up from.

I can't just ignore one side of the equation, that's throwing away half my strengths.

So what do you do?

In my case, change the game.

A Different Approach

Over my career, I've been lucky to work at quite a few companies and have built great relationships everywhere I went. In addition, I've spent the last ten years building up a reputation in the community as a technical leader (Microsoft MVP since 2017 and have been presenting on technical concepts since 2015).

I figured if I can't get work as an engineer or as a leader, why not try something new.

Back in 2014, some friends and I had started on an ill-fated attempt to build a replacement Point of Sale system to be used by liquor stores (this would have been before tools like Square would become ubiquitous). Though the project never launched, we gave it a name, Small Batch Software as it was both a tip of the cap to small batch distilling and a nod to working in small batches (a la Lean Manufacturing with batch sizes of 1).

We always joked that Small Batch might take off at some point, but we retired the project and the idea of Small Batch was retired (like most ideas go).

Fast forward to 2021, I started taking on some side work, helping other companies with their implementation and process improvement. At the time, I didn't have a formal company, but I started thinking more about forming a company and working through that.

When I left Rocket Mortgage in 2023, I decided to form my own company, Small Batch Solutions LLC to help me with a more formal approach for moonlighting, partly to get some experience and partly to see how it would go.

However, like most things, it was a good idea, but I didn't put the required energy into the company, so it has been mostly dormant since then.

Which brings us to the present.

Small Batch Solutions - Iteration One

After pouring more energy into the company over the past two months, I've had success in landing clients, focusing on what I enjoy doing the most:

  • Mentoring others, helping them advance in their career and technical skills
  • Problem solving, figuring out pain points and solving them simply

Given these successes, I've chosen to focus on Small Batch Solutions full-time, allowing me to continue building with the community and also allowing me to use my strengths without having to fit in a single "box".

If you've ever found yourself thinking, "I wish I could work with someone who just gets it and can help me", then reach out, I think I might be able to help!

Coaching Corner Volume 5

Welcome to Cameron's Coaching Corner, where we answer questions from readers about leadership, career, and software engineering.

In this post, we'll look at a question from TheRefsAlwaysWin about how to get a new engineer on their team to open up and get comfortable asking for help.

I've got a newish member to the team and they're still early in their career. They've got a good head on their shoulders, however, they tend to go down rabbit holes when problem solving and they don't speak up or ask for help.

They've asked me a few times about "how did I know ....", and a lot of the times, it's experience (I've been doing this for a few decades now).

How do I help them open up and ask more questions to the team and group?

Coaching Corner Volume 4

Welcome to Cameron's Coaching Corner, where we answer questions from readers about leadership, career, and software engineering.

In this post, we'll look at a question posed by Bastien in the Engineering Manager's Slack Group on how to praise your team.

Context: New to Engineering Manager, managing 5 people and working in a 5 person team. My managees are not 100% on my team.

Details: OK, so I've quickly learnt how to spot mistakes and follow up improvements to both teams (one I manage and one I work on). I'm confident taking actions and communicating on all of that. But there is the other side -> congratulation and following up on behavior/action.

Example: The current team has low velocity. They recently finished the specs and review. It didn't happen for months (always late on that), but it's their "normal" velocity. I congratulated them, but I'm wondering if I should have since they "just did their job".

How do you congratulate your coworkers? Specifically

  • Do you? Why or Why Not?
  • How?
  • On trivial/exceptional stuff?
  • When and Where?

Coaching Corner Volume 3

Welcome to Cameron's Coaching Corner, where we answer questions from readers about leadership, career, and software engineering.

In this week's post, we look at how Alan can help their engineer figure out what they want to be when they grow up.

Hey Cameron!

I have a front-end engineer who's sharp, but they're not sure what their career growth looks like. I get the sense that they're interested in other roles outside of software development. How do you navigate this and help them grow?

Cameron's Coaching Corner Volume 2

Welcome to Cameron's Coaching Corner, where we answer questions from readers about leadership, career, and software engineering.

In this week's post, we look at how Chase can balance writing the perfect code and shipping something.

My question: As a young developer, I notice that sometimes I get paralyzed by options. I want to write the perfect piece of code. This helps me in writing good code but usually at the cost of efficiency. Especially when I am faced with multiple good options. Sometimes I want to KNOW I’m gonna write the right thing before I’m writing it when I my be better off with some trial and error

  1. Are these common problems that you see people face?
  2. What rules of thumb or other pieces of advice do you have to avoid writing nothing instead of something as a result of seeking the ideal?
  3. How important is planning vs trial and error ("failing fast" as they say) to good software development flow?

Cameron's Coaching Corner - Mentoring an Intern

Welcome to Cameron's Coaching Corner, where we answer questions from readers about leadership, career, and software engineering.

In this week's post, we look at how test123 can improve the mentoring experience for their new intern.

I recently had an intern join my time and I’m going to be his mentor. I’ve had interns in the past, but this one doesn’t understand any fundamentals and struggles with everything.

My question to you is this, how can I help him? He doesn’t know HTML/CSS/JS, so I’m trying to teach him those, but it’s taking away a lot of time. I suggested for him to watch some videos and then we can sync twice a day to go over the topics and discuss them further.

My issue: I don’t want to just say “go watch videos.” Bc, that’s not the best way to learn - I want him to dive into the code and try things and break, that’s how I learned at least.

How do you think I should handle this? I wanna be a good mentor and I want him to learn and grow. I don’t wanna fail the kid bc I don’t know the proper way to mentor.

My Interviewing Strategy

I’ve found that interviewing for a new job can be super stressful and it reminds me of speed dating, “Let’s get to know each other over the next few hours to see if this relationship can work”. With such a short time window, there’s not much time to ask “fluff” questions like “if you were a tree, what kind of tree would you be”. Instead, I’m more likely to ask some of the following questions to get a better understanding of what I’m about to step into. If the company can’t answer some of these questions, it’s not a deal breaker, but can be a red flag about this place.

With that being said, I hope these questions help you during your interviewing process!

Business Strategy

  • What is your biggest concern for ?
  • What was a major success for over the past year?
  • What was a stumbling block for over the past year?
  • What does your ideal customer look like?
  • What is your business model (i.e. how does make its money)?
  • Any thoughts of expanding to other markets (such as, if the company sells a particular type of medical device, are there any thoughts of making other devices or add-ons for the main device)? If not, why?
  • Who would you say are your biggest competitors? What differentiates you from them?

Software Development

  • What is the current architecture of the software?
  • What is the direction that is moving to?
  • What is your current tech stack?
  • What development methodologies (TDD, Pairing, Mobbing, XP, etc…) are you using?
  • How do you maintain quality?
  • What is one quality you appreciate it a teammate?
  • What is one quality that gets on your nerves? How much work is new (greenfield) vs maintenance (brownfield)?

General

  • What would you consider to be a big success over the past year?
  • What would you consider a failure or stumbling block over the past year?
  • What is the best thing about working at ?
  • What is one thing that be improved about working at ?
  • What determines “success” for this role? How would you measure / know it?
  • What does a typical day look like for this role?

Benefits

  • How many vacation days? How many sick days? Are they from the same bucket (i.e PTO) or different buckets?
  • Is there a 401(K)? If so, what’s the vesting period (i.e. how long until the employer contributions become yours)? What’s the employer contribution?
  • Is there a training budget? If so, is it per person, per team, per department? What do you typical training expenses look like (books, videos, conferences, or in person training)?
  • When does open enrollment begin for insurance? Am I covered on day one or is there a waiting period?