more info ⬇


SW engineering, engineering management and the business of software

subscribe for more
stuff like this:

2018 01 31

Lessons from interviewing CTO Candidates

I’ve recently been on an interview panel for a company in the process of looking for their next engineering leader (think CTO or Senior Vice President of Engineering).

Over the course of the many discussions a few common themes kept coming up.

Making People Excel

This is very broad, but encapsulates the notion that a majority of the work of an engineering manager’s time is spent on making people do good work and produce good output. Activities in the this bucket include 1:1s, coaching, feedback, mentorship, motivation, career management, etc.

At its core, an engineering manager’s job is strengthing and motivating the people who work for them and the people who work with the people who work for them.

Clarity of Vision & Priorities

Assuming you have a strong and growing workforce, the goal is to make sure they know the goals. A team going in different directions isn’t a team. A group working on a hundred items ends up with a hundred partially done and poorly done products.

Getting two people to work together is no big deal. Ten people takes some work. A hundred gets pretty tough. Aligning a thousand people is nearly impossible. And yet, there is no force on earth more powerful than a thousand people working together to achieve a common goal.

Clarity of vision is about making sure your people know what the end goal is. You want people to understand the big destination at the end. Clarity of Priorities is about making the people who work for you understand what the next steps are and why they are important.

The reason this is important is that without it, everything becomes a micro debate. Rather than making a a decision and implementign steps one through ten to acheive something, every step devolves into meeting rehashing and questioning the original decision. There is no sure way to cripple a project then infusing numerous repeated micro-debates into the process.

The underside of this is that micromanagement is bad. A manager should not dictate how to achieve a priority or what language or tool a team should use. You want to leave the implementation details up to those who are closest to the problems.

If your priorities change, congratulations. You are in a normal functioning organization. Just make sure people know that it’s changed and why. If your vision changes, be prepared with a strong story to tell why. Priorities are likely to change often and vision less so, but change, especially in the face of new information can be good. Not providing clarity when change occurs is what leads to confusion and ineffciency.


Metrics are a big deal. This was a fairly common phrase. More interestingly every eng manager seemed surprised that putting business metrics in front of engineers is really important. Choosing the right metrics and publishing them effectively them and having the team internalize their importance are all hard things to do that usually takes iteration, experience and practice.

In the end, it should be trivial to:

Usually this means wiring up business logic (such as user or revenue growht) or engineering stats (such as number of releases) into business intelligence platforms of some kind. Publishing means you need automated output of reports or dashboards and consumption usually means output via email (not great) slack (ok) or wall mounted TVs (my favorite!).

Obviously, be cautious of what you measure. Vanity stats must be ruthlessly culled.


Recruiting is a big big deal. A good engineer manager understands this and makes sure their people under stand this. Furthermore a good engineering manager takes responsibility for hiring, and training people who hire, whether or not they report to them (recruiters, schedulers, interviewers, hiring managers, receptionists, etc.)

This is something I’ve personally spent the past three years thinking about and writing words and software to support. I’ll have much more to say about this area shortly.

And Yet…

At the end of the day the topics above are the most common sensible themes that came across. There were other excellent one-off answers that don’t quite fit nicely into the above, but hopefully your CTO has a good sense of the above.

2018 03 07

Focus or What I Learned About Maximizing Serial Throughput from Civilization

I had a conversation with a friend recently. He mentioned that he planning on reducing his consulting load to focus on three side projects. This kind of shocked me at the time, because in my mind the whole point of focusing is get down to just one thing.

As a child I would play Civilization (or it might have been Masters of Orion). Back then you had a global pool of science points that you could allocate into research which would give you gameplay bonuses. I discovered that if you did then in parallel, you were actually making much slower progress than if you worked on them in serial.

Here’s a more concrete example:

You are planning on building four rental properties. You have four contractors who can individually build one house in 4 years or they can team up and collectively finish one house in one year.

Doing them in serial provides the equivalent of 6 years worth of rental property income over the first 3 years! That’s money you could use to hire more contractors, either build up more houses, speed up construction of four you were building, or blow it all invest in new hot cryptocurrency.

The Limits of Serialization

Now, there is a limit to how much adding resources to a project improves speed. The seminal work, Mythical Man Month, notes that adding people to a late project makes it later. The trenchant saying “Nine women can’t make a baby in one month” also applies. In our above example, four contractors working together sped up the completion time to one year, and yet 1,460 contractors can’t build a house in a day.

I think the end goal is to understand the concept of maximum serial thoroughput and only split work into parallel if you’ve maxed out the serial output. Again in our example the fastest you could conceivably build a house is probably 1 month or so, but the speedup isn’t linear. it would likely take more than 48 contractors to do so. (My math is likely wrong! I’m just making a theoretical point here!)

Keith Rabois, during a Startup Class lecture back in 2014 talks about this with the notion of barrels and ammunition. Each barrel represents a leader who needs other employees to help them execute on a project of some kind. At some point if your leaders are maxed out, your company cannot effectively work on major new projects without hiring another leader (barrel). Hiring more non-leaders (ammunition), doesn’t not materially move the needle on existing projects.

Another way of thinking is Jeff Bezos’ Two Pizza Teams. Amazon found the upper limit of size of a tech team on a moderate problem is roughly the number of people you can feed with 2 pizzas.


