Guidelines for Respectful Use of AI

As companies adopt AI tools, a lot of time is spent on thinking about AI policies from a security, compliance, or even cost-focused angle. But many leaders are neglecting to address how their teams should work with AI in the context of the team as a whole. This creates a lot of unresolved tension, and it’s time for leaders to step up and set some guidelines not just for how to use AI in an “approved” sense, but how to use it respectfully.

When I say respectfully, I am not talking about the baseline appropriate workplace behavior (bullying, abuse, harassment, etc). Instead, I’m concerned that many of us haven’t considered that the ways AI can make an individual more productive (literally enabling them to produce more outputs) can have an overall negative impact on the team’s productivity. Leaders can’t just sit around and expect that their teams will know that they can’t just produce slop and send it to others; if you haven’t set up a thorough policy yet, here are some suggestions on what to cover.

Elements of Respectful AI Use

Don’t ask someone to read/review what you haven’t read or reviewed yourself.

This is one of the most common frustrations I hear amongst people working on AI-heavy teams. Whether it’s code that the owner didn’t really bother to understand before submitting for review, or documents that they generated and didn’t bother to read, too often people try to steal productivity from their colleagues by streamlining their production of work while asking their colleagues to do all of the quality control themselves. It’s great to have a loop of AI code generation -> AI code review -> AI fixes -> final human review, but if the person prompting the AI doesn’t bother to review that code first, they’re putting a huge validation tax onto their teammate, who has to trust both that you prompted well AND that the AI understood the context and problem well enough to get a sustainable solution.

Documents are an even bigger temptation than code, because AI is so verbose and most of us hate writing and editing. It’s easy to get into a loop where you ask the AI some questions, skim the answers, output a document and send it to others. I’m guilty of this myself! But what makes sense when you’re skimming one answer at a time may not make for a good overall document, and there is a big difference between answering individual questions and writing for a human reader. In particular, the context that you have in your own head as you are talking to the AI may not come out at all in the document; if you don’t bother to read it thoroughly before sending it out, you won’t catch the gap in framing.

Even worse, sometimes people don’t even understand what the document they prompted is trying to say. Can you describe this document, and have a conversation about the concepts it presents with others and why it makes sense? If not, you have no business sending it along without at minimum the huge caveat this is AI-generated and I still don’t really understand this space, please help me.

Many people have reached the point where they won’t read something a person didn’t bother to write themselves, and who can blame them when so many don’t even bother to read their output before sending it on?

Shorter is better.

Part of the annoyance of reviewing AI-generated work is that the AI can be painfully long-winded. AI code often looks like tutorial code, with much more verbosity than human developers would bother with. Add in the temptation to one-shot big changes rather than thinking about how to break the code down into pieces, and you can end up with stacks of thousand line pull requests. The documents AI produces are so thorough that something that should be 3 pages turns into 10 or 20. And for those who have fully embraced AI for all of their text-based interactions, you start to see the LLM-generated wall of text chat messages or emails.

This is, frankly, just rude. It goes hand in hand with not bothering to review your own work, but even if for some reason you convince yourself that you really did read and edit that giant PR/document/message, you’re still asking so much more of the audience than you probably put into the exercise in the first place. When it comes to code, I encourage you to honestly ask yourself: if this broke at 3am and none of the AI tools were working, would you be able to look at the PR context and the change and debug it? If not, it is probably too much. When it comes to a big document, at a minimum, have you at least summarized the important points up-front? If someone is just going to ask an AI to summarize the document themselves, you should probably do more work to provide that value before handing it off.

Finally, if you’re writing long-winded emails or chat messages with AI-assistance in order to painstakingly try to explain something, perhaps you actually need to have a meeting or call instead. Increasingly long text exchanges have always been a sign that people need to stop and talk face-to-face, and AI logorrhea hasn’t changed that.

AI is not an excuse to turn off your brain, or your heart.

Signs we’ve switched off our brains and our hearts include: not reviewing the AI-generated work, not taking the time to do human editing, not breaking the changes down into chunks, and avoiding real conversations through AI-mediated text exchange. This guidance is about respectful use of AI because if you have empathy for your colleagues and respect for their time and skills, you will show them the courtesy of giving them work that you are proud of, that you stand behind, that you have thought through and can explain. The AI may have produced a lot of the output, but you thought about all of the pieces that needed to be done, and used the extra productivity to make something better: more reliable, simpler, well tested, whatever. If you find yourself not thinking at all and just mindlessly prompting, accepting output, and moving forward, it’s a warning sign that something is wrong. Perhaps take some advice from Vicki Boykis on adding friction to your development process (or whatever the equivalent is of your day to day work).

