Managing Your Team's Work

As a new technical manager, one of the key things you need to get a handle on immediately is to clearly understand how work comes to your team. This is a critical aspect of team management for a few reasons. It builds trust with your stakeholders. It allows your team to focus on their tasks rather than get sidetracked or endure rapid context switching. It helps to create the space for your team members to be as productive as possible every day. Whether you inherit a system or create one, having a clearly defined process for how work comes to your team is a necessary first step in delivering value.

Understanding and controlling how work comes into your team helps reinforce your relationships with stakeholders. We have all worked with stakeholders that are never happy; that always want more, faster. This is the nature of our work and will never go away. However, if you have a well documented process for how work comes into your team and you follow it, over time, even the most impatient or demanding stakeholder will develop trust in your team, its estimates, and its timelines. They may not like it and their trust may be given begrudgingly, but it will be earned. This is because they'll learn that when you say your team can work on a task, even in the future, they'll know you mean it and have a track record of doing just that. Even trust begrudgingly given is trust.

Following a good process for bringing work into your team allows your team members to focus on what's important rather than be a victim of too much context switching. Context switching is a fact of life in a software development team, but having control of the work coming into your team helps diminish the switching by making the team's workload predictable. This helps your team members stay on task, gives your stakeholders predictability and ultimately helps increase your team's velocity.

An important aspect of any process for bringing in work to your team is dealing with exceptions. This almost always means having a discussion with one or more stakeholders about priorities. If a really important task arises, you need to be able to have a clear view on how inserting that task into your current plan will impact other tasks already in the plan. This is true for a two week sprint, a quarterly plan, or even a yearly roadmap. It may be a "plan" to you, but to your stakeholders, those are commitments. You aren't doing yourself or your team any favors by blindly agreeing to every new, critical task that comes in. There are consequences to schedules, budgets, personnel and even, ultimately, the health of your team. It's critical that you can speak to these consequences clearly. Being able to predict consequences is a skill that takes time to develop. You need develop the ability to go from a hunch or gut feeling to being able to document consequences and prove them.

Having a good process and being able to handle exceptions are essential but you still need to be able to pivot when you are overruled by the business, stakeholders or circumstance. One of the key benefits of having engaged stakeholders is that they will sometimes have a better understanding of what the business needs more than you do. This is a consequence of the fact that you're focused on delivering day to day, while they are looking at the whole arc of the business. You will need to get on board with the new priorities and, critically, be able to explain them to the team in such a way that they get on board, too. Convincing your team to pivot when change occurs can be difficult but this, too, is a benefit of trust. Your team needs to trust that when plans are disrupted due to priority changes, they know that you advocated for them and are changing for good reasons. But trust is a two-way street; you need to make sure your team members know that you expect them to push back on questions of priorities. That is, if you have to suddenly ask a team member to perform a task while they’re still working on one, they need to feel free to ask you which one is more important and to tell you what will suffer by switching to the new task; and you need to listen to them.

On a practical level, you'll need the ability to track tasks in your backlog - ideally with an ID of some sort. An ID not only makes talking about a task easier, but it can be tracked from your team's work through pull requests, bugs, requirements, etc.  If you have a ticketing system of any kind, make sure that any work a team member does can be attributed to a ticket. This makes it much easier to know when something is done; it allows your team to make incremental improvements in production systems; and it keeps you from being surprised when a team member doesn’t finish their assigned task because they were actually working on something else.

Getting a handle on how work comes to your team will help all aspects of building and maintaining a highly performant team - from stakeholder engagement to trust. Most importantly, it's one of the important parts of your job that will help you deliver value.

Ruthless Prioritization

 As an engineering manager, more often than not, you will encounter conflicting priorities. This is especially true if you’re managing a team that’s doing new development and maintaining existing code.

Let’s say that your team is developing new software with a hard deadline. But the team members you have working on it were responsible for creating a previous system that’s now in production and needs support - suddenly, a critical bug comes up in that system. This is what ruthless prioritization comes into play. You’re going to have to say no to something and balance a few risks. 

