The Ten Secret Maxims for Leading Exceptional Engineering Teams

Are you an engineering leader? If so, today is your lucky day — I’m going to give you millions of dollars worth of free advice so you can capture the same magic I’ve found in leading some incredibly high-performing, high-quality and super-fun engineering teams. Just like you, I’ve come across thousands of posts and books about how to be a great software engineer and manager. For the most part, these lessons focus on the fundamentals of coding, architecture patterns, data modeling, team management, scrum cadence and so forth. Here’s the thing — merely having a command of those fundamentals is important, but not nearly good enough for wild success. Those things are just table stakes, and furthermore, new developments in AI may someday reduce their importance.

What really moves the needle is not found in those books, and not likely to be replaced by AI. It is a secret sauce — unconventional ways of thinking based on the collective wisdom of prior success. That’s the path you want to be on… so, without further ado, here are the ten secret maxims for leading exceptional engineering teams, and raising the bar of your whole company with it!

Just keep climbing… you’ll get there!

#10. This is how we do it. Ray Kroc was onto something in 1954 when he asserted that leaning into a franchise model could accelerate innovation through standardization. He wasn’t the first — even Benjamin Franklin franchised his almanac printing in 1733; and old Ben seems like he was always a little ahead of the curve. As an engineering leader, one of the most important things you can do is get everybody on the same page; and just like the luminaries noted above, you too can franchise the engineering process. Getting your entire organization to do things the same way has tremendous advantages. Examples:

• Use the same IDE so you can share toolset integrations and keyboard share during pair program easily.
• Use opinionated and unforgiving code formatters like Black or Prettier with shared standard rulesets, and you prevent all arguments about what code should look like.
• Short circuit confusing, shoddy code by mandating code formatting with Ruff or ESLint, and make it required using checkin hooks.
• Do you like watching new employees slog through a multi-day out-of-date onboarding procedure? Of course not! Use container-based development environments for an easy first day.

These are just a small handful of possibilities. The key is that the consistency associated with setting and sticking to standards gives your team resiliency to turnover, quicker bug resolution, faster ramp-up and a much better shared experience. There are two ways to know you’re doing it right: (1) when you’re able to quickly and easily roll out process improvement changes to the whole team because of your shared conventions; and (2) you find yourself humming Montell Jordan’s 1995 hit “This is how we do it” as part of your SDLC.

#9. We’re all go-to-market. If you ask most software engineers to describe their job, they’ll probably tell you some variation of “writing code” or “building features”. While technically true, it really misses the mark on an engineer’s raison d’être. With all due respect to the academic and non-profit communities, the vast majority of engineers work for some company or organization with a focus around selling goods or services. As my good friend FK often says (but others said first): nothing happens until somebody sells something. The truth is plain: the success of most companies depends on a great go-to-market strategy with strong sales and marketing execution.

So, bear with me for a moment… imagine you told your engineering team that they were now in sales and their job was to help sell the product your company offers. Well, if they interpreted your edict as a request for them to work the front lines as an SDR, many of them would just have panic attacks and quit on the spot. So, let’s clarify. The way they can help sell is by changing their mindset about their role: we’re all part of the go-to-market team.

The job of the product and sales team is to bring feedback to the organization about product-market fit, customer requests, demo stories (and horror stories), sales and rejections. The job of the engineering team is to listen, empathize and act on this feedback. Don’t insulate your team from the sales organization. In fact, encourage the opposite — make sure your engineers understand the customer, and how/why the customer uses the product they built. If possible, get your engineers to watch the customers use (or struggle to use) their creation! When you ask your team to build something, make sure they understand why they are building it and how it protects existing or unlocks new revenue opportunities. If you can’t draw that line… don’t build it. Too often the sales team feels the elation of making numbers and dejection from defeat in the field, while the engineering team sits smugly in the back cave plugging away at ideas they find personally interesting but irrelevant to the bottom line. So, embrace the “team sport” of it all. Draw the engineers toward the sales organization and go for the win together.

#8. Data is a relationship business. There are many different valid ways to store, seek and serve data: Relational DBs, NoSQL/KV DBs, Graph DBs, Vector DBs, Columnar DBs and other architectures like object stores and even file systems. Over the last decade, the debate has raged on and on about which engine is “the best”. It’s a ridiculous argument, of course, because that decision is completely dependent upon what you’re trying to do with the data in the first place. But before you misinterpret my intent —this maxim is not actually about the database engine. Truth bomb: digital enterprises are built completely atop data, and the shape of that data and the relationships between them underpin almost every technical decision your team needs to make.

As a team, modeling and remodeling the data should be a core group exercise. Every time there is a new project, begin by examining the data involved and how it pieces together with the existing data model.