Framing these guidelines

If you decide to do this, one final tip from me: assuming your company has some sort of company values, it’s always a good idea to call back to these values when you create policies and guidelines like this. It’s one thing to abstractly say that shorter is better, but if you can tie that to a value for your company, it will resonate more strongly. As an example, if I were at Amazon I might consider tying “shorter is better” to the leadership principle Invent and Simplify. And since shorter is better and this is already too long, I leave you here.

This post is 100% human-generated except that I needed a spell-checker to spell logorrhea. Maybe I should’ve used an AI editor, feel free to tell me if you think so!

Enjoy this post? You might like my books: The Manager’s Path, and Platform Engineering: A Guide for Technical, Product, and People Leaders, available on Amazon and Safari Online.

Revisiting Manager READMEs

Several years ago, I published a critique of manager READMEs that succeeded in stirring up a lot of feelings, pro and con. I’d like to believe it prompted some people to reconsider whether these are actually effective tools.

Today, I want to revisit this. Not to encourage you to write a manager README, but to suggest other ways forward that I have learned in the years since writing the first post.

The Problem

When you become a senior manager or an executive, you face new challenges. Your job involves directing work across many people with different approaches, styles, and opinions. Left to their own devices, each person will develop a slightly different way of communicating with you, one that works for them and that they believe works for you.

With a broad scope of work to oversee, you need to quickly grasp what matters and should be shared upward, outward, and down into different parts of your organization. Now, at most companies, this is a known problem and inevitably someone has already tried to solve it by means of standardized tooling and reporting. Everyone uses Jira for a reason and it’s not that Jira is the best tool ever, but it is malleable to many types of standardization. Companies implement OKR tools and Tableau dashboards, they institute various program management processes, they run quarterly business reviews, and all of these are done in the name of standardizing the information that is passed upward and outward so that people can make better decisions.

Unfortunately, this is typically the lowest common denominator of usefulness to any senior manager. Reporting generated in this way obscures as much as it reveals, and it rarely addresses the things that you really care about¹. So senior managers need other mechanisms for imparting what they want to hear about and see. The README can sometimes be an attempt to impart that cultural overlay: a way of saying, “I care about X, and want you to focus on that when you communicate to me; I don’t care much about Y and Z, and by the way, it’s best if you communicate with me in these ways.”

I remain steadfast that this is not a good approach. It creates a focus on you as the person to be managed up to. Your personality must be accommodated, your preferences honored. I get the desire for this, and I’m certainly not immune to being managed up to, but my preference is to avoid major blind spots. I want to hear what I care about, yes, but I don’t want to live in an information bubble either.

READMEs are also rather lazy. There’s a kernel of truth in their purpose: we want people to focus certain types of communication on what we believe is most valuable. However, doing it in the form of a general README isn’t actually the most effective approach.

So if not READMEs, what then?

The Solution: Appropriate Templates and Ceremonies

Instead of one doc that attempts to communicate all of your preferences and warts and creates a you-focused mindset, it’s time to level up and recognize that a big part of the job of senior/executive management is setting standards for doing certain types of work. The best way to set those standards, in my experience, is lightweight templates and ceremonies for information sharing, discussion, and decision-making.

I think that every good senior manager should have some toolkit of these. You aren’t just going to operate against the lowest common denominator of pre-existing reports and processes in your company, you have to establish a few processes that exist to show what you care about and where you want the organization to focus. One of mine is Wins and Challenges (discussed in my recent book), which I’ve brought from startups to giant teams and everything in-between. Is it extra work on top of whatever people might be doing in Jira or other tools? Possibly. Does it create far more valuable conversation across my leadership team than those tools? Yes. Does it help me specifically understand things and do my job better? Absolutely.

There is a very lightweight template to follow for my Wins and Challenges, and the process details are owned by the team gathering the information (although I specify opinions about how it should be done, I only check the outcomes). I find that the best templates and processes are lightweight in a way that they show what information should be collected but don’t dictate exactly the process to collect that information.