When does Focusing not make sense? When you don’t have a clear end goal. When you are experimenting and brainstorming. Pre-Product-Market-Fit in VC parlance. These are times when you should be trying many different things as rapidly as possible.

Certain creative processes are effective when you take breaks and have time to marinate different ideas and thoughts in your conscious and unconscious parts of your brain.

Anytime Speed isn’t a priority really.


As an individual, you want to focus your time and energy. As an organization, you want to focus your team and the company resources.

What have we learned?

One project, completed to the point of producing value is worth vastly more than N partially completed projects providing no value.


First achieve maximum serial thoroughput and only after that, start splitting out in parallel.


Oh and my friend? After expressing my shock and giving my Civilization analogy, I discovered that he is not a hopeless Civ player. The three projects were all at different stages, and two of them didn’t require much day to day involvement, just need a couple of low hanging fruit tuneups.

2018 04 23

Tar Pits, Trampolines & Safety Nets

I’ve been programming for over 35 years. I’ve done it professionally with 8 languages (including C, VHDL, Go, Swift) and as a hobby with at least 5 other languages. I’ve done mobile apps, embedded programming, backend, frontend, devops, system architecture, and more. In addition to pure engineering roles, I’ve had stints in a diverse set of roles, including Technical Marketing, Field Support Engineering, Engineering Management & Recruiting. I’ve worked for startups with as few as three people and mega-corps with six digit employee counts. I’ve run my own companies. Some of the companies I worked at have had soaring valuations and others crashing. Some companies had both separated by a surprisingly small window of time.

I worked in Tokyo for six years on a sweet ex-pat gig and taught myself Japanese while I was there and did business & training presentations in foreign languages. I was once sent to Korea from California, SWAT team style, to fly in, successfully teach people who don’t speak English as their first language a highly technical topic and fly back in 24 hours. I’ve helped close multi-million dollar deals. I’ve charged as much as $1000 an hour as a consultant (not that often) and received as little as $0 when I got stiffed on professional work done (also, not that often). On the whole, I have a fairly diverse skillset, with a more than a few spikes of proficiency in certain marketable areas of expertise.

I only recently started going grey and despite being a dad, people laugh at my jokes more than they groan.

Despite all that:

When my self-belief, willpower, etc. suffers, I am grateful that I have done the best of my ability to surround myself (IRL and virtual) with amazing people who respect & care for me. This obviously means my family and friends, but also includes close peers, a handful of mentors and a broader circle of “my people” (peers who are like minded on more than a few axis of measurement, but may not be connected directly via work).

I cannot overstate enough. Think carefully about the people you surround yourself with. I find that in the worse case, they drag you down and keep you trapped, like a tar pit. In the best case outcome, they are both your trampoline to help you reach new heights and your safety net in case of occasional (yet inevitable) falls.

2018 07 07

Two Kinds of Culture

One of the more common conversations I have is around the nature of what happens when things go wrong in an organization. In all businesses, things go wrong. In startups, it can feel like things go wrong more often than people post selfies on facebook.

Things going somewhat off-kilter or things going off the rails is a frequent enough occurrence that the way a company responds is quite meaningful. I’ve observed organizational reactions along a spectrum that I call Type Us/Type You.

Type You organizations

You can think of a Type You organization as one that points fingers when things go Titanic on iceberg.

There’s probably screaming. There may be crying. There’s definitely swearing.

Effing Product never anticipated this. Why the hell did sales sell something we don’t do. Eng can’t deliver. These designs are late/unrealistic/unimplementable. Useless marketing doesn’t bring in enough leads.

Beyond swearing what you really have is resentment, mistrust and a clear lack of communication. This is a recipe for a stagnant, dysfunctional company.

Type Us organizations

When faced with the aftermath of a steaming crater, Type Us orgs may have screaming, but they are usually followed by apologies. A well functional Type Us is mostly a big sigh. Possibly a group hug is the company is into that. Following these necessary but short moments of shared grief and pity, the focus is on the problem, resolution and how to prevent a similar outcome in the future.

If there is blame identified, it’s for the purpose of support and helping. “The root cause involved X commincating to the customer Y. How can we be more proactive or engineering around this? What can we do for X?” “The release system worked as designed, but human error led to the early release of Y. What kind of guards can we engineer in place to prevent another incident?”

In a Team Us, the basic thought process is problem, resolution, future prevention and growth. If you get good a this, your team should never see the same problem twice. You are compounding improvements over time.

And so?

If it’s not obvious by now, you want to work in a Type Us environment. Type Us is easier to maintain in a smaller group (team of say 5 or so) than in a larger org. Geographical differences make this even more challenging.

If you are stuck in a Type You environment, it’s important to note that moving the team toward Type Us is possible, but challenging. If you are not in a leadership position, the difficulty is even greater.

If you are looking at a new role, ask your interviewers to describe what happens when something goes wrong and followup with who was at fault primarily. You want to hear things like shared blame or something like “while the initial spark as from X, Y or Z could have done better to prevent it.”

The kind of organization you join will make a big difference in your overall satisfaction and career longevity.

the fine print:
© matt nunogawa 2010 - 2019 / all rights reserved
back ⬆