Capturing a good relational data model on paper or whiteboard is the best teaching artifact possible for new employees, the best low-effort documentation of the system and the best viewport into the original thinking of the system creators. As a bonus, it’s a great way to train rookie engineering minds on the base theories of data modeling: moving from conceptual entities to logical entities to physical entities. (think: what’s a library book.. the idea of a library item, the description of such as a book, or an actual book on the shelf?).

How powerful is a good relational model? Well, I’ll make you a bet — give me 30 minutes with your well thought-out entity relationship diagram and I can explain your entire business with no further context. Easy money!

#7. Gimme options, damnit! I’ve watched a lot of Star Trek. Maybe an embarrassing amount depending on your perspective. Inevitably, when the crew is trying to work their way out of some harrowing pickle, the Captain (who’s your favorite?) asks the bridge officers for their recommendations. Always plural. Laying out a broad variety of different options is a key component of problem solving and helps you in many ways.

• Asking for options helps you gauge the level of understanding of your team; a team with deep understanding will bring lots of options to the table.
• There are indeed such things as bad ideas. But a “bad idea” still has a lot of value — just agreeing upon what makes the idea bad helps everyone understand the problem at a deeper level; and often there are kernels within that bad idea that have just enough goodness to drift into the eventual solution.
• The option you pick sets you on a path, but that path is unlikely to be a straight line — and having previously discussed lots of options will positively influence your ability to course correct down the line.

There’s also an art to the choosing. People (especially senior people) hate being told what to do. Choosing the go-forward option (notice I don’t use the wording “the right option”) has to be a collaborative decision, or it’s toxic for the organization. In my experience, many decisions are similar, but the option blessed by the prickliest architect will get deployed without friction while an equivalent option that produced a negative reaction from said architect will gum the works.

A word of warning: stay away from artificially manufactured Goldilocks or Decoy Effect tri-option layouts (i.e., a nonsensical idea + a valid idea + an impossibility). The rote exercise of picking a predetermined middle path has no real value.

#6. Ditch the “dunno”. As an empathetic leader, you always want to build a team where it’s safe to say “I don’t know”. Heck, even I know that I don’t know more things than I do know. But, it’s sometimes too easy for people to close off conversations merely by saying “I don’t know” — and it can be frustrating to ask team members important questions and repeatedly be stonewalled at a dead end. Next time it happens, blame yourself, because you’ve failed to build a team with expectations of broadly understanding the systems and concepts beyond an individual’s remit.

• Does your front end engineer know how the data gets to her code?
• Do your data scientists know how the systems and services they work with are architected or deployed?
• Do your backend specialists understand what the customers are doing when they use your API?

I know that it’s not possible for everyone to know how everything works… but you need to create a culture where everyone aspires to know everything. It’s your job to help people get out of their swim lanes. Enhanced, broad knowledge of the platform greatly helps individual productivity and quality, it fosters new ideas from new sources, and helps people build their careers both deep and wide.

Next time you ask a question and somebody says “I don’t know”, don’t let them off the hook. Try this: “hey, let’s find out together, and then… we’ll both know!”

#5. Fix bugs with the think method. Controversy alert! I posit that the overwhelming majority of bug hunts don’t need instrumentation, breakpoints orstack traces. See, experienced engineers already know what causes bugs: unexpected input, unhandled state, memory issues, race conditions, etc. Experienced engineers also know that bugs aren’t really random — ask anyone I’ve worked with about my age old quip: “it may be a bug, but it’s definitely not magic”. So, before your team digs in to any hardcore bug tracing, teach them to try my (un)patented think method:

1. Carefully inspect the code around the bug area cerebrally and make sure you understand exactly what it is doing line-by-line.
2. Work backward. Mentally explore the ways in which the code you just read could have even conceivably created the condition.
3. Disregard the highly improbable cases and attempt to recreate the specific problem mentally based on your educated intuition of the most likely code-flow that results the error condition.

Dollars to donuts, you’ve got your bug. Many times, you can make a safe, speculative fix right then and there. You’ll be shocked at how often this works. As you’re beaming with pride for being hailed a genius, don’t forget to tip your cap to old Professor Harold Hill (the think method), Sherlock Holmes (powers of deduction) and William of Ockham (the most likely answer usually is).

#4. ABC. Always be Coaching. I have always liked Marcus Buckingham’s management book First, Break All the Rules — a distillation of a massive study unearthing the key components of being a great manager. If you haven’t read it, you should at least review the 12 questions for measuring employee engagement. Whenever I ask my team what it takes for them to be happy at work, there is inevitably a tremendous degree of overlap between their answers and those questions. Creating an educational culture at work fills the needs proffered in Question #12 (“Have I had opportunities at work this last year to learn and grow?”) — learning makes people happy — but it’s more than that: a team-wide learning ritual creates shared experience bonds, provides cross-training, improves presentation skills, piques personal interest, and allows you to hire for talent. People with talent can learn the skills they need. Simply put, a learning environment creates the proverbial rising tide that lifts all boats.