Developing templates that expose the right useful information is hard. You will both over-do and under-do this as you’re figuring it out, whether it’s your first time in the job, you’ve moved to a different company or team, or your team has just evolved past the usefulness of the old methods. My advice is to start simple and add on new details or processes only when it’s clear you have a widespread gap. A good rhythm for a new job/team is to learn for 90 days, then introduce what you need, and evolve from there with enough time to learn from each iteration (usually, 1-2 quarters).

Don’t Try To Template/Processify Everything

I recently asked an experienced CPO about good product processes, and what they looked like from his perspective. One piece of advice was that not everything should have a fixed process or template. When you need to leave room for discussion, it’s often best to limit the structure; a walkthrough of a prototype might be better done as an open-ended exploration and discussion rather than a formal set of steps.

It’s important not to give into the temptation (or external pressure) to create processes for everything. I personally do not have a fixed format for my 1-1s, and dislike even the expectation of coming with a set of written and shared topics. I don’t want to feel rushed to finish everything on an agenda, and the temptation to immediately jump to conclusions about a topic based on an agenda item often increases miscommunication. Sometimes there’s a need to pre-read and prepare, but sometimes we just need to talk and see where the exploration of current top-of-mind concerns and information takes us.

So, senior leaders, you can tell people how you want them to work with you, but don’t do it via the crude mechanism of a manager README. Drive clarity through templates and processes where needed, resist the urge to create them everywhere, and lead your organization by showing them where to spend their time and focus as a collective good, not just good for you.

---

¹ Think of it this way, if you could easily see the problems via the pre-existing dashboards, they’d already be on their way to being solved. Dashboards are like alerts and tests in this way, they tend to catch what you know could go wrong, but rarely the surprise problems that lead to big incidents. Necessary, but insufficient.

Enjoy this post? You might like my books: The Manager’s Path, and Platform Engineering: A Guide for Technical, Product, and People Leaders, available on Amazon and Safari Online.

Dude, Where's My Strategy?

I’m working on a talk about rewriting platforms for LDX3 later this month. Spoiler alert: a lot of the talk centers around why rewriting platforms is usually a very bad idea. For more on that you can read the rearchitecting platforms chapter of my latest book.

One of the points we make in the book is that, generally speaking, platform teams are not the foci of innovation at companies. Platform innovations often come either by adopting external innovations, or absorbing and expanding platform-like work that was created by internal application engineering teams for their own purposes. I won’t say that it’s impossible for platform teams to innovate, but a lot of the innovation is much more incremental and evolutionary rather than novel and revolutionary.

But this doesn’t mean that there’s no need for strategy in your platform team; on the contrary, platform teams are often the fulcrum that drives important architectural evolution across companies. Pretty much every major change in technology that I have lived through has needed platform-level support: containerization, microservices, event-driven systems, big data, continuous delivery, observability, the cloud, elastic scaling. Many build on one another through the platform, such as containerization making it easier to move to the cloud and moving to the cloud making elastic scaling more realistic. 

This is what strategy starts to look like as a platform leader. You’re watching where the state of the art is going, and thinking about what makes sense to introduce or evolve so that you can take advantage of that over time. You’re not forcing everyone to move from bare metal hardware to kubernetes overnight, but you’re making the tools to support bare metal to virtualization/containers available, easy to use, and cost-effective, to encourage the natural evolution to happen. The larger the company, the longer these timelines will run, and the more that you’re going to have a number of leading and lagging strategies running, but this is the engine of baseline modernization that needs constant feeding to keep your technology stack from stagnating.

“Strategy” and “Vision” are so often conflated in peoples’ minds that this kind of boring but reliable forward progress is overlooked as strategic. But when leaders can execute in this way over years, the application/product teams have that much more flexibility and power to innovate and do interesting things without having to completely go out on their own. So, platform leaders, don’t feel bad if you’re not at the forefront of innovation! You don’t have to drive the next innovation to be strategic, you just need to make it easy for others to get there.

Enjoy this post? You might like my books: The Manager’s Path, and Platform Engineering: A Guide for Technical, Product, and People Leaders, available on Amazon and Safari Online. 

