Engineering Management ×12
For a large part of my career, I was an individual contributor. That involved project and working group management, as well as people management, but I had largely focused on technical leadership. In 2018 that changed, and I prepared to fully switch into a management role. After sum.cumo hadn’t offered a management perspective, I completed the transition when I joined Jimdo as an engineering manager.
In my work as an engineering manager, it’s also interesting to look back at the experiences with my own superiors. During my time at Google, I may have had my best managers (googliness), but to this day, I feel inspired by the leadership team at OPEN KNOWLEDGE as well, where I worked from 2001 to 2003. I believe that great managers produce other great managers.
But what has influenced me as a manager, what have I learned about management, what about leadership, and what do I stand for as an engineering manager? 12 ideas.
- “Competence, Caring, Conviction”
- Think “What,” Not “How”
- Have a System
- Focus on the Process
- Lead by Example
- Be There for Your Team
- Keep an Eye on Team Health
- Manage Up
- Stay Humble
1. “Competence, Caring, Conviction”
A more tangible reflection of googliness, Jim Mattis’s leadership mantra has fundamentally inspired and guided my own work. (Great book: Call Sign Chaos: Learning to Lead.) You need to be competent in your work, and improve your work on a regular basis. You need to care about people, their well-being, their development. And you need to have and display your values.
When we see leadership fail, then it’s usually in one of these areas: They don’t appear competent, they don’t care enough about people, or they stand for little.
2. Think “What,” Not “How”
I don’t know anymore where I picked this one up: For a manager, it’s more important to focus on what is being done, not how it’s being done. The “how” can and should be left to the teams. It’s where their self-organization starts. It allows them to make decisions (and mistakes). It also frees up leaders from getting pulled into time-consuming details for which there usually are a good number of valid options.
I still need to remind myself of this (as a developer, I do have my views on “how” things need to be done!), but it’s much more useful, and much more economical, for me to focus on the “what.” The micro-managers and those managers who appear constantly stressed or upset are often those who violate this principle, and who would benefit greatly from just focusing on what is being done.
3. Have a System
“Organization is not everything, but without organization, everything is nothing,” my former CS teacher used to say. (I dedicated The Little Book of HTML/CSS Coding Guidelines to him.) I don’t think you can sustain your work as a manager without some form of organization, without some form of system.
What system would that be? Your own. You need to identify what works for you. But as unspecific as this sounds, there’s of course help. An excellent book and classic around work productivity, David Allen’s Getting Things Done is a great start. After reading the book many years ago, I sat down looking through the key points to come up with a system for how to organize my own work. The pillars proved incredibly useful and still persist; some of them I hinted at in earlier writings, like doing, delegating, or deferring work, as well as using reminders (though I use them differently and excessively).
The point is, a manager needs a system to reliably do their work—and to have a chance to free their heads.
4. Focus on the Process
You can’t do everything at once. There’s no “perfect,” either. You can understand managing and leading as a process. For many, this comes natural. For others, it’s difficult—either they’re hard on others, that these haven’t accomplished a result yet, or they beat themselves up, for not having achieved a result.
It’s important to be clear that everything’s a process, because it is:
- Building features is a process.
- Improving a code base is a process.
- Improving tooling is a process.
- Training a team is a process.
- Mentoring and coaching are a process.
- Building relationships is a process.
- Most everything is a process.
This gets useful when you plan and prioritize, or change plans and priorities. The fact that much is a process, that much can be iterated on gives leeway: You can cut things out or squeeze things in, you can prioritize and de-prioritize things, you realize that it’s fine that some things aren’t done now, because they can be done tomorrow, or the day after. This, however, should not serve as an excuse: You still want to keep your commitments. (And to get help with that, you use a system.)
5. Lead by Example
An important quality quality to acquire is to lead by example. That’s all the more crucial as a manager. Are you competent in what you’re doing? Do you treat people respectfully? Do you pay attention? Do you give credit? Do you invest in others, in yourself? People notice.
Do what you expect from your teams, and don’t hesitate to get your own hands dirty. Lead by example.
As a leader, as a manager, as an engineering manager, you need to communicate. You need to be able to be concise but also to give context. For leadership communication, under-communication (communicating too little) is worse than over-communication.
Over-communication, in fact, is important to make your objectives known and to enable everyone to self-organize and run with these objectives. You really don’t want co-dependent teams and peers that need to clarify each and every thing with you—you want teams and peers who are crystal-clear about the purpose of the mission. This empowers them and, by extension, frees and empowers you.
Communicate early, communicate often, communicate clearly, repeat to get through to everyone, give context, give the vision, communicate.
I looked through the books I read about communication, and Harvard Business Review’s On Communication is one good option to learn more.
Another point is to delegate, and to actually delegate. I believe you can’t and you don’t want to do everything yourself, but I’ve seen peers try that. If something’s important to them, they do it themselves, or monitor (micro-manage?) it closely.
In a way, we’re at “what” and “how” again. If you dive in so deeply that you’re worrying about “how” something is done, then perhaps it also becomes difficult to delegate that work. Increase your altitude, and focus on the “what.” Give that to your team, and take care of other priorities (like the people that make your team).
Is this a real management idea or tip? I’m not sure. But trust is fundamental, and if there’s one thing that can interfere with the smooth handling of our work and the smooth operation of our teams, then it may also be trust-related. Or mistrust-related.
As trust is so fundamental, I don’t think I need to elaborate much more here other than sharing an observation: You can decide to extend trust. You can decide to trust your team, you can decide to trust your peers, you can decide to trust your superiors. (You can also decide to mistrust them. Life is about making choices.)
I had a career moment just a few months back when I had to do exactly that, extend (additional) trust. I’m not sure it was the correct choice—I don’t know—, but what was clear and helpful to me was to deliberately choose to extend my trust. You can do it, too.
9. Be There for Your Team
As a manager, you want to be there for your team. You don’t need to and probably can’t spend all the time with your team, but it’s important to maintain contact and to be available. Things that I’ve found useful for being available:
- having weekly 1:1s with every team member (30 minutes), which can be used for any topic, and that can be extended if need be and if possible;
- attending standard team events like dailies, reviews, and retros;
- making room for additional team events like team coffees or game evenings;
- emphasizing (and repeating) availability for anything that could be of importance for a team member.
It’s rare that someone has taken me up on the option to have extra meetings for something, but I can’t tell whether that’s because of there being no reasons for it, the frequency of standard 1:1s,—or perhaps a power distance of sort.
I noticed, however, the extreme value of attending team dailies, after I had, for a few weeks last year, opted out of them. It was astonishing to observe the distance that created, both from a human and a work perspective. Rejoining the dailies allowed me to reconnect with both the team and our work.
Important, to me, is the part about being there, at any time, for any topic. I see annual reviews and such as a safety measure to make sure that certain topics are being covered, but not as the sole opportunity to talk about the respective topics. I strongly believe that a topic worth discussing should also be discussed when it matters, with anyone.
10. Keep an Eye on Team Health
Team health is an interesting topic, and I’m not sure I have a full grasp of it yet. It’s important in itself, and it’s important for my work. When I had previously focused on the “feeling” of a team being of good health, I later adopted a version of Spotify’s Squad Health Check model (hat tip Nadja Macht). I created a Google form with all the relevant entries (on a 5-point, not 3-point, scale) that I sent out every month, to discuss the results with the team.
While I’ve found this to be so helpful that I’m investing into the system to better monitor the development for each area over time, I can’t say this is “done” yet. Surveys like this are a bit “sterile” for something as wonderfully dynamic and alive as team spirit. Yet the point is, watch your team’s health.
11. Manage Up
While it can happen that we end up in so many meetings, with so many priorities, that we lose touch with our teams, we can also end up out of touch with our superiors. Managing up—establishing strong relationships and exchanging expectations with our superiors—is therefore also important for our work.
I’ve had mixed experiences with this, but they’re mixed largely for personal rather than professional reasons. If you don’t get along, if you don’t “click” and connect with your manager, let alone if your manager disrespects you, that’s a problem. Work on that—and if it doesn’t improve, leave. I can’t offer better advice.
Yet the point here is to work with your manager, and their manager. Establish a good working relationship. Set expectations. Don’t wait too long to raise concerns (I’ve made that mistake).
12. Stay Humble
Finally, for this collection of thoughts: Stay humble. We’re all the same. We’re all humans. We all have needs and desires. Where anyone is on the organizational map doesn’t determine their “worth.” The org chart is only a snapshot of people’s professional choices, seen through the distorted lens of the economic value system. Tomorrow’s snapshot can look different. Life’s snapshot does look different. Be humble, and be human.
❧ I could go on: Have an impact beyond your team; don’t give up on anyone; keep an empathetic distance; &c. pp.! It’s all about people, and that’s the beauty and challenge of management. Let’s continue with this.
Figure: Leadership, again. (Copyright King Features Syndicate, Inc., distr. Bulls.)
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe of interest to you, too:
- Next: Upgrade Your HTML III
- Previous: HTML Concepts: “Body-Ok”
- More under Engineering Management, or from 2021
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.