Getting Sh!t Done Without Doing It Yourself: Part 1

There’s a common career progression in this technical industry. You come in wet behind the ears as a junior developer, whether front-end, back-end, infrastructure, or even security. After a few years, you lose the “junior” from your title, and after a few more years, you gain a “senior.” You might become a team lead after that with some light duties around oversight and overall team delivery. But then you’re promoted into some role with "manager" in the title — engineering manager or software development manager or something similar. Suddenly, you’re in a position where it’s pretty easy to prove out the Peter principle. Wikipedia summaries this principle, coined in a 1969 book, as follows:

“The Peter principle is a concept in management developed by Laurence J. Peter which observes that people in a hierarchy tend to rise to 'a level of respective incompetence': Employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.”

Skills as a successful software engineer in no way prepare you for the duties of management —and not just any kind of management, but people management. There are so many ways this goes wrong that a million and one books, articles, training programs, and Substack posts are out there to help people figure out how to become better managers. 

So why this article — and why me?

Though I’ve worn many hats in my career, for most of it I should have had the title “reluctant manager.” Management?! I’d rather slit my throat. Can’t I just do it all myself? Maybe you’re not like me and have always wished for minions around to do your bidding, but you’ve found they’re a little harder to, well, manage, than you expected.

I’m Amanda Kabak, Founder of Verdant Work, and I’ve been in the industry for over 25 years, spending the last decade of that in startups and ending as the CTO of a clean-energy software company. I’ve built and managed teams with limited resources and varying degrees of naivete, but I learned how to lead disparate groups of people to repeated successes in delivery while maintaining good retention and a sunny disposition. This series of articles is specifically geared toward technically minded people who have found themselves in the limelight of team or department management and need some straightforward and pragmatic help to excel in this role as you had done as an individual contributor.

What Is Management?

One of the core tenets of all effective management is clear communication, so let’s make sure we’re all in agreement as to what we mean when we talk about management. For me, if I’m feeling cheeky, which I usually am, I think of management as the title of this article: "Getting Shit Done Without Doing It Yourself." But, seriously, Merriam Webster so helpfully defines it as “the conducting or supervising of something (such as a business).” What about “facilitating the work and professional maturity of those who report to you”?

Is everyone familiar with Maslow’s hierarchy of needs? In management, I focus on the bottom two layers: physical needs and safety, with a touch of the next one, belonging.

I have to admit that physical needs and safety are partly metaphors, but they’re really good metaphors as well as being concretely accurate as well. 

Physical needs: do they have the right equipment? Do they feel comfortable talking to people inside and external to the team? Do they have proper bandwidth and aren’t freezing for sweltering in an out-of-the-way corner of the office? Are they sick and need to take the afternoon off? It’s as easy as that. Ask how they’re doing. Introduce them around. Sit in on a few meetings. Make them log off when they’re hacking up a lung or have brain fog from allergies or sleep deprivation.

Now safety, on the other hand, is a little more complex. There’s a physical component to it, yes — but I’m largely concerned with a feeling of security. Can they ask questions? Do they feel empowered to make decisions? Do they fear punishment for doing something wrong? This kind of safety is key to continued performance and growth.

Finally, belonging. This one is less concrete than the other two, but the other two enable it to happen, just like in that triangle. If you want a hokey word for it, I would say that we’re looking for synergy: getting more out of individual parts when they’re together. Do you facilitate a feeling of camaraderie on the team? Do team members actively ask for help from each other or you? Do you acknowledge wins and learn together from losses? I’ll touch on this more later, but, remember, you can’t have this if you haven’t met physical needs and safety first.

Context

Everything in life has a context, which means nothing happens in a vacuum — everything happens within, next to, or during something else. In literature, there are schools of criticism that not only dive deeply into the words on the page (the what) but into what was going on while it was written, the politics in play, the social mores, the epidemics, and wars. This is all context — and guess what? When you give someone a task, there’s a context to it, whether you divulge it or not, and this context is critical for everyone to understand.

“What,” alone, is insufficient. Think about the game of Clue, if that’s not dating me too much. Colonel Mustard in the Conservatory with the candlestick. For a story to be complete, it’s not just about what. It’s about who, where, and most importantly, why. What is the business perspective of the task you’re assigning? Who are the customers that need this feature? Why do they need it? How do our competitors handle it? Where does it sit on the larger roadmap? How does it potentially relate to revenue targets? In many cases, users pay your salary, and you and your team are likely one of the most expensive things in the company. Don’t forget them, and don’t let your team forget them.

Is everyone clear on how this task relates to others that are happening at the same time? Do they understand where this piece of functionality fits into the larger flow? Are they aware of upstream or downstream integrations they may have to take into account for timing and compatibility? Think about an assembly line: each step is dependent on the step before it is completed successfully and to specification, and the step after this one expects a certain outcome before it can begin.

Another kind of context is in your team’s history. It can help to point out things you’ve done before that are similar as well as those that are different. These can provide concrete frames of reference for the work you’re assigning.

