It’s a tale as old as (UNIX) time : The gender-neutral protagonist of our story, <Talented Dev Lead™> led a happy, comfortable life. Crushed code by day, learned all about new tech by night, and commanded the admiration of peers far and wide.
One Day <The Powers That Be™> decided that TDL would be tapped to lead a group of engineers. (Or maybe TDL decided that the Coder path was no longer appealing??? I don’t know. The details are fuzzy…)
From that day onward, TDL became know as IHNIWIDM (I-Have-No-Idea-What-I’m-Doing Manager). Our protagonist persevered, and after learning a whole new skill-set and acquiring plenty of battle scars, finally moved up to TEM (Talented Engineering Manager).
And they lived happily ever after.
Or did they?
Ok, let’s get serious now. After moving into the management path for various reasons, it turns out some people not only enjoy it, they are good at it.
As a first-line manager, (Definition: Somebody who directly manages one or more teams of engineers) you are equally responsible for the deliverables of your group, as well as the personal and professional growth of the engineers under your direction.
You have to be skillful in extracting productivity, maintaining the health and well being of your group, and building a harmonious work environment for your folks.
If you do these things right, you will eventually be promoted, and this changes everything (again).
Managers of Managers
Congrats on your promotion! As a second-line manager, (Definition: Somebody who manages groups of managers, and is at least one level removed from individual contributors) your primary goal remains the same: Make sure your deliverables are consistently of high-quality, and on-time. (That’s why you’re getting paid the big bucks now). But the way you achieve this is much more nuanced now.
While you might’ve gotten away with occasional micromanagement before, at this level it will prove difficult. You need to learn how to trust your groups, and allow them to do what they’re good at.
So, we’ve established that you don’t get to play engineer anymore, and you have to sit back and watch other people work. What do you do now with all your spare time?
As engineers, we’ve all worked on, or built platforms. I don’t know what it is about platforms, but we definitely love ’em; so let’s talk about what good platforms are:
A set of capabilities that provide a foundation upon which products and solutions can be built. They enable products to be developed independently of the platform, and are predictable in their usage, development cadence, and operation.
(I’m borrowing this definition from Edwin Aoki, our Chief Architect at PayPal)
As the architect of a platform, your chief concern is enabling others to build on top of the foundation you create. Like any good framework, you want to give freedom, while at the same time, make it difficult for things to go off the rails.
It’s important for platforms to provide operational consistency, because you want to know at a glance if things are working well, and what levers to pull if they’re not.
Building a platform is an exercise in systems design, where the goal is extensibility and scalability. You build a platform so that others can plug into it, and multiply the output of the system.
Oh, and in case you didn’t notice, at no point in these definitions did we mention Software.
As an Engineer, you work on your code.
As as a First Line Manager, you work on supporting your team.
As a Second Line Manager, you work on the systems that will enable FLMs to thrive.
This is where the Management as a Platform philosophy comes in.
As a SLM, you can find yourself in charge of teams in completely separate domains, and to be successful here, you need to learn how to establish the guidelines by which your teams need to function.
You don’t want your FLMs reinventing the operational wheel, and having to spend time thinking about how to work with their teams.
In the hypothetical situation where an entirely new team is moved over to your organization, if you’ve done your job in codifying and simplifying the day-to-day operations, it should be straightforward for this new team to adapt their own operational rhythm to that of the org.
Likewise, if you need to spin up a new team from scratch, the platform-like aspects of your group are going to allow the new team to focus 100% on the problems they need to solve, knowing that they have a proper support structure around them.
Obviously, this is just one pillar of success. There are many other things that you need to do right, but in my experience, seeing yourself as the architect of an extensible system comprised of humans who need to work together is critical to building a successful organization.
Your organization needs to be a place where information flows freely (both up and down the command chain), and though the goals of each individual team might not necessarily be common, their basic needs certainly are.
You need to provide a clear reporting structure, and sound operational rhythms, with a fine balance of uniformity and freedom to account for the specifics of each domain. Ensure that you have systems that guarantee a good work-life balance for your teams, as well as providing space for innovation and experimentation.
A nice side-effect of this set up, is that you will end up freeing some capacity for your FLMs as well. This automatically leads to their growth, since they can focus on higher level tasks. By removing the usual drag and friction teams encounter, you’ll end up with a highly productive organization, with ample room for personal and professional growth.
Look at you! Such a successful and promising leader. Uh Oh… Here come <The Powers That Be™> again…
If you’d like to be a part of my platform, I’m currently hiring! Hit me up on twitter @ Lenny Markus