The Core of Software Engineering Management

Whenever you do something, you need to keep the core goal or idea in mind. The core is your North Star, especially when times are tough. This post is about the core of Software Engineering Management, a topic near and dear to my heart.

For example, suppose you are learning a language in school. The core is learning the language itself: speaking, reading and writing, maybe even fluency if conditions permit (e.g., you have a realistic way to immerse yourself in the language nearly 24/7, which is often much harder than it seems). There are other goals, like doing well on tests, but learning the language is the core of it all, not tests, studying, etc. It sounds quite simple when stated that way, but you’d be surprised how often people drift from their true goals (myself included).

For software engineering management, the core is happy and productive teams. This mantra takes a minute to learn and a lifetime to master. Of course, “happy” and “productive” need unpacking. But that phrase is simple to remember.

Despite being a business cliché, quadrant charts are quite useful because they impose a light framing on a topic and, if done well, help you see the forest for the trees. I’ve created one for software engineering management, see here:

Like any good quadrant chart, the place to be is “up and to the right”: the happy and productive team, org, etc. The other quadrants I will discuss in future posts. If you have directly fostered or evolved a team to be happy and productive, or at least improved the trajectory, you should be proud of yourself! Yes, it’s a team effort, but I’d say (perhaps like most roles) large swaths of what engineering management entails can be unrecognized and thankless at times, so you gotta celebrate the wins.

Happiness for a team member means some combination of:

• They enjoy their work, ideally day-to-day
• They enjoy collaborating with their colleagues, both on the team and across roles
• They realize (e.g., by launching new features), and are recognized for, the value of their contributions
• They believe their own area, and ideally the company as a whole, are on the right path
• They see and experience how their success and company success grow together, and personally this often means advancement, promotion, bigger opportunities, increase in compensation, new projects, etc. I’ve found very few engineers who are comfortable with stasis, given how much the industry has changed and keeps changing.
• They stick around and contribute both via outcomes and culturally as well

Of course, work satisfaction is an extremely deep subject, so consider the above list a sampler plate of top considerations.

Productivity for a team member means, again some combination of:

• The team or org produces outcomes that matter for the product and company
• In some cases, that output is a “big win” and moves a key measure: revenue, users, cost, etc.
• In other cases, maybe the big win is harder to validate, but the outcome still matters by some provisional, circumstantial, qualitative, or localized measure. Fact is, not everything is a big win, this doesn’t get talked about as much online or in books, and so I want to carefully delineate here.
• The contributions are timely, especially these days (the age of AI) where time matters more than before.
• The contributions are also high quality. Speed and quality are in Blakean tension, like reason and energy. Doing both well, or navigating the rhythm and balance, is the real art.
• Outcomes are sustained: you’re not repeatedly running out of important things to do, whatever the bottleneck is (decision making, under- or over- resourcing, etc).
• The overall trajectory, both personally and for the org, is growth.

Again, much more can be said and considered on productivity.

Of course, the million dollar question is, given the goal of happy and productive teams, how do you go about achieving and sustaining that state of bliss? Well, that is a good question now, isn’t it? In my current analysis, I believe it boils down to 4 key efforts that the software engineering manager must constantly attend to. Again, these sound like business clichés, but there is tremendous value in doing them well:

1. Drive and deliver outcomes, with the right vision, strategy, alignment, etc.
2. Foster and realize continuous improvement and innovation
3. Lead, manage, and communicate with personal excellence (vision, capability, reliability, trustworthiness, integrity, empathy, candor, etc)
4. Similarly, cultivate an excellent team/org (manage performance, develop people, create new leaders, attract and retain great people, handle problems gracefully and with the right pace, etc)

I’m sure I’ll tweak this framing over time, but the ultimate proof is in the pudding: can these ideas explain or predict success in real world situations and events? If yes, dive deeper to understand and employ them further. If not, diagnose what the issue or gap is, and adjust. My conjecture is that this list is in the right ballpark, but in my writing I’ll be testing and refining each idea.

Heck, the framing here is basically Socratic: excellence, or virtue, or what have you, with a dash of dialectic along the way. I can’t claim to be an innovator in methods of inquiry, so I will just stand on the shoulders of some pretty good approaches.

So that’s it for now. Remember: happy and productive teams.