Who's Your Tie-Breaker?

You’re on a team with people that have different titles and roles: product manager, product owner, your boss, principle software engineer, etc. It’s always good in any context to know, when priorities conflict or trade-offs have to be weighed, who the person is that you go to to break that tie. Sometimes it will be your boss; sometimes it’ll be the product manager; sometimes the principle software engineer. The projects you work in intersect in different ways with these and other roles. Understanding those roles will make your job easier which will have a direct impact on your team's productivity.

Think of your tie-breakers as allies, too. They can help you do more and move quickly by removing ambiguity and road blocks. But it's critical that you don't just present problems to be solved to these allies. Your job isn't to make work for others - it's to help reach your organizational goals and create value. This means when you encounter a situation where you need a tie-breaker of any kind, it's up to you to do your homework first. Make sure you can present reasonable options and have thought about the trade-offs. That will help your tie-breaker make an informed decision and feel comfortable that they're not taking on risk by helping you out.

Once you've got your answer, make sure you document it somehow. Maybe it's an email summarizing the decision; maybe it's updating documentation; perhaps it's adding stories to your backlog. The mechanics of it don't really matter as much as documenting it and communicating it to your team and stakeholders. This will help prevent second guessing later on as well as reinforcing your reputation for transparency.

Remember, too, that for some people you are the tie-breaker. When you're the tie-breaker, work with those that are coming to you so that the topics I cover above are addressed. Being decisive is all well and good, but if you make a poor decision because you didn't have all the facts, that's on you.

But what happens if you don't have a tie-breaker? What if things are so changeable or chaotic that you don't have a person to go to? This is definitely a tough spot to be in. My recommendation is to first, start building relationships with people that could become your tie-breakers. This will serve you well in many situations, not just resolving conflicts. Next, transparency becomes even more important if this is the case you're confronting. By keeping people informed, in whatever way is appropriate in your organization, you'll build a reputation for level-headedness and communication. You'll also likely learn whom your tie-breakers are as you get feedback about your decisions. They may not be "official" tie-breakers, but they're a start. Build out relationships with these people.

Knowing how to break ties when it comes to decisions of all kinds in your team and organization will help you become a better manager and teammate. It will help build and reinforce solid relationships that will help you in all aspects of your job.

Don't Drop the Ball

Most jobs, especially in technology, include frequent priority changes, requests for information, and just general to-do list churn every day. This can lead to stress but also to forgetting important things or missing deadlines. I've suffered from this to some degree or another throughout my career and have come up with a couple strategies that help. These are by no means "silver bullets", but they can help me keep up with changes and reduce stress.

I've been kind of forgetful for my whole life. (Friends and family reading this post will heartily agree.) When I was in high school, I played trumpet in the marching band. Our marching band played at football games almost every Saturday in the fall, so this was a regular occurrence for me. I never forgot about the event at the right time, but once or twice a season, I'd forget my trumpet, which, with the possible exception of my band uniform, was the most important part of my being there! Eventually, the band director made sure there was a spare trumpet available for me to use when this happened.

As I started working, I would forget the perfectly decent lunch I had in the refrigerator when I left in the morning. This meant that I'd have to spend money on buying lunches. I fixed this by putting my car keys on top of my lunch in the refrigerator when I made it to be sure I couldn't leave home without it. After doing this trick a few times, I was able to get into the habit of remembering my lunch. Developing this trick, and others like it, have really helped with forgetfulness but also for unexpected requests and dependencies.

Being conscious of this kind of pattern and creating your own tricks for mitigating it will help you in a few different ways in your career. You'll be less likely to forget important things, you'll earn a reputation for staying on top of things, and it will help diminish your stress levels because you know that you're less likely to miss things.

Each of us can develop our own approach to this. My approach to this problem centers around my inbox and my calendar. I don't like having lots of unread email in my inbox. Over time, I've learned to use unread emails as a kind of to-do list. This tends to work better than a written to-do list for me because it's always current in my inbox, whereas a written list has to move from page to page or note to note. The second trick I use is related to my inbox: I create calendar appointments to tackle important things that include an email reminder. I create zero-duration appointments in my calendar with email reminders so that I remember to do things. The emails contain just enough information to be actionable. 

One other tick I use is more analog. I use a hand-written notebook to keep track of my notes during the week. I've tried various electronic versions over the years but a physical notebook is best for me (with my favorite kind of pen, of course). I think the physical use of a pen helps reinforce what I'm writing. But the trick itself is to draw square check-boxes beside to-do items. They're quick and easy to add during meetings and they stand out during those times when I'm looking back over the last few days to see what I need to keep up on. I also just love checking things off of lists. Sometimes, they age out of relevance (even in a short time), but even then, I'll cross them out with an X and still get the pleasure of checking something off of my list.

There are an infinite number of ways to tackle this problem with an almost infinite number of tools to help. I've created a system that, while not perfect, works for me. I encourage you to take some time to come up with a system that will work for you. Don't be afraid to tweak it or even change it wholesale to make it better. Please share your solutions in the comments - I'm always open to change!

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!