You can put a more junior person (or someone not familiar with the system) on the critical bug in the production system. You can pull an experienced person from the new development effort into the analysis of the critical bug to get a feel for what the problem is, what a possible solution(s) is, and how long it would take them to implement, test and release it. 

If it’s half a day of work for the experienced person, can you spare the experienced dev? Is the context switch too jarring? How many times have you done this recently? Don’t forget that the fix needs to be tested as well as deployed - those are critical pieces that you need to add to the risk equation. Who can do them? Are they trained up on the processes?

If the work is longer than half a day, can you have the experienced dev explain the fix to a new person and expect the fix to get done correctly? It’ll take longer, but now you’re still moving forward on multiple fronts - always a good thing if you can do it.

Having an experienced developer work with the less experienced person has  multiple benefits. It gives the experienced team member the opportunity to mentor another team member. It gives the newbie a chance to learn how the experienced person approaches problems so they can learn the craft of software engineering; and it gives them experience in a new part of the system. By slowing down slightly in this way, you’re increasing your velocity in the future because now you have multiple people that can work in that part of the system - you’ve eliminated a single point of failure.

For green field development, you’re also going to get conflicting priorities. Companies and product managers always want more features, delivered quickly and under budget. Being able to explain tradeoffs and the impact of priority changes to stakeholders, while difficult sometimes, will pay off in better trust with stakeholders, trust in you for your team members and consistent delivery of value.

An important aspect of ruthless prioritization is stakeholder management. If you say no to something or deprioritize something, you need to communicate that and be able to explain it clearly. You need to understand the tradeoffs and, if possible, be able to quantify them. Doing this will not only help reach multiple goals, but it will give your stakeholders confidence that you know what you’re doing and will build trust.

There are going to be times when it’s going to feel like you just can’t prioritize - ruthlessly or otherwise. But you must try - for the sake of your team, the project and your stakeholders. Whether or not you think true multitasking is a myth or is possible, for teams it’s not sustainable. The constant context switches will wear down your team, frustrate your best people and, at worst, lead to burn out.

Giving Back

I'm going to take this blog in a new direction for a while. Rather than focus on working with my hands, I want to share what I've learned while working with my brain.

I'm happy with the success I've had in my career in software, so I'm embarking on a project to give back. I'm going to write a series of articles about the things I've learned in my career including my successes and my failures. I hope that by doing this, I'll give people that are transitioning from writing software to managing a team of software engineers the chance to avoid my mistakes. For those that are already software engineering managers, maybe you'll be able to pick up some useful information, too.

Like many in my position, I didn't plan on getting into management. I was happily writing code and gradually found myself managing projects and other people. Eventually, the company I was working for made it official so I became a manager. This was not an easy transition for me. One of the most difficult parts was figuring out the difference between being a productive coder and being a productive manager. When I was writing code, knowing whether or not I was productive was pretty easy; but as a manager, I'd finish work for a day or a week and wonder what the heck I had actually done for all that time. 

I want this series of articles to help those that are going through this transition to get there faster and become great managers quickly.

Kitchen Bookshelf

We needed a bookshelf in our kitchen for a few things: cookbooks, a place to stash Sarah's purse, and our weekly pile of library books (in various states of being read). This one I built fills the bill.

As usual, I started with a rough hand-drawn plan in my shop notebook. I really enjoy doing this because it allows me to go at my own pace and picture what I want to do. It's quite easy, especially with something as simple as a bookshelf. I usually start by just writing down and drawing the dimensions that define the limits of the design. Then, after thinking about it for a while, I draw what I want with measurements and refine them. I'm not sure you can see it in this photo, but I did some "research" on other shelves that I built or that we bought to get a feel for the sizes that we'd need.

I used two 8' 1x10s. I bought the good stuff, which was unnecessary since I painted it but it was nice to work with. Check out that nice bench!

Parts cut out, pre-drilled and labeled

Test assembly

Partially assembled

Screw holes filled and ready for sanding

Just checking that it fit where we want it

Glueing on the back

Sanded and ready for priming

Last coat of paint on

I really enjoyed this project even though the heat index was 105 degrees on the weekend I built it. I got into a nice flow state and things went quite smoothly.