Document the Details

Details are an essential part of good communication. First and most importantly, what is in or out of scope? Let me tell you something: scope is not like Schrodinger’s Cat. You need to know what’s in that box before you open it. If it’s your team member’s job to find out, then that’s a task in and of itself. And, guess what? What is in or out of scope needs to be documented somewhere outside your head, their head, or the business owner’s head.

What do I mean by document? I mean something tangible and complete. I don’t care if it’s a Post-It note or a printed and bound novel, though I would caution against both. The key here is that multiple people can point at it and be looking at the same thing. But be cautious about handing over dense blocks of text. Diagrams are awesome, maybe throw in a table or two where it makes sense. Bullet points can help delineate text to make it more digestible; numbering the list facilitates fast referencing for discussion.

Look at these two pages. Which do you think is easier for people to digest? Right. The second one. Bullet points are powerful, images are even more so. You know the old adage that an image is worth a thousand words? This is especially true in requirements. You don’t want everyone to have a different picture in their mind; the only way to avoid that is to put the picture on the page.

Whatever you do for your documentation and wherever you store it — your GDrive, SharePoint, ADO, Jira, GitHub, the closest conference room — be consistent. Define a set of standards and then use them. Standards not only help organize, but they make the content easier to absorb and can help you ensure everything is complete. If you’ve got a blank space for security concerns in your template, you might remember to ask about it. . . and it might even get implemented.

The Definition of Done

For any task, you need to know what you’re doing and hopefully why, but you also need to know when you’re finished. Done is this nirvana that never lasts, but for the brief moments we’re there, everything can seem worth it. You could think of it like a home improvement project you’re contracting out. If the contractor wants 50% in the middle of the project and the rest when it’s complete, you’re all going to agree that once the plumbing is roughed in and the tile is up, you’ll pull out your checkbook. That 50% mark has to be defined.

The definition of done can be thought of as just another tool of communication. Why are increments of doneness important — besides contractors getting paid?

1. They enforce agreement. If everyone knows where a task is supposed to end before it starts, we can all focus on the work and not on trying to patch up mismatched expectations. Let me say it this way: if someone doesn’t know what’s expected of them, how can they possibly succeed?
2. They enforce process. If 75% of your tasks have a common set of items that must be completed — tests, for example — you can automate these requirements and make your tool require them. People will get used to including them pretty quickly if the PR can’t be made or the build fails. Steps of review and approval should be in place where appropriate.
3. They promote quality. Think of what doneness should look like for this task. What about tests? What about documentation? What about review? Think of all those things that we say we’ll do later “when things slow down.” What if we require them from the start? Because it takes too long? How long does it take for us to fix integration or production bugs or not understand why something was implemented in a certain way?
4. They communicate progress. If something is actually done, meeting all the criteria of doneness, you can. . . call it done! You can communicate that this nugget of business value has been achieved, and you can see where you really are in your project because of it. If something is almost done or kind of done or done except for this one thing, guess what? It’s not done, and you shouldn’t claim credit for it, no matter how much you might want to. It’s the painful truth. Finished, done, is a binary state, which means if it’s not yes, it’s no.
5. They enable a feeling of success. If our work overall is never done, when can we ever have that pizza party? I’m serious. If we are on a hamster wheel of never-ending sprints and continuous releases, when are we supposed to feel satisfied and take a breath? I’m serious about this, too. A long grind induces burnout, which brings about turnover, which loses the company money on retraining and kills days of your time in interviewing and onboarding.
6. They provide moments of reflection. If something goes wrong with a task, everyone knows it by the time you get to done, and you can disseminate that knowledge across the team quickly and make adjustments so it doesn’t happen again — even in the same project, maybe even in the same Sprint. If something goes really right, it’s an opportunity to see it and respond to it right away.

So much goodness in true doneness. That’s why one of the most important aspects of this is that you cannot compromise on your definition of done. You just can’t. If the buck stops at you, why would you want to? Because you’re under pressure? Who isn’t? Making sure things are done the right way by people on your team is a lot of how you add value to your company and earn your salary. What makes it easier to do is knowing how critical it is and what happens when you start to compromise.

Incremental Conclusion

There’s more to management that I’ll cover in the next installation in this series, but let’s review what I’ve covered here before moving on with your day. We defined management as “facilitating the work and professional maturity of those who report to you,” and showed how it could be considered in terms of Maslow’s hierarchy of needs. We then dove into the concept of context, all that stuff that exists around individual tasks that is critical to communicate to your implementers. Documentation, especially in terms of details, came next with some ideas about how to organize and communicate things on the page or screen. Finally (and fittingly), we covered the definition of done and how having one is critical to almost every aspect of delivery.

Stay tuned for the next article, which will cover deadlines and protecting your team’s time, understanding the handoff points of your tasks, communicating doneness over time, promoting dialog through questions, and overall mentorship.