10 Years of Engineering Ladders

 On March 26, 2015, I posted a short blog post to the Rent the Runway engineering blog, Sharing Our Engineering Ladder, with a quick intro to the RTR engineering career ladder and links to both spreadsheet and long-text versions. This was one of the first public engineering career ladders that came with a clear distinction between management and IC levels, and meaningful details about the requirements and expectations at each level.

I published these resources because, at that point, most of the companies that were writing ladders were either a) getting some consultant like Radford to help them bootstrap something, b) copying a big company that they had worked for in the past, or c) stealing a template from a friend’s company and modifying it. For teams without the resources to hire consultants, prior big company experience to draft on, or friends to copy, they were basically stuck. I knew that what we had created at RTR was special, because it had many different sources of inspiration, contribution from a smart team of tech leads and managers, and a lot of care behind it. And as an open source person, I believe in the value of sharing not only ideas but actual work for others to use, build upon, and expand, for the greater benefit of the tech community. Publishing the ladders for widespread use was an easy decision, and one that has had an impact on the industry: I still get occasional thank-yous from people who have used it as a baseline all these years later.

These days, this sort of thing is almost passé. Almost every company has done this work, many inspired by the very ladders we published, but others inspired by far different approaches published over the years. I am proud to have stoked a simmering conversation among leaders in the tech industry. It proved what I always knew: most people want a starting point to play off of when designing organizational processes as much as they want one for technical work. Even if all the starting point inspires is “ew, not this!”, it gives you something to riff off of.

Advice For Writing

I’ve done this exercise again at least twice over at different companies in the past decade, and it’s always a challenge. So here’s some brief advice for those embarking on this process.

1. Don’t let (or make!) HR do all of the work. It’s really not their job to define expertise in your functions.
2. Details matter. Your ladder should be more prescriptive than a horoscope; it’s impossible to avoid all subjective language like “increasing complexity”, “large systems”, “high impact”, but pay attention to where you use that and try to provide ways of roughly measuring this where possible.
3. One great way to flesh out details is writing long-form text to accompany the spreadsheet-style ladder. I think it’s a shame people don’t do this more, even if they don’t publish it, because it helps you envision the work and catch things you might miss when writing bullet points.
4. You should not try to create a ladder that functions as a pure checklist or scorecard that guarantees promotion if people check enough boxes; promotions are as much about the needs of the organization as the skills of the employees.
5. Be honest: not every job family has ladders that start at the bottom and go to the top. Some should start in the middle and go up; some may start at the bottom and only go to somewhere in the middle. Don’t promise people that they can become the VP of X just because some people do job X, and don’t pretend that you should hire people straight out of school into jobs that are specializations that you only take on after years of working as a generalist.
6. Also, maybe you don’t need to create a job ladder for literally every job. There’s something to be said for the finance company catch-all analyst/associate/VP/MD scale to cover everyone, with ladders for large population jobs (such as engineering) where it makes sense.
7. Err on the side of more early-career levels rather than later-career ones. Assuming you are still hiring junior engineers (you really should be even in this AI era), the good ones will learn quickly and want to see career progress in their first few years of working. Once the path splits IC/management, just match the management levels and you’ll be fine.

Are Ladders Passé?

Even as I write this, I’m not sure anyone will care. The industry is in backlash mode, and I wouldn’t be surprised to see many companies try again to make the “flat” organization work. But even with the aid of AI, I’m not convinced that we’ll overcome the human instinct to gather in groups and create leaders of those groups, and fight one another for power of those groups. The Tyranny of Structurelessness has yet to be overcome, and for those who still care about creating strong, transparent, equitable organizations, this work matters. Just please don’t make me personally write them again!

Enjoy this post? You might like my books: The Manager’s Path, available on Amazon and Safari Online, and Platform Engineering: A Guide for Technical, Product, and People Leaders, available now!