Doing the project helps me figure out how I want the shop to be laid out and gave me some ideas on a couple tool upgrades.

Paulk Compact Workbench

It's been quite a while since I posted but it's also been quite some time (over a year) since I've actually had a shop! Now that I have one, I haven't wasted any time getting into it. Aside from a few repairs and some painting, my first real project is this Compact Workbench from Ron Paulk.

I bought the plans for this bench quite some time ago - while we were living in Hanover, NH. I had a small space in the basement that might have been used for a shop, so I thought this bench would be good. However, I didn't end up using the space as a shop so I didn't build it.

Now that we live in Lebanon, NH and I have a real shop, I decided that now was the time. The materials for this bench cost about $200 but I have some nice plywood scraps left over that can be used for some other project.

As usual, I spent most of my time setting up the cuts to break down the plywood into manageable sizes. I didn't take any photos of that, but suffice it to say that there's lots of measuring, checking, measuring and clamping before the 30 second cuts take place.

This photo lets you see the internal structure. Making those cutouts not only makes it easy to store tools in the table but significantly lightens the bench, too, which is handy when you work alone as much as I do.

This bench is a little darker in this shot because I coated the whole thing in water based polyurethane before I put the top on. That is, I coated the inside. I'm not sure that's 100% necessary, but since the heat and moisture in the shop could vary quite a bit, I thought it was worth doing.

Here's the top before I sanded and poly-ed it. You can still see the guide lines I used to drill all the holes. Those holes are for clamps and jigs. Stay tuned because I have lots of ideas for jigs that'll make this bench even handier.

Here's the final product. I'll have it on saw horses for now but a mobile base is in the near future.

I had a great time making this. It allowed me to really settle into my shop and showed me what my priorities need to be in terms of what I need to build next to tailor the shop to how I like to work.

Update:
I got a couple clamps. this should explain why I built a bench full of holes!

Son of Franken Mower Mod

I finally had to stop using the Franken Mower because the wheels are so messed up that it's practically un-steerable. I ran it once this summer and it trashed my forearms so badly that I went to the Home Depot and bought a new (cheap) mower.
Aside from the fact that the new mower is tuned for California emission standards, it works fine with the exception of the handle height. It's way too low for both Helen and me, hence this mod.
It's just 4 pieces of galvanized pipe, 2 elbows, 2 caps, and 4 clamps. It took all of 10 minutes to put together and it feels like it'll work just fine. It's plenty high enough for both of us.
The rope in the picture is used to keep the kill-switch arm closed during mowing.
The sides are 12" pipe; elbows are 45 degrees; handles are 6" pipe; and each handle is capped for comfort.
We'll try it for a while and see how it feels. Helen suggested wrapping the shorter handles with paracord for comfort, which would be cool. I may replace the metal caps with rubber chair feet, too, if they end up roughing up our hands too much.
All in all, a very satisfying build.

Here's a photo of Franken Mower for old time's sake. Check out those front wheels: totally googly and wonky. But the motor still runs!
My original plan for this mod was to add a pair of bicycle handlebar extensions to the top handle but the ones I bought couldn't open up enough to attach so I went with this plan "B".

Workbench Drawer Inserts

Just because I built 10 drawers didn't automatically mean I was organized! So I built a bunch of drawer inserts to organize 10 year's worth of hardware doo-dads.

Back in 2013, I made Sarah a Christmas tree made of wooden slats. I had lots of left-overs that proved to be the perfect height to make my inserts.

I cut everything to length and then set up my dado stack to cut interlocking joints. It took a long time to set the saw blades up correctly because the pieces, while pretty uniform in width, weren't a standard width so I used the paper and cardboard shims that came with the stack to get it right.

Once I got the dado set up, I could start cutting. I cut enough inserts for 2 drawers each time so I quickly ended up with plenty of inserts. As you can see from the photo, I varied the number of compartments so that I had some flexibility as to where I could store different things.

Prior to having the drawers, I had about two dozen glass jars containing nails, screws, nuts, bolts, etc. as well as an old wooden tray. I was able to fit everything into the drawers and significantly tidy up the shop. I'm very happy with how it all came out.