With my last team, we called this Software Congress, and every Friday, we rotated leading the team through a variety of content. Some examples:

• code tours
• vendor offering or tool shootouts
• refresh of educational/academic concepts or new research papers
• cloud architecture reviews or ‘what’s new’ explorations
• cost & spend analyses
• feature reviews aka “how it works”
• prototyping future tech
• abstract concepts (like a very memorable detour called “what even is color?)

Whatever topics you can find, give it a shot. And remember, you might be a manager, but you can be a player-coach too: when it comes to setting the schedule, be the change you want to see — you go first!

#3. Do Something. There’s a famous scene in the 1999 sports movie “Any Given Sunday”, where Al Pacino gives a speech to to motivate his football team to fight inch by inch for the win. There’s a less famous speech earlier in the movie I always liked better, where they are finding themselves getting whooped in the first half: “Defense.. here’s what we’re gonna do. I don’t know, but you gotta do something out there. You gotta make it happen.” Amazon calls this core principle “Bias for Action” but I always preferred “Do something”. Paralysis by analysis is a real thing, so never let the train come to a full stop… make a decision and push forward. Most decisions are reversible anyway.

When you’re hiking, sometimes it’s hard to see the right path from a valley, but if you climb a little, you can see multiple viable paths spread out before you. Engineering is the same way… keep the team moving and find your way to the right path. Stop at the top of each hill and look ahead and adjust on the fly.

Caveat: If you’re writing the type of software that lands airplanes, transfers money or keeps patients alive, make sure action stays within the guide-rails of your quality assurance process.

#2. Build systems, not features. It’s easy to get trapped on the hamster wheel of building just-in-time features to (potentially) unlock that elusive next sale, get the next demo or enable a new customer segment. What I’ve found is that these type of bread-and-butter feature requests repeat themselves over and over again for incremental gains. Incremental gains are good, but expontential gains are better. Break the cycle — take a step back and ask yourself, “what can we build that will lever up the whole company?” The answer is: build systems.

• Instead of building a grid, build a method and subsystem for quickly deploying arbitrary grids via configuration.
• Instead of deploying an ML pipeline, build a subsystem for gluing model logic into a configurable pipeline package deployer complete with all the good stuff: telemetry, error handling, observability and endpoints.
• Instead of onboarding a customer, build a wizard that allows a customer to onboard themselves.

America’s industrialists probably had the right idea: why build a car, when you can build an assembly line for car building?

#1. Push out the jive, bring in the love. The average person works about 90,000 hours in their lifetime. That’s 40 hours a week, 50 weeks a year, for 45 years. Sounds terrible, doesn’t it? But, what if you could have fun for those 90,000 hours? Sounds pretty amazing! When people say “it’s not supposed to be fun, that’s why they call it work,” I think they’ve got it all wrong. Over my career I’ve stayed for long stints at a few jobs and the reason is pretty simple: good people, good projects, good times.

Teams with high retention are often high performing. Retention and loyalty stem from people liking their job and their teammates.

As an engineering leader, the number one way to grow an exceptional team is to take responsibility for bringing joy to the workplace.

It’s not easy… engineers are often introverted, and the world is getting more remote-work oriented. There are 3 tricks to making work fun:

1. Acknowledging that making it fun in the first place is an important part of your job.
2. Recognizing that “fun” means different things to different people: for some people, a happy hour is their worst nightmare.
3. Understanding that just like software features, incremental baby-step micro-joy as a culture is easier than some kind of episodic forced “big bang” of fun.

Too abstract? Here are some practical ideas: convert inside jokes into custom emojis, mini-celebrate the holidays of the different cultures on your team, get boba, have quiz competitions, build a dad joke bot, vote on flavors, smash physical things, build forts, 3d print desk trinkets, task races, board games, hidden talent showoffs, shared music playlists, costumes, raffles, recurring awards, walls of fame, volunteer together... the possibilities are endless. Did I mention getting everyone boba? 🍹

If you find yourself thinking “work is not fun lately”, you should immediately follow that thought with “I’m not doing my job well”. Get back on track with smiles and laughter.

I committed to the top ten list format, so I’m going to stop here. I’ve used these tips (and many others) to build the engineering organizations of multiple successful companies. If you found this interesting and want specific help implementing some of these suggestions, or need other team and technical guidance such as cloud architecture, data operations and exit-readiness feel free to reach out. I’m available for fractional CTO and engineering leadership advisory through my consultancy: CTOversight. Feedback welcome!