(reposted from https://skamille.medium.com/10-years-of-engineering-ladders-329d309000cd)

The Next Larger Context

“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan” — Eliel Saarinen

Frequently we will be given problems to solve by other people. Early in our career, these problems will usually be well-scoped and specific, eg:

• Add this new data to an interface
• Make an endpoint that returns a certain specific calculation or piece of data.

And as we grow as engineers these tasks become bigger but often the success criteria remains well-defined:

• Write a service to manage the state of a customer.
• Create a new interface that allows developers to manage and track the status of their code change from review to deployment.

There are often plenty of decisions to be made in implementing these designs, but we are not identifying the problem to solve ourselves, just building the system to solve it well.

A major challenge that I see many people hit right around the time they become senior engineers is that they want to progress farther in their career, but they expect that the way they can do that is that they will be given a hard problem to solve that can only be solved by the level of technical skill they’ve gained so far. In fact, they expect that the career path from senior engineer to even loftier heights (depending on your company that might be things like “staff engineer” or “principal engineer”) will go much as it has gone up through to senior: you’re given increasingly harder problems, and you get to use your skills to solve them.

I didn’t write The Staff Engineer’s Path because I’m not qualified to talk about a path I didn’t follow. But what I can tell you based on my years of managing people throughout the stages of their career and watching friends who are on the individual contributor path is this: it is exceedingly rare that the path past senior engineer comes from being handed increasingly hard problems. It’s not that there aren’t hard problems to be solved, for sure, but they are generally being solved by the people who were already around on the team when the problem was discovered. And most of us don’t work in research, so the job of exploring the edges of possibility and discovering completely new things is not part of what we’re expected to do. Instead, at the senior levels, we are expected to identify problems that match business opportunities with something that technology can solve.

The blending of these two things, business opportunities and technology, is where you need to turn your eye, senior engineer. But that doesn’t mean you need to become a product manager, or a manager-manager, or even an expert in the business. Instead you should look at the problems you’ve been solving and that your team is solving, and follow Saarinen’s advice: look at them in the next larger context*. Here are some examples.

Current Context: A Bespoke Storage System

Let’s say that you are on a team that supports a bespoke storage system that has been built up over years for your company. You’ve been something of an expert in the internals of that system, how it works, how it scales, you have added some features to it, and you are capable of teaching other developers how to use it.

The next-biggest context to start to understand here is how this storage system supports the company that is using it. Why do you need a bespoke storage system? What are people putting into it? What are their complaints about the system? What are they using it for that surprises you? You need to understand not only the way the system works itself, but the way the people who are using the system interact with it. This gives you the larger context that it is operating in, and will help you see the next opportunities for this area. Is it time to bring in a new type of storage system, one that fits with some of the data your users are producing that isn’t being served well by the current system? You are supporting a bespoke storage system, in an era where companies are trying to move away from bespoke systems in favor of open source or cloud hosted solutions. What does this mean for the future of your system? How can you get ahead of that trend, either by showing true differentiation between what your company needs vs the external options, or by embracing that trend and drawing down the differences to allow the company to eventually move to one or more of the external options?

The lesson from larger context here is that sometimes the advanced move is not to build a more complex thing, but to enable the company to embrace the broader trends in storage systems. But when the right thing is to build a bespoke solution, you will only do that well if you understand why you need to differentiate and how to make the case for that based on the understanding of the larger context around your system, namely, its users.

Current Context: An Inventory Management System

Now let’s take a very business-focused example. Imagine that you are an engineer on an inventory management system. You have overseen the development of this system to account for the nuances of the company that uses it. You understand very well how the operations team thinks about inventory, how they plan to buy new things when inventory runs low, and the kinds of reports they want to see on a regular basis about all things inventory.

The next-biggest context here could be a few things. It could be the entire context of warehouse management. If your company not only tracks inventory but actually manages the warehouse they use to store inventory, they probably have some warehouse management systems that you have integrated with your inventory management system. How well do you understand that world? How does your inventory management system fit into it? Are there opportunities to build out better integrations that could provide more accurate reports for the operations team forecasting inventory needs?

The other side of this information flow of course is the information that you’re getting from the customers themselves. You’re tracking customer behavior in some way, if you’re working in any sort of modern commerce company. Are you automatically feeding information about customer interest in your products into the inventory management system to improve planning? Or, can you use information about inventory management to show to customers which items are about to be sold out?

These questions may sound like product questions, but in many cases they are all about technical challenges. Integrating all of these disparate systems together in an effective way is challenging. Even if all of these systems were developed in-house, they will have evolved at different rates and in different ways, and feeding new data from one system into another can sometimes require that you rethink the entire way the systems work together. If you built your inventory management system to do batch processing, for example, because you never expected that inventory would change fast enough to need real-time updates, you don’t have an easy way to feed information about low stock dynamically to the website. In fact, may websites fake statistics like the number of users buying a particular item because they have no easy way of feeding this information back and forth.

You need to think about the larger context of your system both to identify business opportunities that it could be filling, but also to predict how the technology you’ve built to support the current needs might fail you if you needed to integrate with a new model.

Current Context: A Developer Tools Team

Our last example puts you in the context of a team that supports the tools and processes other engineers in your company use to develop software. You are the person who supports Jenkins, and all of its various integrations, for doing build and test. You know Jenkins inside and out, and have created an impressive set of automation that makes it easy for you to manage a large number of build and test pipelines for the company. However, this project has only been around for a little while and many teams still don’t have good continuous integration processes.

The next-larger context here is one of education. How are people using your product? How many teams understand the power of the automation that a system like Jenkins can provide? Where are there additional places that can take advantage of this system? What would be the blockers for them taking advantage of the system?

By teaching people how to use the system and getting more users into your system, you will start to understand the patterns of testing and integration more broadly at your company. You may identify pieces of support that are missing that would get more teams to be able to release more frequently, such as a good feature flagging system. You may identify that the artifacts you build are huge and take a long time to create, and this could lead you down a path of figuring out how to make those artifacts smaller or faster to build. You may simply identify the need to set up some kind of classes for new developers about how to write good unit and integration tests, so that they can get value from running their code through your pipelines.

---

What all of these examples show is that, as engineers, when we are looking to do a larger project than the ones we’ve done before, we need to step out of the context that we normally operate in. When you look one context bigger, you will see immediate new opportunities that you can tackle in adjacent areas. So don’t wait for the next project to come to you, seek it out by looking at the slightly bigger picture. That is where you will find your growth.

*You look only one context bigger because it is easy to overdo things and violate our “evolve complex systems from simple systems” principle when you try to go too broad.

Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!

The Product Culture Shift

Adding product management to more traditional software infrastructure organizations, sometimes with a shift towards platform engineering, is all the rage today. As someone who has done both these things, it doesn’t surprise me to see so many people struggling to make it work. Both of these shifts require going from a siloed, process, tech-focused mindset to a portfolio, usability, and customer-focused mindset. This is a hard transformation, and it’s easy for people who have spent their whole career building infrastructure to misunderstand what product and platform really mean. So I thought I’d share the secret to making this work.

Your whole engineering culture has to change.

Yes, seriously.

Infrastructure organizations tend to be good at many things. They are good at cost management, vendor negotiations, and running systems at scale. They have specialists who know the murky depths of databases, the nuances of networking, and how to debug nasty kernel issues. They may even be good at triaging bug requests from tens or hundreds of teams, planning large-scale failure tests, and coordinating massive migrations.

Unfortunately, they are not usually very good at thinking about the people who will use their systems, taking their preferences into account, and treating them like customers who they are trying to keep. Why should they? The people who use their systems are a captive audience! As I mentioned in my post about product for internal platforms, this is a major challenge that platform and infrastructure teams have to overcome to build great products.

This culture, with its focus on cost, scale, and process, over people and usability, is very hard to root out. And you don’t want to lose all those rare skills in the process. So what do you do?

You can’t just rub product managers on it and call it a day.

To start, let’s be clear about one thing: as tempting as it might be, just hiring product managers won’t fix this problem. Even if you could find enough good product managers who want this type of job, which you can’t, product managers are only useful when they are paired with willing engineering teams. If the engineering teams don’t feel a sense of ownership for delivering a great product to their customers, product managers are unlikely to close that gap, and they will more likely turn into glorified backlog groomers than true product leaders.

You need to change the way you support your products.

The ticket system black hole is a great way to make your customers feel more like a burden than a focus. I understand that it is hard to manage all the incoming requests for your teams, but taking a close eye to how you provide support, what your response time is for questions, and how you triage incoming issues is critical to this transition. Your engineers should spend time supporting their products. If they are not regularly answering questions, they are missing a chance to appreciate the pain that customers are facing when trying to use the systems. Be careful about making this optional, or leaving it to only junior engineers. Your senior folks will not build the kind of humane products that you need if they are incapable of interacting with the users in a polite and helpful way, no matter how brilliant they might seem. If you have someone you can’t trust to engage productively in help situations, watch out, because this person is probably not building products that are easy to use. Over time, you may find yourself redoing a lot of their work because it is harder to support and drives a high volume of complaints.

You need to update your interview process.

I recommend adding screening for what I call “customer empathy” to all of your interview lineups. This doesn’t have to be deep, it can be simple as asking them how they think about how they write code so that other developers can understand it, or what their approach is to answering questions about the systems they have built. But you want to set the tone that you expect your developers to think not just about how to build the systems, but about the people who are going to use them or work with them.

You need to update your systems of recognition and reward.

If you only promote people who solve big technical problems, you’re going to have a hard time retaining the people who do the work to smooth out the usability edges, actively listen to the customer teams, and adjust their work priorities to fix the stuff that is causing the most pain. So look closely at what you are celebrating, paying, and promoting, and make sure you are including work that makes the product better whatever that looks like, even if it isn’t the hardest technical bits. Remember, this is a cultural change, and cultural changes that don’t involve changes to what is valued when it comes to recognition and rewards are destined to failure.

Do you have too many project managers?

There may always be some need for project managers, but in infrastructure organizations, heavy reliance on project managers can result in a lack of up-front technical planning around one of the most common infrastructure team tasks: migrations. If your migrations are so painful that both your team and your customer teams need project managers to understand where all the dependencies lie and track what is happening, you are not taking ownership of the user experience for your software. Yes, migrations are part of your UX! I am astonished at how often infrastructure teams offer new systems that do not have compatibility with the systems they are replacing, and expect the customers to do all of the work to migrate to those new systems, often on a timeline dictated by the initiating team.

If you are moving to a platform model, you are going to need to own much more of the migration than you have up until now. That platform value add must include lowering the migration pain for customers, which means getting better at doing them entirely yourselves. By limiting the number of project managers now, you force engineers to face project management work that they will not want to do. And the good ones will realize that if they created automation to support the migration, whether it is detection of dependencies, compatibility bridging libraries, or abstractions that allow them to change the internals without changing the client libraries, they won’t have to do so much of that tedious project management work. By saving themselves time, they will save their customers time. So limiting project managers is a good forcing function. Just make sure that you are giving teams time to do this work, and not just making them miserable or shifting the project management onto your new product managers.

Your teams are going to spend more time talking to customers, and less time purely writing code.

There’s no way to shortcut the product mindset transition for your engineering team. You can’t just add a product manager or a customer advisory board meeting once a quarter and call it a day. The team will need to spend more time with the customers, and more time strategically planning for how to address holistic concerns, rather than just triaging the latest set of customer complaints. There will be an up-front cost as you change the way people work. They may complete fewer tickets or other process-oriented measures of productivity, and the pace of work might look slower than it did when they were just churning through a never-ending backlog of tickets. But over time, the work that is produced should be better, as measured by customer surveys, adoption, migration timelines, and eventually, engineering productivity.

Keep it fun!

By the time companies go through this transition, they are often in a deep state of us-vs-them between their infrastructure organization and their other business/product engineering teams. This situation never feels good to the infrastructure organization. No matter how much they may claim outwardly that their users are hopeless or ungrateful (or worse), it is simply not much fun to have an antagonistic relationship with your users, and to feel like you are deep inside of an us-vs-them dynamic with colleagues. So while this transition is going to be tricky, it can also be fun if you let it. Get feedback from your users about what they love about the product. Share kudos as they come in, and take the time to celebrate improvements in your customer satisfaction metrics. Make sure your teams are part of the celebrations when their work enables an application team to do something they couldn’t do before. This is an exciting opportunity, a chance to learn, to modernize your approaches to work, and to create a more positive culture, and leading with a positive attitude will make all the difference in how fun it is for everyone.

Wrapping up

In many ways, this cultural shift echoes the changes that happened during the “devops”/SRE transformation. Engineers in SRE-focused organizations do not build code that they carelessly throw over the wall to an operations team. In the same way, engineers in a product-focused organization do not build software without consideration of the users of that software. These transformations ask more of the engineering teams, but deliver higher-quality outcomes as a result. It’s expensive and takes time but I promise you, it’s worth it.

Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!

Structural Lessons in Engineering Management

Software engineers are attracted to formulas, algorithms, and structures. As people whose job it is to take ideas and turn them into predictable executable code, it is unsurprising that we’re drawn to ways of thinking that categorize and systematize things. This attraction continues as engineers become engineering managers and leaders. I should know, I wrote a pretty popular book that is full of best practices, tips, tricks, and process suggestions to apply to the various challenges of leadership.

However, I think it’s worth talking about the downside of going too far with structural thinking as it pertains to teams and organizations. Let’s take a common area where this structural approach happens, namely that of organizational structures and interactions.

There are certain rules that I believe in, one of which is that engineering managers do not scale well beyond about 7–8 direct reports. It’s hard to keep the context of what each of these people is doing and thinking about in your head well enough that you can effectively guide them. You end up spending an outsized amount of time on management tasks when your direct team size grows much beyond this number; or, even worse, you just start doing a bad job at those management tasks because you don’t have the time to do them well.

On the flip side, many organizations do not want managers who only manage a couple of people directly. Someone who manages only two people is often in a limbo state: are they an individual contributor? Are they a manager? The HR system is binary: if they have direct reports, they must be a manager. But the reality is that if you only manage a couple of people, most of your time is spent doing things other than management. If this person is a new manager, they may not be learning the things they need to learn to grow into a confident managerial role. On the other hand, if this person is and wants to remain an individual contributor, their management is likely to be a bit lacking for these two individuals.

The temptation is to move from these two beliefs into the notion that you must create a clean tree structure for your organization. Each manager manages three to eight people; when a team grows too large you rebalance the tree. All is clean, and easy; our organizational structure works.

Experienced managers know how quickly this falls apart. People quit, and suddenly the manager of 5 people only has 2 direct reports. Managers don’t just drift between teams depending on the immediate size of the organization, they have skills and interests that make them sticky to their group. Individual contributors get rightly frustrated when their manager changes too often, and they prefer managers who have some understanding of their work. The teams need to have some coherence of vision and purpose; hiring is never a steady drip but comes and goes in bursts. Your ideals quickly fall apart when faced with the reality of a living organization and the needs of the people in it, so your trees sometimes have skinny branches, and sometimes very fat ones. The best you can do is try to nudge it back into shape over time, or very occasionally, reorganize into something more appropriate.

Photo by Gilly Stewart on Unsplash

Another failure mode happens when leaders get enamored of applying engineering analogies to define team interactions. APIs are a fine concept but the idea that team interactions can be strictly defined by an API is as laughable as the idea that programmers won’t figure out a way to exploit every undocumented feature you provide in one. In this case, Hyrum’s Law applies as much to engineering organizations as it does to software. Humans will and must talk to each other, trade favors, and negotiate based on changing circumstances. When you are in the thick of trying to get things done, you will use what you can find, whether it’s an undocumented API or an engineer on another team who is willing to lend a hand.

Ironically, a lot of software engineers turned managers believe that they are taking humans into account with these rigid structures. When you see the world in systems, interactions, and efficiencies, you can trick yourself into believing that the humans inside of these systems will be happier if the system is well-organized. While I agree that there is value to organizing your teams effectively, the marginal value that the teams might experience is likely to be offset by the unintentional friction that happens for the people who don’t fit perfectly into your structure. If you don’t work to stay ahead of what the people in your team want and need, if you don’t create growth opportunities or appropriate technical challenges even though it’s not the most optimal thing for the system as it currently exists, you will find yourself losing good engineers and managers. The people in the system are much trickier than you are imagining, and the structure that accounts for their skills and happiness will have organic features as much as centrally-planned ones.

Managing a startup team at a new and growing company can lead inexperienced managers to believe that they can define the structures and processes to be perfectly tuned to what their company needs at the moment. I went through this phase myself, and I know the temptation to allow the ever-changing demands of startup life to justify changing and tweaking of teams and processes and projects in pursuit of the ideal execution machine. While managing a large organization at a more stable company, I’ve come to appreciate the cost and overhead of such a systems-focused approach. When you are thinking in terms of years and not months, it becomes important to accept that you may hang out in imperfect structures for many months or even longer, because you are trying to hang onto people for years.

So, new leaders, read those books and expose yourself to those ideas, but don’t stop there. Listen to your people, and don’t be afraid to break your perfect structures to accommodate their needs. They are your best source of learning, and your most valuable asset.

Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!