Three years retired... An update...

This was actually the week that I retired three years ago, I gave my notice on March 16, 2020 and my last day was April 15, 2020. I figured I’d write an update to talk about how things are going.

The process of writing this blog has been helpful because it provides me with a diary of sorts to go back and review and read what I was thinking about and doing in the past. I’m happy that I’ve spent time in the last three years doing all of the things that I visualized myself doing when I retired. My focus has just naturally shifted from one thing to another as my motivation and inspiration dictated. I’ve tried not to force one thing or another to happen. Some projects have come to a natural resting place and I may or may not revisit them. Some trends have developed that I can see continuing for a while.

Building projects have come to dominate my activity and they’ve grown in size and sophistication over the last three years. I feel like I’ve learned a lot and improved my skills a lot over that time. It’s really satisfying to read older posts and to see the progression to more recent ones. Even better is knowing that there is a lot more I need and want to learn.

Writing about my career in the software industry has slowed down, I have covered most of the topics that I had brainstormed on my list three years ago. I’m working slowly on an additional post in this area, but I think it’ll take a while.

I still sit down at the piano and play for myself and noodle on ideas there with some regularity. I think I’m figuring out another project there but again it might be some time before I get focused enough about it to bear down and make it real.

I still enjoy computer gaming with my Occulus Quest 2 ( now Meta ) but it sorta ebbs and flows because so many games that are interesting to me also end up being multi-player only and I’m not interested in interacting with random adult children (and children children) online. But, every so often something comes out with a deep single player campaign and I play it to the best of my old guy slow twitch ability.

Traveling is looking up and we’re hoping to do a major trip to Greece this year and we were able to take a traditional fall vacation in Aruba last year. I was able to get to New York Winter Jazz Fest this year and that was absolutely fantastic.

I’ve been reading more regularly than when I was employed and I’ve returned to subscribing to comic books and reading them for the first time in thirty years or so. I pass the read comic books to my neighbor’s kids since I don’t really collect stuff, they seem to really enjoy them.

I try to keep in touch with colleagues that I’ve worked with and when I talk with them I remember working and I recognize all of the stuff they’re dealing with. It all just feels distant now and I only think of it spontaneously when an item in the news or a moment in a TV show triggers a memory. I’m always happy to chat… I’ve got a very flexible schedule.

A frequent question I get from folks when I tell them I’ve been retired for a while is: “Are you bored? Are you going back to work?” My answer so far has been “…laughs out loud… Oh fuck no!” I am not lacking for projects I’m interested in, and though I miss some of the social aspects of working, the whole blog post I wrote about things I won’t miss is still very true.

In a natural sort of way I feel my old career is getting further and further away behind me. I know less and less about my old companies, when former colleagues mention the names of upper management I often have no idea who they are. Many folks have moved on in their careers sometimes to a couple of companies since then or started their own. I don’t know what a lot of them do anymore. That’s good too, the tendrils of stress related to old plans that I was so focused on delivering have gone from being a once in a while tweet where I would think “Whew, they finally did that…” to not following at all because I don’t recognize any of it anymore.

My plan is to not go back to doing stuff for money (if I can avoid it,) and so far so good. I know that all the important things I learned in my career are timeless and have more to do with dealing with groups of humans than any fleeting technology. If I ever had to I could absolutely do it again, there might be some rusty machinery noises, but it would all come back.

Other than travel (which requires future planning,)I really don’t have any hard and fast goals or KPIs ( sarcasm ) other than to continue as I am. I hope I get to do it for a long time.

That’s all I can think of right now, I’ll probably post another update at some point.

Cheers,
James

Management: Change is the only constant...

I’ve been writing a series of posts on management based on my experiences. If you’re starting with this one, you may want to have a look at: https://www.jlgoodwin.com/words-pictures/2020/9/17/management-the-job-of-a-manager

Introduction

A former colleague suggested that I write a post about “change management,” which is a good suggestion. Like most business euphemisms “change management” as a term doesn’t really convey much about what it really represents. I would say it should be more like: “The company is going to do something profoundly stupid/brilliant/destructive/tedious/pointless to you and your team, and it is going to make many of your best team members upset, and you need to try and keep shit together and damp out the reaction as quickly as possible so it doesn’t fuck over the actual work you need to do to run the fucking business that makes the money.” The profanity comes naturally after the first time you go through one of these events. 

I’ll try and reflect on some of the things that seemed to help me when I had to lead teams through changes. Of course there are all kinds of situations that require change (e.g., gaining and losing large customers, growing out of your current process, merging with another company, etc.) that are perhaps less surprising or counterproductive than upper management whimsy, but my conclusions also apply to those situations.

Honesty is the best policy

My first real experience with poor change management was with the first “large” company (about 15k people worldwide) I worked for, after I’d been in my job for about two weeks. All of the orientation presentations had been about how awesome the culture was, how progressive the company was, and how excellent the people were. I attended my first engineering all hands which seemed pretty normal at first. However, the tone of the business presentation started to turn bleak, with phrases like “rapidly declining market share” entering the presentation. Then the head of the division got up and started their presentation; it was pretty unintelligible and it was unclear if it was positive or negative. The phrase “we’re not considering a layoff” was spoken and you could hear a pin drop. It reminded me of the Zen Koan: “Don’t think of the white horse.” How the fuck can you make that statement without having considered a layoff?

Needless to say, within that quarter, layoffs of ten percent were announced. The layoffs really freaked out the long time employees, who had worked there while it was raining money. People and projects just sorta disappeared without any comment or explanation. It took a toll on other projects that had been teetering near failure as well.

The first thing I would recommend is to share everything about the impending change with your team as completely and as soon as legally possible. Certain things like acquisitions and layoffs can have legal constraints, so do what you can, when you can. Don’t try to spin; tell your team what you know and what you don’t know. Tell them what you have been told about the justification for the change. It will be tempting to critique the change in front of your team, but I wouldn’t recommend that. You have a responsibility to the company to sign up and support the change. If it is really so odious that you can’t bear it, you should quit. 

Talk to the most important members of your team and get their perspective on the change. You should acknowledge their concerns and do your best to correct them if they are extrapolating future events or are attributing intent that they have no evidence for. If you see a trend in the reactions, you should address those in your next team communication. If there are concrete problems that need to be addressed, be open and direct about prioritizing their importance and fixing them.

Limit the blast radius

Work with your managers and/or senior employees to try and figure out a response to the change that minimizes disruption. If you can limit the number of people affected, limit the duration of impact, limit the product scope impacted, or all of the above, then you will help your team get past the change faster. In some cases where the change is really just tedious busy work, you may be able to come up with a pro-forma compliance response and save everyone a lot of time. Resist the urge to immediately restructure the team significantly to address the change. Be tactical at first and then, if the change looks permanent, make more structural changes.

If you have to cut, cut

Later in my career, I was working at a very small company after spending more than a decade at a very, very large multinational company (hundreds of thousands of employees). I was really enjoying having virtually everyone I worked with in the same room and just cranking out code. I came into work one February morning and I immediately knew something was wrong: My boss greeted me at the door. This was very unusual because he never left his crypt before ten or eleven in the morning, and I usually arrived at work somewhere around eight-thirty. And he was definitely not the type to greet you at the door. He summoned me into his office and informed me that they were cutting the company down to just an essential core, and that I was part of that core. I sat there all day watching people arrive, get greeted, taken to the office, and either stay or be walked back out.

In some ways it was fairly well handled; many of the folks that were removed from the engineering side weren’t really the best team members and I was sorta relieved to see them go. On the other hand, immediately after the layoff, on top of what we were already doing, we started working on random projects under the capricious leadership of our CTO. Regular projects started to drag out, the random ones went through a weird escalation of frantic activity followed by abandonment. I finally realized that they were some sort of corporate “forbidden dance'' with potential buyers for the company. It could have been made clearer what the CTO wanted because we weren’t a public company. 

Finally, we were acquired by a large multinational corporation in a deal where they wanted the engineering team but not the product. They sold the product and the rest of the company to a consulting company to help cover some of the acquisition costs. I came full circle through these changes right back to being an engineering manager at a gigantic company, except now my entire team was in another country.

In the case of a cost-based layoff, you should look carefully at your team and think broadly about who the team would be better without. In some cases it might be the very senior member of the team that everyone thinks is untouchable. In many cases these folks are trying to retire on the job and are actually a corrosive force on the team holding back newer, more productive team members. The point is to try and make your team the best possible team at the new size. Sometimes this is just a process of limiting the damage, sometimes it is an opportunity to make a needed change. You should aim to have your team be more balanced, more diverse and inclusive, and still effective after the layoff. If your team is too small to handle all of their projects after the layoff, you should work to kill some projects and reduce scope.

Use the disruption to your advantage

If the change is a large one then you should look at including changes that your team has been planning at the same time. Disrupting the team once is better than a chain of disruptions covering more calendar time. All changes tend to damp out in about the same time so bundling them makes sense.

It is not the stages of grieving

The first time I had to substantially change and reorganize a team was at a large multinational corporation, where I had just signed up to be the director of half of a large engineering team. The team was a little bizarre because it was made up of what looked to me like three duplicate product acquisitions of various sizes. We were still operating all of those acquisitions’ services, even though none of them was profitable or cost effective. So, I thought to myself, “Well I guess I’ll understand the business sense of this at some point, let’s use this to learn how to be a director…”

A few weeks after I started that job, I got a call while I was out of the office from my boss’ boss. They informed me that they needed to cut the division by more than half and refocus on just one product. They wanted me to lead it and lead the restructuring. I of course didn’t mention at that moment that I had never restructured a team that large, that I didn’t know any of the people, or for that matter, any of the products; sometimes you just gotta go with it. The total cut was from about 150 or so folks down to 33. After I finished freaking out about this mission, I began to figure out a strategy.

I connected with the couple of folks that I knew on the existing team, and asked their opinion on who was the most productive member of the engineering team. As usual, this wasn’t the technical leader or the most senior member of the team. I brought that person onto my restructuring team and we collaborated on selecting who we would need to stay in order to build and manage the new product. 

As soon as the reduction in force was announced, I gathered the remaining team together and we immediately started planning our short term actions and our first release. I did a lot of the planning with most of the team in the room, which a lot of folks thought was crazy and would never work. Well, in three months we consolidated and shut down all of the existing services. In one case, we discovered a whole data-center that had never been used since its acquisition, but was costing tens of thousands of dollars a month to generate heat. We launched a new platform on flexible technology that could be hosted in the cloud and the first version of our new product. The cost savings just from the shutdown of the redundant platforms and the shift of hosting covered all of our engineering costs for a year.

The team coalesced quickly because we had immediately established a release cadence, new leaders on the team had to step up and learn quickly, the challenges focused everyone, and there was very little wallowing in the massive change they had just experienced. Everyone was on the inside of all of our plans and requirements so they knew what had to be done. Most critically, they felt like they owned the plan and the goals.

Not every one of our choices for team members worked out, but in this intense release cadence it was easy for managers to see who wasn’t contributing. We made additional changes and hired new people to the team to fill gaps.

You’ll see advice that says there are stages to change management and the stages they quote are based on the apocryphal stages of grieving: “shock, bargaining, etc.” There are no stages. Every person will have their own reaction to the changes and will need their own amount of time to deal with it and in some cases, they won’t come to terms with it. Don’t buy into those platitudes. Your job as a manager is to move forward, be consistent, be positive, and establish new goals and focus your team on them. If people leave your team, you should support them and replace them promptly. 

A key point in explaining the actions of any company to a team: Do NOT personalize it. Even though the impact is personal, causing changes to their career plans, their job, their role, or even their compensation, the company isn’t doing it to them. The company isn’t their friend or family; the company is a machine that is trying to reconfigure itself to make more money. The perceived damage to the employee is an unfortunate side effect of this reconfiguration. And the company has factored this damage into its consideration of the cost of the change. This message can be complicated by flawed corporate culture that proclaims “we’re family” or ”we support you” or ”we value you as an individual.” These things may be true when individual humans say them, but they are never true when a corporation says them.

Don’t mistake team formation for trouble

After any significant change there will be friction and conflict as people negotiate new roles and new tasks. Don’t overreact; it’s best to let these things play out. It can be disconcerting to see people who you thought were reliable and settled seem to transform into problem team members, but that is just what happens when a human hierarchy is tossed about.

Return to steady state

In general when you’re communicating with your team, you should prepare them for change. Don’t create the presumption that things will stay the same for more than a quarter, perhaps less, in an early-stage company. Don’t make overly long detailed road maps with specific commitments going out for years. The Soviets proved that five year plans don’t work. Have high level goals that set a direction and that can be addressed by multiple responses over time. Make short road maps that fit into the planning cycle of the company. Reinforce the notion that these plans might change because the company is dynamic and may need to focus differently or these ideas might fail in the market. 

Within the planning cycle of the company, try to have a cadence and return to that cadence with a new set of tasks and with new goals and priorities after each change. With any luck, you’ll be able to carry forward important goals that you still own from before the change. For example, if your company likes to do quarterly plans, it would be good to make a new roadmap for one or two quarters (maximum) and to plan a couple of releases in the next quarter. The new roadmap might be related to your pre-reorg roadmap or it might be brand new, depending on what changed with your team. The fresh roadmapping process will help your team understand their new mission and begin to focus on it.

Part of the return to normal operations is updating your roles and processes if they’ve changed. Sometimes folks will have new responsibilities and new processes that they are now required to perform. You should as quickly as possible make sure they understand and accept these changes and that you document them and communicate them to the rest of the team. It is a good idea to have a “new organization” kickoff meeting to talk through the whole org and its goals and responsibilities so everyone hears it at least once. Reiterating these changes at future team all-hands meetings is also a good idea; people take some time to really internalize the details.

Summary

You should try to include as much of your team as possible in planning for changes, large or small. People in different roles often bring up key issues that you might not immediately consider in making the change go smoothly. If I had to summarize my approach it would be to communicate clearly, listen to feedback, follow through quickly on changes, and get everyone back to work as quickly as possible. Make sure to always be talking about the job ahead and not about what used to be. Getting your team oriented toward the future will have the best impact on morale and productivity post-change.

Management: Why become a manager?

I’ve been writing a series of posts on management based on my experiences. If you’re starting with this one, you may want to have a look at: https://www.jlgoodwin.com/words-pictures/2020/9/17/management-the-job-of-a-manager

Introduction

A former colleague who is considering a management role asked me: “Why did you become a manager? Why do people do it?” My first thought was: “Right?! I woke up many mornings and asked myself the same question with a lot more profanity involved.” My second thought was: “Good question. It’s complicated.” I’m going to talk about my reasons and their complexities in case it helps other folks process theirs.

It picked me

When I first got a management role, it chose me. I was nineteen years old and working on a team that was building a microcomputer frontend for a mainframe-based portfolio accounting system, the team lead left; because I was the only other microcomputer programmer at a Fortran based mainframe shop they asked me to be the team lead. To say that I was immature and lacked basic social skills is a colossal understatement. The thing that saved me was good mentors who patiently showed me what to do. All the same, my next several jobs were all individual contributor jobs and I was very happy. 

My next management role happened again in a similar way several years later when I was working for a company that did accounting and estimating software for construction companies. I was the only C/Assembly language programmer at a BASIC shop (yep, real software products were made with BASIC). I wrote the UI, database, and networking extensions for BASIC so it looked and worked better. Our manager departed and because I was the most experienced person I ended up the manager. At least by that time, I was a little more mature and less socially awkward.

I probably wasn’t the best manager in either of these positions, but I certainly learned a lot. Most importantly I learned that my engineering ability didn’t have a lot to do with managing people. I also gained confidence just by interacting with other people, which helped me as an individual contributor too.

It’s a control thing

I started thinking about management as a career path when I was probably fifteen years into my career. I had reached a point where I was a very good engineer (at least the folks paying me thought so) and even though the job wasn’t easy, there wasn’t much mystery or growth in it for me. I’d become much more aware of how companies and teams worked and I started to crave more control. The first few times I sought out management roles it was to obtain more information and to have more influence in order to protect myself and feel more comfortable. I think a thing to mention here is that I went back and forth between management and individual contributor and it didn’t hurt my job prospects at all. In fact, it actually improved them. I would however counsel you to avoid the hybrid role of technical leader and manager. I’ve been there, done that, and I ended up alternating between sucking at one role or the other. The best scenario for these situations is to help hire your technical lead peer and have it be someone you see eye-to-eye with.

I found out that I liked it

A side effect of working more and more as a manager was that I started to try and be good at it. I copied good managers that I had worked with or near, especially my older brother. I also started to enjoy the delayed gratification of team success. It made a lot of sense to use my experience to support a whole group of people with less years and to help them perform better and progress faster. 

It isn’t a coincidence that my maturing as a manager coincided with me becoming a more mature person. As a kid, folks had always seen me as smart but distracted, and never as the leader of anything. Actually, I’m not a joiner either: I’m more of a loner. I found that being a manager was actually the safest place for a loner/nerd/introverted person like me. It allowed me to control most encounters with other people and in the power dynamic I had the upper hand going in. I only had to do a few “performances” as the corporate version of a leader to keep the business folks happy. In reality, I did most of my “leading” one-on-one with folks on my team, which is the perfect-sized interaction for an introvert.

I enjoyed the more subtle problem solving required in management and creating organizations. I had always had a talent for keeping big complex systems in my mind and restructuring them. Human organizations felt very familiar and more challenging since people are less predictable than code. I also liked having the ability to help folks who reported to me to succeed and grow as part of the process. Mentoring is a very satisfying part of being a manager and an effective way to get better as a manager by listening to folks and having to reflect on your own experience in order to respond to them.

Money, power, and problems

As you get higher in level as a manager, your satisfaction from your job becomes more and more abstract. At the end, I did enjoy managing other managers and learning from them and making them into a team to support an even larger number of people. But as you get to that level, you become more and more split in your focus between your own team and servicing the needs of peers and higher level executives. It ends up involving more “performances” that essentially amount to making an executive or peer who is scared about something feel better, or at least feel in control.

Money is certainly a motivation for choosing to become a manager. Later in my career (as I started to consider early retirement as a viable option), I saw that I could level-up faster (and with a bigger total compensation) as a manager than as an individual contributor. I was getting older and the mental and emotional stamina that I could summon for coding under an intense workload (required to earn a lot of money) was definitely waning. There is certainly truth to the phrase “more money, more problems,” in that you trade stress about your individual performance for a lot of stress about the performance of other folks that you loosely control. I developed a good poker face to mask my internal stress about my position as I climbed the management ladder. It would crack every so often, but generally folks thought I had the ability to remain calm in the worst situations. Even though I still experienced a lot of chaos and churn, I preferred to experience it as a manager where I at least was in the room when bad decisions were being made even if I couldn’t prevent them.

Know when you’re done

I knew I’d hit my final level when I got to VP of Engineering. From that level, you can look into the abattoir of executive management without having to spend all day in it, and you either like what you see or you don’t. I didn’t, and since I had no desire to just repeat myself, I stopped. By that time in my life there were a lot of other things that interested me more that had nothing to do with business. I had been planning my exit for ten years and I was in a position to make the final moves to retire.

I hope these reflections help to give you some perspective. I probably should have mentioned earlier in this series that you should feel free to ask me any questions you have via twitter (@jpfxgood), https://www.linkedin.com/in/jpgoodwin/,or comment on this post below. I can’t commit to answer every one directly, but I will be writing more of these essays and I’ll try to address them there.

Management: Things I won't miss...

I’ve been writing a series of posts on management based on my experiences. If you’re starting with this one, you may want to have a look at: https://www.jlgoodwin.com/words-pictures/2020/9/17/management-the-job-of-a-manager

Introduction

I’ve been retired now for ten months after a thirty-nine year career in the software industry. I’ve had pretty much every role from software engineer to vice president of engineering. Overall, it was an enormously rewarding career and I’m honestly not bitter or angry about any of it now that it is over. I’ve certainly had periods of bitterness and anger over the years, and there are definitely things that I think are systematically wrong with the industry that I found myself struggling against (especially as a manager). It can be a great career for anyone as long as you know what you’re getting into. Here’s the list…

Being between the team and upper management

I will not miss: 

• Waking up every day thinking about some executive’s expectations of me and my team, the problems I should solve, the deadlines I should pay attention to, the people I need to wrangle, my performance measured against an invisible changeable ruler.

• Having to get people to do things that they don’t want to do for reasons I don’t entirely agree with (or in some cases completely understand). Negotiating the “merely goofy” vs. “the actually stupid and evil” to figure out how much political capital to spend on any given act of inquiry, redirection, or resistance.

• Trying to deduce, from a cloud of barely differentiated requests for my time and my team's time, which actions will actually be valuable to the business if we do them. This is where actual management happens, and actual decisions, and actual risk… Some folks completely avoid this, but they tend to be crap managers.

• Facing my email with dread, waiting for the next capricious turn that will invalidate all of the planning and understanding and work me and my team had done for weeks or months before. Our decisions, supported by a lot of work and thought, undone by the sudden “pivot” supported by a rambling semi-coherent e-mail. 

Human frailty

I will not miss:

• Having to listen to other folks’ emotional outpourings, worries, freak-outs, paranoia, sadness, grief, anger, you name it. Having to absorb and understand that emotion and not respond in kind, and then talk them around to some productive direction that keeps them getting paid and us all doing what we get paid for. Hard to do and still have some personal integrity…

• Changing my entire mental focus an average of ten or twelve times a day… and not being able to focus afterward on anything that I want to pay attention to.

• Having people who pay me a lot of money for my experience and knowledge ignore or contradict my advice. The worst version of this is when they come back and tell me “You know, you were right…” after the debacle/or resisting me tooth and nail.

• Having to fire people either for something stupid that they did or failed to do or because the company did something stupid or failed to do something. Fortunately, if you are breathing in and out and have a good story about being a software engineer you can get a job in this industry. Believe me, I’ve reviewed a LOT of resumes and interviewed a LOT of folks, so, generally I don’t worry about people I’ve fired, It’s more the emotional impact of the moment that I won’t miss.

Male dominance behavior

I will not miss having to step on the neck of male bullies in the tech leadership because it's the only way they’ll “respect” me. This is one of the worst things about the industry, and it stems from overwhelming and systematic male dominance, and by this I mean, only hiring men into leadership positions, only listening to men, only valuing particular male styles of communication, having to dominate other people to show how “good” you are in a male recognized sort of way. Even in the very best of companies I was frequently confronted with men telling me about how women engineers were “too junior,” “didn’t communicate directly enough,” “didn’t communicate clearly,” or “weren’t organized.” What they actually meant was “They’re not aggressively suppressing all other ideas in favor of their reductionist linear version of what to do.”

All, and I do mean all, of the monumental software project failures that I’ve witnessed in my career were led by aggressive, opinionated, and actually under-qualified, men. They all went off the rails because these folks couldn’t allow consideration of alternatives or even whether the project had useful results. Their egos wouldn’t allow it; their entitlement wouldn’t allow it.

I never fit into male culture very well even as a child and male culture knew it. I was frequently the focus of a lot of aggression and bullying. I figured out how to survive by using my intelligence (and low animal cunning), and I never developed any sympathy for my abusers. In my personal life, I avoid folks who behave like that and now that I’m an older, bigger, more affluent man, they tend to avoid me too. 

I did my best to be an ally for folks who weren’t aggressive men during my career. I used my power and influence to counteract the default narrative and get more women into higher positions. It was a fucking struggle, even when overtly these same companies had “diversity” goals. I have to say that announcing “diversity goals” is mostly talk, because I did the awkward thing and actually hired the women and others. Most of my peers didn’t. I would provide them with excellent candidates who I vouched for; they would invent a reason not to hire them. They would be happy about my team improving the stats but they weren’t interested in helping.

Meaningless technical debate

I won’t miss having to explain why I don’t want to include all of GraphQL for one tiny feature because someone thinks it’s “cool.”

I also won’t miss Java, JavaScript, the C++ Standard Template Library, browsers as the worst runtime environments of all time, vim, emacs, the Windows API from any century, distributed object systems of any kind, micro-services and other overused flavor-of-the-year one-size-fits-all architecture patterns that substitute for actual architecture design, Big Company drive-by-do-nothing-take-no-responsibility software architects, the new language to end all languages (Golang, Rust, etc.)… I could go on.

The fact of the matter is that good engineering is good engineering and you can do good engineering in Assembly language if you have the skills and the discipline. And good engineering means that what you are engineering is appropriate to the problem you’re solving, the economics of the business you’re in, and is reasonable for the talent you have access to. You can even build good things out of imperfect pieces (and you often do for economic, social, and political reasons).

All failed software projects fail due to one or more of: poor goals, poor leadership, a bad business model, a lack of customer value, poor analysis of requirements, outrageous scope vs. capacity, and human frailty. Of course, the least valued skill in the software industry is management, and it is the skill that is required for success. 

Business travel

I love to travel for pleasure; business travel is the opposite of that. I won’t miss being forced to fly to places I’d never go on a bet, to talk to people I don’t know, about stuff none of us are interested in, followed by tiresome forced socializing. All of this happens in a dreary business hotel or some kind of function hall or closed down public venue or worst of all a fucking golf resort. Business trips often are scheduled so that you are “ON” for twenty-four hours a day and constantly in large groups of people you only slightly know. This is the very vision of hell for an introvert.

Even in the best case, where I got to go someplace I really wanted to and had some time to myself, the logistics of traveling efficiently so you don’t waste your own time and also have time to do the work ruin a lot of it. When I managed folks in Berlin, I visited about every five weeks. To assure I still had time for myself and my family, I would fly out late Sunday night, arrive on Monday morning, work all day, go out in the evening until my normal bed time. That first “day” was thirty-six hours long and by three o’clock in the afternoon local time I was almost hallucinatory. I made some great friends there and in the end it was worth it, but the travel was a huge drag.

I really hope for everyone’s (and the planet’s) sake that, when the pandemic is over, people realize that most business travel is just posturing and a meaningless, inefficient display of wealth and entitlement. It’d be great if folks would recognize that business travel isn’t a perk for an introvert; if you’d like to give us a perk, we’d prefer some free time on our own.

Finally

I sincerely hope that the other allies out there will keep working to reform the industry. It was a great career and I loved a lot of it. I’m glad to be done with these particular things.

Management: Things I'll miss

I’ve been writing a series of posts on management based on my experiences. If you’re starting with this one, you may want to have a look at: https://www.jlgoodwin.com/words-pictures/2020/9/17/management-the-job-of-a-manager

Introduction

I’ve been retired (as of this writing) for about nine months and it is the end of the year, so I’ve been assessing my response to this new state of being. Overall, I’m very happy, and I’m a lot more relaxed. People see me on zoom calls and they comment that I look “better.” I have plenty of things to do, and I also have become comfortable putting any of them aside for weeks or months if I feel like doing something else, or nothing. Writing this series of blog posts about management has been an interesting project because it has caused me to stretch my memory back over the years to find stories that would illustrate my points. Back at the beginning of this process, even before I had formally retired, I started a list post entitled “Things I won’t miss.” My wife and most marvelous editor read it and said “Oooh, harsh, perhaps not yet?” and so I’ve been holding on to that one. But, the process also begs the question: “What will you miss?” I’ve been thinking about that too… here we go.

Stress

I honestly also enjoy not having work stress, despite the fact that I actively sought it through my entire career. You become addicted to stress over the years. There is a rush that you get when you sense that things are heading in the wrong direction and you need to do something. There is a “jumping out of the plane” sort of feeling when you embark on a project that you don’t know how to finish. There is a wave of relief when something you’ve been trying to steer in a good direction finally bears fruit. It is an element of my personality that I chose increasingly challenging work to amplify these sorts of feelings. I never had good luck trying to coast in a less challenging context; it’s always made me unhappy. My working-class background also reinforced this need in order to feel secure. I’ve identified all those elements and understood how it’s affected me, and I realized that I’ve had enough of that for a lifetime. Many of the projects I’m doing now involve learning stuff I’m not good at, which makes a good surrogate.

Hiring people

I used to hate interviewing people, being responsible for hiring people, and worrying if they were going to do okay. My last few roles were at a level where I had to do a lot of hiring and do it well or I was going to fail. I got a lot better at hiring and my perspective on it changed. I started to enjoy finding people who were great at what they did and needed to be given more responsibility to get to the next level and hiring them into roles that would give them that. I learned a lot about that on a project where we built a whole new product staffed only with me, a senior engineer, and a few interns (to start). I gave the interns that worked for us full responsibility for building the product (okay, I gave them architecture and some fundamental technology choices, and some guidelines). It was impressive to me that even though they had to redo some things and overcome their own lack of confidence in some cases, they produced what we needed and they became confident engineers at the end of six months. I think they got a lot out of it, and I enjoyed it. It strongly influenced how I built teams after that and what I looked for in candidates. The number one thing I looked for from there on was the spark of creativity and the drive to make things and share them with people. Hiring is definitely a management superpower and it has a huge impact on the people being hired and the team you hire them into. I’ve reshaped whole teams by hiring the right people into key roles. I’m glad that I got to do that and I’m not sure exactly what will take its place.

Collaborating

Being an introvert, I am not good at joining groups and I actively avoid it. The reality of the working world is that I had no choice but to overcome my aversion and join lots of teams, in lots of different roles. In the best case where the folks that I was collaborating with were all at my level or a bit above, and we all respected each other and delivered our part of the job, it was a great feeling. I’ve formed a few teams like that and I could always tell when they’d jelled just by the feeling they gave me. It is such an emotional support when things aren’t going well and there are a whole group of people who understand and are engaged in fixing things with you. I think I’ll go forward having a looser engagement with folks by sharing my projects and getting input from friends and interested parties. We’ll see.

Customers

I enjoyed seeing what customers would do with the software I helped create. They often imagined uses that I had never even considered. Working with customers gave me a fascinating glimpse into businesses I never would have seen otherwise. The people themselves were often brilliant, driven and creative. I would never have met or interacted with these folks had I not worked in the software industry. There is something very satisfying when you see someone use your software and get something out of it. The feeling was similar to when I was cooking for a living, and that was even better, because it was very immediate. Of course, this is another element of work that has a downside as well, but I’d say on balance it was a big motivator for me.

Finally

These are the big things. I’m not going to list all the minor items. I’m not going to include coding because I intend to keep doing that. I’m not going to say “the people,” because I hope to be friends with many of them for years to come. Okay, now I’m off to edit the “Things I won’t miss” post into a shorter, more focused list.

Management: Be a quitter

I’ve been writing a series of posts on management based on my experiences. If you’re starting with this one, you may want to have a look at: https://www.jlgoodwin.com/words-pictures/2020/9/17/management-the-job-of-a-manager

Introduction

Amazing, talented, hard-working, accomplished folks who’ve reported to me over the years have asked: “What do I need to do to get to the next level?” In most cases, because I needed them, I have to admit I have sometimes stopped short of complete candor. If I could have, I would have said: “Find the job you want to have at another company and then quit this one.” There is also the version of: “Find the job you want at this company and then transfer to that one.” I’ve never stood in the way of anyone leaving my team and getting their next job, and I’ve always helped in any way I could to make it happen. So, my career advice is “Be a quitter.” There are some dimensions to that reductionist statement…

Are you getting what you want?

My very first programming job was when I was sixteen years old, when I worked for a company creating educational games for the TRS-80, Apple II, Atari, and IBM PCs. When I had worked for them for about three years and was heading to college, they were still paying me eight dollars an hour. I was as good or better than their older programmers so I asked them for a raise to fifteen dollars an hour. They had recently started to become more of a “business” and had hired a biz school grad to manage their operations. He wouldn’t go for it. I quit and took a job cooking in a restaurant that happened to be on the ground floor of my girlfriend’s dorm building for fifteen dollars an hour. I got some good cooking experience and a few months later I got another software job with a company that did portfolio accounting for big Wall Street firms. They paid me a lot more than fifteen dollars an hour, and I later dropped out of college to work for them full time.

Right from the start of your career I recommend that you pay attention to what engages you about your job and what turns you off. Make pro/con lists at some regular intervals, perhaps at quarterly review time. Are you getting enough of the pros from your job vs. the cons? Are there opportunities to shift the balance in your current role? Are there things you could add that would be pros that you’re not doing at all? Are there things that you’ve only done once in that last quarter that you really enjoyed? Try to do that again. Don’t pay that much attention to what you “should” do, pay attention to what you want to do. 

If money is on your list, find out what you’re worth by spending some time getting some other offers. Don’t try to coerce your manager into paying you more by dropping offer letters in front of them. Instead, just talk to them about what you think you should be making in your current role and why.

If you really don’t see a way to pursue the things that motivate you via your current role, then this is a signal to start looking inside and outside the company for your next role.

Ask for responsibility

I was a principal software engineer on a large team writing business productivity software. I wanted to be a software architect. I had been working fairly autonomously on a feature that touched every damn thing in the product. So you could say I was already doing software architecture work. But, because I was young they were reluctant to promote me. I saw another team that was fucking up wildly and they desperately needed architectural guidance. So I talked to my boss and asked to help them out. It was a huge mess to unravel but I managed to create a good architecture out of it and rewrite a lot of it. I also got the team members contributing better as well. After that, when I asked for a promotion they gave it to me. Partly because they acknowledged that I was qualified, and partly because I owned two large feature areas and they couldn’t afford to lose me.

 If you want to get to the next level, ask for next level responsibilities when there is an opportunity. A new project, a new sub-team, a crisis that needs to be sorted out, etc.--any of these are places where you can volunteer to take on more scope. Essentially that is what “career growth” is: getting more scope of influence. This kind of informal tryout is good for you and for your boss. It lets you figure out if these are really the things that motivate you and whether you are any good at them. It lets your boss see you as the next level without committing to a promotion. Of course some bosses are assholes and (even if you do well) will just try to use you again in this role without a promotion. I would say that risk is worth it to get the tryout and if you have an asshole boss you should (you guessed it) quit.

Be great at your current job

I can’t tell you the number of people who have pursued me for promotions who weren’t good at their current job. I’m sure that works with incompetent managers who want to just pass their problems along to other folks while failing up themselves, but I’m not talking about them. You’ll know you’re great at your current job when the 360 feedback from peers, supervisors, and stakeholders confirms this--that’s when you should try to get the next job. A real challenge in this is that sometimes you’re good at something that you don’t like all that much. You are left with a choice: Pursue the thing you’re strong at or perhaps go for something that makes you happy that you’re just okay at. I don’t know the right answer; you have to choose.

Work for people you can learn from

After some years at a Very Large Multinational Technology Company I had reached a point where I was flying back and forth across the United States with PowerPoint decks telling “stories” to partner companies. I wasn’t learning anything except how to get the most frequent flyer points. I was not happy. I went looking for a company that was smaller, more focused, and where I could be an individual contributor again. I found a little place doing cool work that I was interested in. They were a small tight knit group of really talented folks. The interview was really hard. I learned a lot about truly collaborating on a project, taking feedback, and using asynchronous communication effectively. I got deep into Linux, Python, test automation, Windows distributed security, and about a thousand other things. I started coding for fun again during that job and haven’t really stopped since. There was a lot of blunt feedback, but in response to that, I got even better than I thought I was going in. 

The worst place to learn anything is a place where you are the smartest person in the room. When you’re interviewing companies (or other teams), one of your goals should be to see if you are going to learn anything from them. That education is worth more than money. Learning is what gives drive and interest to your career. If you’re not learning, you’re sliding backwards. This is why chasing easy money, and hopping from money-wasting startup to money-wasting startup, is not a good way to develop a strong career. It isn’t always easy to be learning on the job, and it comes with stress and sometimes uncomfortable feedback, but I think it is worth it in the long run.

It’s okay to plateau

I was leading a scrum team at a small e-commerce company and as part of a project we were doing, someone had to write some deployment scripts. This involved writing some shell script and a little work in Lua on Nginx. When the task came up during planning, the task wasn’t claimed so I assigned it to one of the more senior engineers. The next several stand up meetings this engineer was in a very bad mood with me. I finally had a talk with them and they informed me that they were a “Java Engineer” and that they didn’t appreciate being given tasks that weren’t Java. I told them that their job title was “Software Engineer,” and that they would use whatever software tool was required to build the systems we needed. Needless to say, this conversation didn’t help them in their quest for advancement. I can only imagine what has happened to this person since then, with the rise of JavaScript on the backend and the long dragged out death of Java.

It is okay to get to a certain point and just stay there because you’re happy, challenged, and still learning. A key thing to be wary of in these contexts is to not let the market leave you behind. Don’t be a Java engineer or a Python engineer: be a Software Engineer. Be comfortable in multiple environments and idioms. In the software field, languages and tools and operating systems go out of style. It isn’t that there is really something better, it is just that people tend to herd towards new things periodically. You should pay attention and update your skills, put the new tech into your current job (or get a new job with new tech). I’ve had to lay folks off in the past and there is nothing sadder than “senior” folks, whose skills are a decade out of date, trying to attain the same level in a market that has moved on. You become at best an entry level person with commensurate lower salary expectations.

Don’t become a manager if you don’t like managing

Don’t take a management role if you don’t like it and/or you don’t have any aptitude for it. There are plenty of ways to figure this out before taking a management role. Being a great engineer is not an important qualification for being a great manager. Many companies make this stupid assumption because they were founded by engineers, and they typically have a lot of crappy managers (who are former engineers) who really don’t like managing people. You are much better off solving your money problems or level problems inside the engineering track than switching over to the management track. Also, the employees that would have to suffer under you will appreciate you staying in the engineering track.

Take a pay cut if it is the right role

In the long run, it is better to have the right role than to always have a steadily increasing salary. Of course, this assumes that you have your finances in order and can afford to do this. I would say that being able to have this option is very useful in career progression. I’ve done it more than once, because as a great employee, companies tried to lock me in with an above-market salary. I didn’t want to be locked in anywhere, so I took jobs for sometimes $50k to $100k less because they were the right jobs for my goals. The money always came back in about a year, and I had the role that I wanted and was learning the things I wanted to learn. Sometimes if you’re trying to change your role and you don’t have the most extensive experience in the new role, it helps your new employer take that risk more easily.

A note on entitlement

It is usually about here that someone says: “This is easy for you to say; as a white male, the system is built for you to succeed and get opportunities.” Yes, I agree and I think there are systemic biases against women, people of color, LGBTQ--basically anyone who isn’t a white male in the software industry. I worked hard to be an ally during my career and to hire, mentor, promote, and empower folks that weren’t white males. But, I’m just one person in a sea of shitheads who don’t acknowledge their bias, or worse, who actively revel in it. That being said, having watched the careers of several talented women and people of color over the years, I would say that my advice is not entirely bullshit for them either. The difference is the timeline, the amount of resistance, and the level of care they needed to take in choosing companies, groups, and roles. I always encourage folks who are not like me to find a successful mentor who is like them to talk to and to run ideas past. When you’re networking, ask about allies and see if you can work for them.

Don’t quit too often

Look for companies where you think you can spend at least four years, and try to stick to that. I’ve had stints from thirteen years to nine months, but the average is probably around four or five years. And even at the longer tenure jobs, I had a new role about every three or four years in a very large organization. As a reader of hundreds of resumes, I can tell you that (unfair or not) I don’t like ones with a series of two-year jobs. I know that a lot of startups don’t last more than two years. I think startups suck as a place to learn anything, as most of them fail, which means you’re learning to fail. I prefer a going concern four- or five-years old with a money-making business, because they are succeeding and you want to learn success. The concern I have when I see a two-year pattern in resumes is that the person talks a good game, and it takes twenty-four months for the organization they’re working for to detect that they are lazy or incompetent and get rid of them. I’ve made the mistake of hiring people like that based on a glittering interview performance, so I learned to pass on those. I suspect other managers do too. It is also important to show folks that you’ve been through a long arc of a software product or service’s lifecycle, not just the launch.

But, what about my team?

Don’t flatter yourself. Your team will be fine when you move on. You’ll be creating opportunities for other folks to step up to replace you. If they’re in a crappy situation, your departure might push them past their inertia to upgrade their jobs too. You don’t owe the company anything, they paid you for your efforts and (at least in the USA) they could drop you in a hot minute if they wanted to. Besides, as I mentioned above, you gave good value for money because you were great at your job. Nobody (sane) will be offended, as quitting is part of business. 

Finally

You are responsible for your career. If you don’t engage in planning it and driving it, nobody will. Your employers are much more likely to use you up in one role and replace you, than to encourage you to grow and progress. Be proactive on your own behalf.

Management: Managing yourself

I’ve been writing a series of posts on management based on my experiences. If you’re starting with this one, you may want to have a look at: https://www.jlgoodwin.com/words-pictures/2020/9/17/management-the-job-of-a-manager

Introduction

I’ve written in other posts about what the job of a manager is; a lot of that related to how the manager should support the team, but, as a manager you need support, too. In my experience it is often the case that managers are not very well supported and they are expected to “just get on with it,” with very little guidance. Or the guidance is of the form: “Well, you fucked that up, don’t do that again or we’ll fire you.” So, in that situation you end up managing yourself. I’m going to describe a few dimensions of what that means. 

Time Management

Howie didn’t work on my team, my project, anywhere near me and yet for some reason he would come to my cubicle, sit down, and talk to me about nothing. These little chats were quite one-sided and sometimes even after saying “sorry, I’ve got a lot to do,” the monologues would still run to an hour. My boss could be seen to drift past my cube opening and the glare I was getting was meaningful. Finally, I just started not turning around when I would sense Howie entering my cube and just continue working. This didn’t dissuade Howie however because he would just plop himself down and deliver a soliloquy about the Red Sox (or some other shit I had no interest in). Finally, when I would feel the guard hairs on my neck signal Howie’s approach I would just say “Fuck off, Howie” there would be a quiet shuffling of feet and he’d move on, probably seeking another victim…

Nobody is going to manage your time for you. Folks above, beside, and below you in the org-chart will dump things on you as if you have nothing to do. The problem with this is that if you just accept this, you will end up burnt out and not accomplishing what you want to do, and often not even what other folks want you to do. Treat your own time like the precious and limited resource that it is. Block time in your calendar to work on your own tasks--this can even be “spend an hour thinking about the hiring plan” or “spend an hour thinking about the teams priorities for the next month.” The key part here is to actually take that time, and do those things: don’t read email, don’t answer instant messages, don’t get distracted by clerical tasks. This also ensures that you do these things on the company’s time--and not lying awake in bed at home. 

Go to only those meetings where there is an agenda and where decisions might be made. Feel free to delegate to other members on your team and ask them to summarize or alert you to things that might be significant for you. If these are Zoom meetings, request a recording and watch it at 1.5x or 2x speed at your leisure. Resist any meeting that could be solved with an email conversation; try that first and then, as a last resort, have a short meeting. In general, keep meetings short. Start with a default booking of thirty minutes and make sure the topic and the objectives are clear. Manage the meeting and keep it on topic; ask to table things that are off-topic, or drive them into email. Do this even if it isn’t your meeting. Develop a polite but firm “Don’t waste my time, I’m busy” vibe (which I also used to call the “Fuck-off” pheremone) to discourage time wasters and meeting addicts.

The other side of time management is actively maintaining a disciplined boundary between your work time and your off hours. Once I understood this, I essentially committed to work strict eight-hour days. This means focusing and working effectively during those hours; it also means that when you are not at work, you don’t read emails and instant messages. Don’t commit to things that would require you to work “around the clock.” Having this separation gives you perspective and creates a value system for your life independent of your work and your work role. Work to live, don’t live to work.

Americans get such a shitty amount of time off, so use it all: Take all of your vacation and all of  your sick time. Shut off all communication with the company during your vacation. If you don’t want to completely eliminate email and slack from your phone (which is ideal), temporarily turn off the notifications. Of course, this relies on you having the self discipline not to proactively check them. I recommend getting out of your work context as much as possible during vacation time. If you can’t physically travel, plan activities that interest you and will allow you to be immersed in them. This gives you time to recharge, to gain some distance and perspective, and an opportunity to see how things go when you’re away. If your life has no pleasure in it then you’re headed for serious emotional and mental trouble.

Managing your emotional and mental state

I worked for smaller companies for most of my early career. In general, people were somewhat more emotionally invested in the products and their contribution to them. After all, if you were careless, then you and your co-workers could be out of a job quickly. The first time one of these companies was acquired into a Giant Multinational Corporation, I noticed a steady decline in people’s attachments to the product and the team--and in their expression of emotion. I remained quite emotionally engaged, and often sent passionate emails to my superiors when I saw bad stuff happening in the product or in the team. After a bit, the director of our division invited me to a chat. They said, “Look, you’re very talented and we like a lot of what you’re doing, but you’ll never get anywhere at Giant Multinational Corporation by being so emotional.” This was of course delivered in the most medicated deadpan I’d ever heard in my life. It was at exactly that point that I vowed to get out of the Giant Multinational Corporation before I had the life sucked from me. 

When you are an individual contributor, your moods and day-to-day run of emotions (unless they’re pathological) have relatively limited impact on the broader team. When you are a manager however, if you are unaware of your emotions and how you’re projecting them in your communication, in your manner, even in your decision making process, those emotions can have a big impact on your team. I went through a period in the early-middle of my career where I found myself experiencing flashes of intense anger in situations that didn’t warrant them. It got to a point where I had a couple of encounters with people that came just short of employment threatening. I realized (with help from people close to me) that I needed to talk to a professional about it. I started therapy and worked on that for several years. I learned a lot about myself and about what was triggering my emotions, including where some of my defensive behavior towards other humans came from. It helped me make a lot of progress in my career and in my life. I share this because I realized that emotions are ok to have, and that you can’t repress them, but you can understand and manage them.

Your honest expression of emotion based on caring about your team, your project, even sometimes the company, lends credibility to your leadership. People can tell when you’re being real with them, and when you repress your true feelings, it creates a distance that erodes true leadership. Of course, as I mentioned above sometimes anyone’s emotions can go haywire and therefore self-awareness and being proactive about your emotional state (and its causes) is imperative. Even on a day to day basis, you should pay attention to how you’re feeling. For example, if there is a particularly contentious meeting with a challenging person coming up and you are tired or have recently had another emotional challenge, feel free to ask to change that meeting and give yourself some time to recover. If that’s not possible, be aware that you can be triggered more easily in that situation and do your best to manage the encounter so you have time to contemplate your responses.

In order to resolve problems in the workplace, sometimes you have to share your emotional or mental state with someone who is causing you difficulty. Ignoring emotional trauma on a team can create real world impacts, such as failure of communication, underperformance, or lack of teamwork and coordination. These conversations can seem very confrontational, but framed as “When you do X, it makes me feel Y,” it can be a positive discussion that may lead to a better working environment. Avoid attribution in this process, e.g, “You are doing X to undermine me!” You may feel undermined, but you don’t have any idea why they’re doing X until you get them to tell you. Remember that you too have a contribution to these interactions. For example, you might realize that you have a fear of people undermining you from experiences earlier in your life, and that this person’s actions are reminding you of those experiences.

Positive visualization

One challenge that comes with moving from working as an individual contributor to acting as a manager is swapping the instant gratification of accomplishing tasks for the delayed gratification of your team achieving goals, sometimes over years of effort. It can be hard to feel like you’re accomplishing anything and it can be very demotivating. I recommend setting aside a time every day to think about your fantasy positive future for yourself and your team. It can be as detailed as you like and it doesn’t have to be super realistic, but it should represent the feeling of where you’d like to be in the future. Don’t edit yourself, don’t criticise it, just tell yourself a story of success and add in all the things that you dream would happen. You’re not making a commitment to have all or any of these things happen in real life. However, after doing this for many years and looking back at what happened over those years, many of the features of my positive visualization had been achieved. For example, I’m very happily retired, having visualized that outcome for several years. By visualizing it, you’re starting to plan what might be necessary to achieve it, and can (even unconsciously) influence a lot of the micro-decisions that happen every day and creates a direction that you might not recognize existed, save in retrospect.

It also lets you recognize whether the longer arc of your team’s progress is being achieved more efficiently than any list of statuses on tasks. Being a fantasy, it is flexible, so if a macro-economic change occurs, and changes the whole business, you can just add it to the story and start thinking of the new positive outcome.

360 Feedback

You may or may not get feedback from your own manager; even if you do, the quality of the feedback will depend on how good a manager they are. Actively seek 360 degree feedback from your management chain (not just your manager), including your peers, your stakeholders, and the folks who work for you. Ideally this should be through an anonymous mechanism, perhaps through your manager or HR, so it can be honest without fear of retribution. There are many frameworks to help folks structure and express their feedback constructively. I recommend picking one and using it; lack of structure tends to make all but the very stroppy not respond. Before you look at any feedback, evaluate yourself honestly in the same terms, using the same questionnaire. Compare your answers with the feedback that you get back, look for gaps and conflicts, the areas where you think you’re doing one thing and others see it as the opposite. These are opportunities to get better at your job, so every candid, thoughtful piece of feedback is a gift that to be cherished and considered. Look for significant signals supported by multiple people and work on those things in the interval between repeating the feedback, quarterly or every six months.

Relationship management

Your team has stakeholders and dependencies on the teams run by your peers, so pay attention to your relationship with them. It is often easy to get immersed in the details of your own team’s tasks and ignore the broader context that is around your team. Make sure to connect with, and listen to, your peers and stakeholders at some regular interval. Some may have more priority for your team than others, and the frequency and intensity of contact should vary proportionately, but this maintenance will help your team succeed. 

Be there for your peers if they need advice, or if you need advice, pay them the compliment of asking them for theirs. Be open with them, and offer help and support if they need it. Building strong relationships can help protect you in cases of larger political dysfunction in a company. Always deal with them with integrity; don’t mislead them, and if your team is failing to deliver for them in some way, own up to it and work to mitigate the impact.

Playing to your strengths

Nobody is all-around awesome; we all have strengths and weaknesses. As a manager, you should structure your team and your processes in order for you to play to your strengths and minimize exposure for your weaknesses. There are many tools and books that can help you identify what you’re good at and where you need work. People frequently try to “improve” in their areas of weakness and, certainly by craft and practice, you can get better in some areas. In the meantime, however, there is often a person standing next to you who has the skills you lack, and you could empower them immediately and see results immediately. I am very much not a detail person, or a perfectionist, so projects that are imperative, but filled with a million boring details, each of which needs to be perfect, are not my thing. However, when I’m hiring I look for folks who love that sort of thing, who describe themselves as obsessive about details and enjoy ticking off all the boxes. I try to balance my team with some of them for just these sorts of projects; conversely I don’t send those same folks off on quick and dirty “lean” projects to test the market.

Learn how to negotiate

Once I started managing teams with multiple stakeholders, I realized that much of my job involved negotiation. Teams always have more demands on them than capacity to meet them, so you are always trying to prioritize your stakeholders. All stakeholders think they are the most important--hence the negotiation. I also realized that just advocating for what I wanted (or what I thought was the most reasonable) wasn’t working. I got my company to send me to a course at Harvard that focused on negotiation. It was one of the most useful courses I’ve ever taken. I came away with an entire framework for approaching negotiations and for finding compromises that were mutually beneficial. It also turned out to be a good life-skill in totally non-work related situations.

Be kind to yourself

My new boss only talked to me for thirty minutes every three weeks. That actually wasn’t so bad, since at this point I was pretty experienced and I didn’t require a lot of direction. The content of those meetings were mostly them downloading the new things that were wrong with my team and my product, and the additional un-scoped, un-staffed tasks we needed to accomplish. Every so often at the end of our time I’d ask “So, is there anything that we’re doing well?” and there would be a pause like an old computer having to spin up a device long asleep, followed by a couple of sentences acknowledging the good work we’d done. Of course, that was usually followed by a reminder of the latest things we needed to work on, so we wouldn’t become complacent.

Finally, and this is going to sound nuts, praise yourself. Not out loud to anyone else (except maybe to your life partner), but to yourself. Say “That was fucking awesome, I made that happen!” or even “I love me!” I know, I know, across many cultures, for whatever fucked-up reason, we’ve all been taught not to be proud. “You’ll get a big head!” or “Don’t be so bold!” or “Don’t be arrogant!” I’m not suggesting that you be blindly self-congratulatory or praise yourself even when you’ve fucked up: Own that shit and do better.  However, when you do things that you know are good, acknowledge them to yourself, even if nobody else decides to notice. This also helps your independence from a withholding boss; these folks often withhold praise to goad achievement-oriented employees into jumping higher and higher for them. Don’t fall into that trap; appreciate your own achievements and take pleasure in them.

I was new at the company and was a few months into running my new team. I was excited that I had gotten the team to start shipping features again, and I was resolving a bunch of the productivity issues that had been blocking them. I was called into a meeting with our CEO and my peer on our biggest stakeholder/dependency team. The CEO proceeded to take us to task for not coordinating the release of a new feature that my peer’s team had shipped. I was pretty amazed: Everyone had told me that “culturally” we didn’t do that sort of thing at the company. We shipped things when they were ready and we didn’t worry about the short-term marketability. It was made clear to us that we needed to fix this lack of coordination or the CEO would fix us… I felt incredibly stupid to have led my team into this spot when I should have known to question the “culture” story, and ascertain that it was not just the old “culture” that we were discarding as the company grew. It kept me up at night, going over it in my head relentlessly for days. Finally, I realized that I needed to take control of our relationships with our stakeholders, even going so far as to staff teams inside their organizations so that we could truly coordinate and support them as customers. I also started discounting the “culture” stories that old-timers tried to impose on me and paid attention only to what the CEO was doing now. I slept fine once I saw the path forward.

When you make mistakes, you should certainly acknowledge your mistakes and take responsibility for mitigating them--but do not beat yourself up about them. Everyone makes mistakes, and many of the folks whose persona is “I’m the big expert and I’m never wrong” are often the folks who make the biggest mistakes and then try to bluster their way past them. You learn by making mistakes and by fixing them and then figuring out how to not repeat them. This brings up a corollary: “It is better to make your own mistakes and not someone else’s.” There will always be a lot of people who want to tell you how to do things, and you should certainly listen to them and evaluate their advice. If you don’t agree with their reasoning, and you are more comfortable with your own approach, you should follow your own direction. If you’re wrong, and it’s a mistake, you learn something valuable about how you were approaching that situation. If you follow someone else’s direction when you don’t agree with, or understand it, and it fails, you are left holding the bag anyway and you haven’t learned anything nearly as useful. 

These are the aspects of self-management that I’ve found to be most productive over the years. It turns out that doing these things in your non-business life is also very rewarding.

Management: Managing up

I’ve been writing a series of posts on management based on my experiences. If you’re starting with this one, you may want to have a look at: https://www.jlgoodwin.com/words-pictures/2020/9/17/management-the-job-of-a-manager

Introduction

Sooner or later every manager ends up in a situation where they need to get their boss to do something and directly asking them isn’t going to work. This is what “managing up” is. Of course, it is always best if you never have to do it; ideally your boss is doing their job well and you are in alignment with them on what your team is doing and how it is performing and on the overall goals of the organization. The first alternative is to try the direct approach and give your boss the chance to do the right thing or give you a different approach to use. But, because humans are flawed, organizations are a bit fucked, and you don’t often get to recruit and hire your boss, you’ll eventually have to try managing up.

When to manage up

My boss was promoted into a role that was way beyond their experience level due to friendship and nostalgia for the early days of the company. They realized that they were completely over their head and that in reality, I was both their most experienced direct report and more qualified for their role than they were. I wasn’t interested in their new role, and I wasn’t jealous. I offered to help in any way I could. Instead of accepting my offer of help and trusting me, they decided they needed to tell me how to organize my team, manage my directs, and run certain key projects. This was mostly so that I would “respect” them. After a while, I stopped trying to clue them in to where they were failing and instead I did the nonsense things they asked for and minimally complied. While never openly opposing their processes, I demonstrated better processes on my team that my other peers noticed and began to copy. I followed my own direction with my team and we succeeded more and more. The contrast wasn’t flattering vs. my boss’ other failing teams, which took up most of my boss’ time. Eventually my boss stopped meddling in my team and was heard to point to us as an example of a successful team.

In many cases, managing up isn’t worth it. If you look at the entire operation of your organization and your company and it’s a chaotic failing mess (and there is no obvious path to a good upside for you), then you should focus on finding a new job and just surviving this one in the meantime. However, if your boss is an anomaly in an otherwise good organization, then it is probably worth managing them a bit. I can’t emphasize it enough that you don’t want to take over your boss’ entire job in the process; many are lazy and incompetent enough to accept the offered scapegoat. You only want to manage them relative to your goals and your team's goals and succeeding for the company.

Some signs that it is time to manage up may include a situation where your manager commits your team to deadlines and deliverables without speaking with you or the team. You end up in a review meeting with your boss’ boss and find out that you’ve failed at a goal you either never heard of or were told wasn’t high priority. Or your team is regularly disrupted by “last minute” projects that seem to come from nowhere. Or you are constantly asked to take on more work and to get your team to “work harder/faster” without any clear explanation of why and no offer of more humans to do the work.

Some techniques

I was the Software Architect for the team and nobody reported to me. The problem was that while I could design the software system to my heart’s content, the team seemed incapable of making progress on implementing it and putting it into production. The manager of the team was a major contributor to the problem: They were a “yes” person and agreed to everything they were asked. Sprints were packed to the gills with all kinds of tasks that had little to do with the platform we were supposed to be building. At the same time, much of the team’s time was spent fire-fighting an existing system that was critical to the business and riddled with technical debt, major design flaws, and single points of failure. The manager never focused any effort on root cause analysis or technical debt reduction, only on random tasks, which also didn’t get done because of the fire-fighting blowing up the sprints. Eventually, my boss’ boss called me in to castigate me for not fixing these problems. I was genuinely perplexed: I was hired to deliver an architecture for a new platform, not fix the team. After a heated discussion, I agreed to fix it, but only if I was given a completely free hand. I then engaged in a detailed root-cause analysis that didn’t stop at just the technical issues, but examined the process and management problems that let the production issues persist, thereby putting the business at risk. I hijacked the whole team and we fixed the major issues in the existing platform. It became clear that the manager was one of the major root causes, since the same team that couldn’t get anything done before was immediately very effective. I ended up managing the team temporarily and helped them recruit a much better manager.

You want all of your efforts to be perceived as positive and supportive of your boss. Arguing with them about their mistaken ideas is largely a waste of time; often they are insecure, attempting to cover their failures by acting the way they think confident people act. Always listen to them, always show them that you’ve heard them completely, always try to minimally comply with any stupid stuff they want. I propose a process that a former manager of mine dubbed “parallel monologue” where instead of trying to refute your manager’s position or argue with it, you merely acknowledge it and then add your ideas. Often you can just tell other team members and peers your idea and after a while you’ll find these ideas making their way to your boss.

Find out what your boss’ goals are supposed to be from their boss, from sales, from marketing, from support. Find out what the business actually needs your team to do. After listening to your boss, start a parallel monologue with them about what you’ve learned matters to the business. Not in opposition to them, but in addition to them. If they resist, accept it and say thanks for the guidance. Assign people to the real goals, even if it is part time. Seek opportunities to show your boss’ boss that you and your team understand what the real priorities are. Share all the credit with your boss to gain credibility and leverage with your boss’ boss.

When you know your team is going to be disrupted, say “Yes, Boss!” Then, very positively say, “I’m just going to let folks know that we’re not going to be able to work on [the true high priority] so they can replan.” If they demand that you keep the information to yourself, you should make sure to reiterate your suggestion that folks be notified in an e-mail or status report, and note that you’ve followed their guidance and are grateful for it. If they’re starting to see the benefits of your parallel monologue, they may at this point start to reconsider disrupting the team and your team cadence and productivity can improve.

Develop a relationship with your boss’ boss (or even higher up) and talk to them about how wonderful your team is. If they ask you direct questions one on one about your boss, be honest, note all of their positive attributes first, then explain how you’re often surprised by their actions that cause your team to fail. Repeat your parallel monologue on how you think things could be better, showing that you know what the business needs from your team.

Through everything, keep up the parallel monologue with your boss, agree with them, then say “and,” followed by your thoughts on what to do. Make sure to do this one on one. For many of them, once they see positive results from your team, you will hear your words coming out of their mouth. Don’t note this, don’t take credit, just keep up the parallel monologue and keep focusing your team more and more on the real business goals of the company.

Replacing your boss

One result of processes like this is that your team will start to look like a bright shining star in an otherwise murky sky. Folks will begin to wonder why the rest of your boss’ organization sucks so bad and yours is doing so well. Depending on the level of incompetence in the upper management of your particular company, they will eventually do the math and want to replace your boss. You don’t need to be that person if you don’t want to, even if they offer it to you. Only do it or ask for it if you feel ready and actually want to. But otherwise, you must work to get involved in recruiting your new boss, up to and including volunteering to run the recruiting process. This will give you the best opportunity to get someone into that position who will be good for you and your team. Yes, it will be a lot of work. Yes, it will be worth it.

Have you been “managed up”?

Recognizing when one of your team members is trying to manage up can be informative and a signal that perhaps you’re messing up. Being far from perfect, I’ve had the epiphany several times “Heeeeeyyyy, they’re using my techniques on meeeeee!”  After some introspection I usually own up to my blunder, ask them to take charge of the process they’re trying to manage me into, and praise them for taking initiative. In some cases, it isn’t so positive, often when it is a  purely self-serving move on the team member’s part. I’ve had managers try to get me to do their presentations for them, deal with the performance problems on their team, fire people for them, even get rid of peers they think are competing with them. These sorts of things don’t make me inclined to trust, promote or empower someone. In fact, I usually give them a lot more direction, deliverables, and scrutiny to see if they’re doing any of their job right. Sometimes you can provoke some “managing up” from your direct reports, when I see all my direct reports playing chicken with a task that needs to be done with the team, I have been guilty of proposing a heavy “brute force” process in order to provoke someone into volunteering. The clever ones will try to “improve” my process for me and then I have my volunteer. 

Losing your job

Sometimes your boss will see your efforts as a threat no matter how positive your actions are. This is why documenting your compliance with their wishes, your extra efforts for the company, and your advice to them (which they ignored), is good insurance. But you should always be prepared to get fired. If possible, keep your finances in good shape, keep your resume up to date, and make a list of some peers or stakeholders who can give you good references. I’ve never been fired, but I have been threatened with it several times for doing my job and making my boss or an executive above them feel uncomfortable as I did it. The discomfort usually comes from them getting information inside their executive cocoon that most people are trying very hard to keep out of there. The thing that has saved me every time was being more valuable to the company than my boss or the comfort of the particular executive. If you’re going to have a dispute with HR involved and all of that, you want to be doing it from the moral high ground with good documentation.

What does success look like?

In the best case, your boss will realize that you are acting in their best interest. They will start treating you like a valued collaborator and confidant. Or, you’ll get a new boss, one that you helped to hire, and they already like you and trust you because you got them a new job.

Management: Building teams...

If you’re starting with this post you may want to read this earlier post for context: Management: The job of a manager

Introduction

Over the years I’ve joined software teams as their manager that other folks have built and I’ve built some basically from scratch and then evolved, grown and shrunk those teams over years and releases. A lot of what I have to say about the experience has been said by others, but I hope to add some of my own observations that might be useful.

Inheriting or founding a team

The manager before me had been an intense micro-manager, they had required all the engineers to include them in every meeting, every discussion with any stakeholder, they cracked down on engineers and stakeholders alike when this rule was violated. They made every decision, parceled out their team’s work in dribs-and-drabs, they deliberately constrained creative and productive engineers, they rewarded loyalty above competence and ability. In other words they had set the bar low for me and I knew I was going to be very successful...

Most of the time, I’ve joined teams that other folks have hired and organized. Early in my career I took a “they must have chosen these folks for a reason so I should work with what I have”  approach. It turns out however that most teams have been formed haphazardly by people who were short-sighted and had no interest in the concerns of management or long-term team health.  After torturing myself a couple of times that way, I shifted to a model of “I need to evaluate this team and see how completely fucked they are and decide on the one or two things that I have to un-fuck immediately” approach. There is a corollary embedded in this statement: All teams are a little bit fucked and you’re never going to completely address all the issues. You do need to aim for a good operating temperature for the team that trades off performance, morale, stress, interpersonal tension, happiness, and satisfaction. It is often an impulse to try and fix everything all a once; you should try to resist the urge. The less common case is starting a team completely from scratch, all of the advice below applies, but the first concern is to recruit a good lieutenant. If possible choose someone you have worked with before, someone who compliments you in terms of strengths and weaknesses. This person will be a key partner in choosing all the rest of your team members and in establishing the team identity. You will make mistakes, hiring is hard, people are quirky, combinations of people sometimes don’t work out… so even your hand-built team will be a little fucked up… it’s a process.

Gaining the team’s trust 

The very first thing that a new manager with a new team needs to do is gain the trust of the team members. The first thing that I try to do is listen to the team, validate the problems they identify, and try to address one of the most important ones. This can come before any systematic or process changes. It can show that you as a manager are willing to work for the team, and that you are really listening because you are acting on their behalf. It doesn’t need to be the biggest thing, it can even be something that just requires some focused effort and attention. It is important that you do the work yourself. The second thing is to be transparent with the team, share as much information about what you’re discovering about the team back to them, along with your ideas about what’s important and what needs to be done. Then, you guessed it, listen… weigh the feedback of the team, adjust the priorities, adopt their suggestions if they’re better than yours. Finally, have integrity, for me this means being openly responsible for your decisions and actions. If you say you’re going to do something, do it. If you make a mistake, take responsibility for it. If you need to change a plan, say so and explain the reasoning.

The un-fucking process

As the new manager from the United States, from a just acquired company, from outside Europe, I didn’t have a lot of credibility with the team to start. I spent two weeks in-country with the team and talked to each team member individually and observed their interactions over the course of a release of the web service we were building. I didn’t change anything, I didn’t offer any opinions, I just watched them… Several things became obvious to me: their technical leader was incompetent, they had no experience building large scale web services, they weren’t competent to make the changes to the open source software we were using that they had made, they had no repeatable process to create a release and verify it’s quality, they had no logging or metrics coming from the production deployment and so ( it turned out ) they were missing the fact that 60% of requests from clients were failing, the architecture of their web service was a complete non-starter. I built all my future team and project plans on correcting these issues…

What should you choose to un-fuck first? Different teams will have different problems but first and foremost if the team is under-performing on their goals for the company, you should address that. Watching the team try and do a release is often instructive for diagnosing this sort of problem. Do they make a plan? Does everyone on the team have a role in the plan? Do they follow the plan? Is the work distributed in a reasonable way by role and by level? Are there people who hinder the planning or execution with discursive discussions, rat-holing, or introducing tasks that aren’t required? Does the amount of work in the plan make sense for the capacity of the team? Do they have any idea what their capacity as a team is? Do they just turn to you and expect you to plan everything?

What you want in a team is a group of people who take responsibility for the product or sub-system that they are tasked with owning and delivering. Based on your observations, find the real competent leaders on the team (or hire one) and empower them. If there are people who are corrosive and are breaking the team, get rid of them, even if they are “the guy that knows everything.” If the team has no process and no plan, help them to figure out what they want their process to be and to follow it. Do not dictate it, do not volunteer to operate the process. If there are people who are hanging back and using chaos to do little or no work, give them direct feedback, call them out at task assignment time, and if they still put in more effort ducking work than doing it, replace them. If there are people outside the team that are removing responsibility from the team by telling them what to do, work hard to redirect those people and get rid of them. If there is a yes-person who is signing the team up for huge amounts of work that they can’t possibly complete, stop them and reduce the expectations on the team and reset expectations about team output. Nothing will cause a team to check out faster than being repeatedly given impossible and, in the end, meaningless tasks to do and repeatedly failing. Fix these things before you even consider growing the team.

Setting the tone

I watched the two supposedly most senior technical people on the team regularly engage in yelling matches as the team sat by in stunned silence. It was probably going to get to a physical confrontation in the near future. The prior manager had not only ignored this behavior, they had often joined in… It turned out that neither of these folks were the right technical leader for the team, one of them I essentially fired and the other I sent to a team that had a complete void of leadership and technical experience. This created the space for a calm, productive, talented engineer on the team who had been doing all the real work behind the scenes to step forward and set a completely different tone.

Once you’ve got the team stabilized, you can look at team dynamics and behavior. A healthy team supports all the members of the team; nobody needs to be “assigned” to help anyone else, they just step up and do it. Even tense discussions should be civil and focused on arriving at a good solution based on facts and real requirements. The most common pathology on teams with regard to dynamics is hiring too many “big dogs,” people with lots of technical prowess and experience, and packing up the team with them. The problem with this in a group of humans is that inevitably, because there is nowhere to progress to, they tend to turn to snarking and sniping at each other and arguing over minor issues way past their actual value. Teams ideally have one or two “big dogs,” who are chosen carefully based on their ability to provide high level control and structure to others, and who are good communicators, good teachers, and good engineers. Then a mid-level of good, less experienced folks take up the majority of the team and a few talented entry-level folks. The actual proportions depend on the sort of work the team is doing.

Teams delivering software products or long-lived web services can skew towards the middle tier; inevitably, the most experienced folks will move on and ideally you will replace them from the top performers and leaders of the middle tier. Teams building custom solutions can sustain a lot more entry level folks and probably should; the work is repetitive and time-boxed. The middle- tier and top-level folks should focus on making the underlying platform efficient and resilient in the face of front-end churn.

When you observe bad interpersonal behavior (or someone comes to you about it or you hear about it in a 360 review), take action to bring the parties together in a discussion. Encourage folks to speak up and discuss interpersonal issues that they have directly with the people that are causing them. Provide mediation, where appropriate, to teach folks how to have a constructive discussion about an uncomfortable situation. In some cases, where intervention, discussion, and even direct feedback don’t solve an issue, removing one or both of the folks creating the behavior problem is appropriate. Of course this above and beyond issues like sexual harassment, which has a very clear process associated with it and which you should follow immediately and in all cases. Of course the opposite is also true: Reward and praise good behavior and encourage it whenever you have an opportunity.

Say out loud and in writing how you expect team members to behave with each other. Often, managers are afraid to talk about behavior, feelings, interpersonal matters: get past that. Everyone comes to your team with a different background and a different life experience, so they all need to be told what the expectations are. Back up these guidelines with appropriate actions, up to and including terminating people. One person can damage a team with their behavior and make everyone else on the team lose performance and fail. Nobody is worth looking the other way for, regardless of their skills or inventiveness. In order for any product to succeed, it needs a team that is going to sustain it for the long term.

As teams change, they often go through periods of dysfunction and chaos until a new team dynamic is established. It may take changes in structure or leadership or just some time for it to settle. This is why you should always be evaluating your teams as you did when you first formed or inherited them, looking for the same things, and addressing the same issues. Teams are always a work in progress. Another classic trap is the belief that your new 20 person team is going to look and sound like your first 5 person team of scrappy entrepreneurs. Ain’t.  Gonna. Happen. And it shouldn’t. What worked for 5 people with no legacy, customers, or competitors doesn’t work ten years later with all of those things and more. Examine whether they are now effective for the company, operating in a healthy sustainable way. It doesn’t matter if it looks different from the five patron gods of the company and their mythological deeds.

Getting bigger

Several of the most senior members of the team were dilettantes, they only worked on things that they wanted to, they didn’t participate in the team’s regular processes, they checked in code that wasn’t reviewed or understood by anyone else on the team. I worked to dis-empower them, it was a delicate process, like a lot of folks that have been in a position for a long time there was a mythology about them that they were indispensable among the other executives. One by one I managed them out of the team, often with them believing that they were attaining an even better position. I replaced them with a well balanced group of people who could collaborate and were willing to do all of the work of the team. The overall productivity of the team grew and morale improved… within a year the dilettantes were gone from the company.

When you’re growing a team, think carefully about what that specific team lacks and put that on the list. Of course you want to hire very qualified folks for the level you’re seeking, but you should also look at the personalities on the team and be on the lookout for folks that would help balance those personalities. For example if the team is all mercurial, less experienced team members and they often build overblown solutions very quickly (that later take hundreds of patches to stabilize and make work), adding someone who is more experienced and more methodical at a higher level can help shape their productivity more constructively. If a team has too many big dogs, look for a couple of middle tier engineers with a good record of consistent delivery and then trade a big dog to another team and backfill to balance the team. 

I recommend aiming for gender parity on your team; having a mixture of people who are socialized differently creates a strong cohesive team and helps a great deal with the atmosphere on the team. A very simple mechanism for this is to scan every batch of resumes you get for women, when you see qualified applicants that are women insert them into the process first. This works for other under represented groups too. You also need to avoid and root out systemic discrimination, questions or concerns that are only raised for women or other under represented group applicants. This often takes the form of code language like “too junior,” when the person has done and is doing the exact work you’re after, etc. The final step, you have to hire them. If you make it a goal and reinforce it as a matter of performance for yourself and your managers, you’ll be surprised how well it goes. Your interviewers should include women and minorities from your team. This reassures minority candidates that they won’t be alone on your team and it gives them someone in the interview process to ask questions about the team culture. It’s also a good social test for all candidates to see if they have issues with the women and minority members of your team. Several times we’ve passed over folks who decided it would be good to cut off and talk over our women interviewers and talk down to them when pressed.

Team morale

When I took over the team, one of the founders of the company had been “helping” what was perceived as a team in trouble. The founder’s model of how to help people was to give nebulous directions and then argue with people when they misinterpreted this direction or when they pointed out obvious conflicts in the direction. The team never received any praise, just constant criticism for not being engineers like the founder. Of course, the founder had no experience in the area that the team was working, or the technology… but, this didn’t dent his confidence that he could tell them what was wrong with them. The team was paralized, very few features could get completed because they were mired in senseless circular arguments. I started a process with the team to define who they wanted to be, what were their goals, what was their idea of quality, what were they going to deliver for our customers. Several iterations of this document engaged everyone on the team in forming a vision of themselves and how they wanted to be. At the same time I worked to manage the founder out of the process, noting that in our fast growing company there were many more vital projects that required the founder’s genius. I praised the team every time they lived up to their goals and standards and the morale on the team improved steadily.

The best team morale/cohesion-building is simply working together on meaningful problems. Morale is highest when the team feels in control, successful, and recognized. If your team doesn’t own what they work on--for example, if an overly controlling product owner insists on defining not just the business requirements but the solution, the architecture, and the technology choices--then no amount of building LEGO structures together is going to fix the disengagement that results. Consultants like these little exercises because you can basically take any arbitrary group and make them feel like they worked together and succeeded. That is mostly because: a.) the objective means nothing and failing means nothing, b.) the problem is simple and bounded, and c.) none of the decisions have a lifespan beyond the session. Apart from maybe being a game to play while you’re drinking, these exercises don’t have any impact on the real workplace. I do think that creating contexts for everyone to participate in planning, process decisions, and implementation decisions is good. By this I don’t mean everyone needs to agree or work on everything; instead, I suggest that when you are forming task groups, insert folks from other disciplines and levels into those groups so they work with team members that they wouldn’t normally and on topics that aren’t in their everyday workflow. This expands everyone’s knowledge of the product and what goes into building it, exposes them to evaluating and understanding requirements, and creates social bonds.

Don’t take engineers’ ideas about how to run the team too literally. Many engineers have naive ideas about how humans work and often devolve to trying to program them like a distributed system. Their ideas do have value as signals about what needs to be addressed in the team. All processes that the team adopts need to be humanized. Humans are not machines; the most consistent of them will vary enough and often enough to matter. They will respond to outside forces from their personal life, they get tired, they burn out, they have subjective responses to people and situations that are unique to them… Therefore team processes have to be fault tolerant and have mechanisms for fault detection and correction.

Getting to the right size

I had worked to build one of my sub-teams and fix it’s culture and staff it appropriately for it’s mission… but they were still struggling to deliver. I realized that their main stakeholder still treated them like outsiders, ignoring them until the last minute, not sharing plans and information, not considering the impact of their decisions on them. I decided to advocate that we move the team into the stakeholder’s organization, of course I had to make it seem like their idea… which I did, and the organization change worked wonders causing the team to gain focus, momentum and productivity. One could look at it as me losing talented engineers that I had recruited at great time and expense… On the other hand I now had a whole group of folks that liked me embedded in our stakeholder’s organization…

I would note that I talk about firing people a few times above, but in reality if you consider these issues as you grow your team, there should be little need. In a recent role, I grew a team from <20 people to >100 people in three years, I terminated five people for various reasons relating to performance or behavior over that time. The team had some of the best engagement scores and productivity of any that I have ever managed. Hire good people, build teams thoughtfully, and you will have a great environment filled with strong leaders. 

Reducing the size of the team is sometimes called for. Products don’t work out in the market, companies make bad investments that catch up with them, and organizations need to be restructured to deal with macro-economic events. In some cases, you are allowed to choose the folks to retain in a restructuring. Think about all the topics above as you plan your restructuring. It is tempting to always choose just the most experienced, and most proficient folks, but doing this will result in a team that is out of balance after the restructuring. Reduce the scope of the team’s responsibilities as it shrinks. I have been asked many times to just go on with everything and do it with half the people. I just gave them back a list of the things we’d be failing at, which was also a good list of things that could be cut if they decided to be reasonable. Sometimes you get asked to lead a team that is already quite large and when you do the evaluation of the team you realize that it is too big and very wasteful. It is tempting to just add the new size of team to your resume and let the waste roll on, but teams like that are often riddled with behavior and morale problems, and eventually companies detect the waste and you are as likely to be disposed of in the restructuring. It is better to cancel wasteful projects, send sub-teams to some other part of the company where they can be productive, and, in some cases, even lay off folks to get the team to a healthy size relative to its real productivity and value to the company.

Conclusion

Finally, I would counsel managers to not meddle too much in the team. Even if there is tension on the team, give it time to be worked out by the team. If you do have to intervene, try as much as possible to do it by coaching the team in a process to identify and resolve their issues. The more that you insert yourself between members of the team, the less of a team it becomes. This also means that you should think about your own transition, try not to make every process dependent on you personally, this will limit the impact if you decide to leave the team or are promoted or reassigned.

Management: Getting the most out of your team's brain matter...

( Continued from: Management: The job of a manager… )

Their division volunteered for every project and everyone there “sometimes” worked on any or all of the projects. Their manager collected teams and subordinates unrelated to any business purpose. The division grew and grew and they proudly touted how many projects they had and how many people. The company praised them and raised them up as an example to other divisions. When an economic downturn occurred, coupled with strong competition, management showed up looking for things to cut. When they looked at this “wonderful” division, they found much that the company could live without. They cut it by two-thirds and then, a couple of quarters later, disposed of it entirely. Many people on the team were shocked: They had stayed with this group for years being unproductive and, in many cases, their skillsets became unmarketable. Now they had to find a new job.

My overall model for deciding what to do with my teams is to think “am I using these folks’ skills and brain matter as effectively as possible?” This means having them help create the goals, solve the problems, make the plans, make most of the decisions, come up with the ideas, come up with the processes, and get the credit for the work. The more that I find myself doing those things for a team, the more I feel like I’m wasting their abilities. The more engaged a team is in the whole process, the more productive and efficient they become. This involves trusting your team and being prepared to back them, even when they make mistakes, but it pays off every time. If you focus on the roles I described [ see Management: The job of a manager ], and give the people in those roles good information and guidelines, coach them and give them feedback, and give them the team members they need, they will take over and drive these things better than you ever could on your own.

Always be looking for emerging leaders on your team, and work to support and empower them. They don’t have to have a leadership title; they can just be the person who provides the drive to get stuff done. Reward that behavior and feed that inclination. Then when your team grows, you already know who to turn to when you need to fill leadership roles.

The company didn’t have a process that you could name; they had a couple of people who indoctrinated new team members in “the way.” When you did something that wasn’t “the way,” one or more old timers would correct you. We sat in a circle and coded together and released the software when we thought it was ready. We released very high quality, high performance software on a regular basis...

I have deliberately not made any specific references to formal processes, because I don’t think they matter much. As long as your process provides the basic elements of a software development life cycle, and gives you as a manager the information you need to evaluate your team and give them feedback, it’s a fine process. It does need to be a process that the team buys into, documents, and follows. A process that changes every week or every release is not a process. Ownership of the process is key, for as soon as the team feels the process is imposed, you have lost a large amount of engagement and productivity. The other thing to guard against with a formal process is that it ends up replacing customer value, business value, and the product as the goal that the team is driving towards. I’ve seen scrum teams with the “perfect” burn-down chart that produced nothing of value to the business for multiple sprints. It’s easy to succeed against artificial metrics that mean nothing to the product.

The manager’s flying monkey came into my office and shut the door. “You’re making a big mistake,” they said. “It’s going to be the end of your career if you don’t get on board…” I had spoken up at a review meeting saying that I didn’t think a product that they desperately wanted to ship was ready. I had a track record of delivering excellent results and doing it fast, while bringing the rest of the team along with me. I laughed at them; it was the most ridiculous and transparent bullshit I’d ever seen. I said, “please do your worst. I can always get another job. Now get out of my office.” Three months later, they were giving me a $40,000 bonus to try to entice me to stay on their team.

I talk a little about politics in passing in order to highlight the things that give you as a manager the most political leverage. Delivering value for your company—and being able to point to it and a cadence of delivering value—can protect you against the worst of incompetent executives. It is very hard for greedy CEOs to ignore your team producing things that make money for the company and listen to a cranky executive that you’ve annoyed tell them you aren’t a “Team Player.” Focus on delivering value and motivate your team around that, and the rest will follow. Or it won’t: Some companies are so profoundly broken that they are entirely driven by ego and vanity. Deliver value while you look for another job—that’s what sounds the best in your job interviews. It does you no good to say that you spent all your time arguing with (and resisting) venal executives and that you failed to lead your team to produce results.

“Don’t manage your peers’ teams” is another corollary in this vein. Figure out which of your peers is good at their jobs, then determine whether you can trust and/or defend your team from the rest. Trying to correct your peers’ flaws, organize their people, etc., is a self-defeating process: It ends up with your team not delivering and you’ll get no thanks for interfering with another team. Sometimes, however, it’s the lesser of two evils to have your team building things or solving problems that aren’t their stated goals, because it protects them from depending on failing teams. If you are asked for feedback, give it: be honest, be factual, be constructive, but don’t volunteer to solve their problems.

“Don’t be greedy or possessive” is another guideline. If you have people on your team that can be utilized better somewhere else, offer them up. Don’t grow your team for the sake of growing it; make sure that the folks you hire will deliver for the company. If something extraordinary comes up in the business cycle and you’re called on to disrupt things to fix it, don’t complain: just do it and get back to normal cadence as soon as possible. These aren’t “your” people; their contract is with the company, and so is yours. If you remember this and act with integrity, you will gain influence and trust.

When I talk about having a contract with the company I don’t mean to suggest blind allegiance, but a recognition that you’re taking money from folks and they have a right to expect you to do what is reasonable for your role. Things like lying, committing crimes, defrauding the company, covering up mistakes, supporting the abuse of employees, enabling abusers, participating in a discriminatory process, etc. are NOT part of that contract. Depending on the company, these things may come up to a greater or lesser extent, and should be prepared to do the right thing. You cannot recross the bridge of doing something unethical regardless of the pressure from above: Once you do it, everyone knows it, and you’ve lost trust and respect. Again, you’re better off looking for another job than ever compromising on these things.

Also, companies are sociopaths. That doesn’t mean that they’re evil, they just don’t care about anyone’s emotional state or livelihood but their own. Part of your job as a manager is to discourage folks from engaging in magical thinking about the company: “We’re all a big happy family”, “we’ll take care of you”, “we’re all in this together,” for example. Employees are worth what they generate (or what they are perceived to generate) in revenue for the company, so I always encourage folks to consider their productivity and where it is being directed. When a project seems like a fantasy boondoggle that will never make money, nine out ten times it is, and the people who go to work on it end up looking for a new job. They might learn great things on that project and get great experience, but they should be cold-blooded about the likely outcome. Every company goes through ups and downs, sometimes very dramatically. Having a loving and caring culture while on the upswing is easy, but the downswing is usually where the reality of being a sociopathic business entity with detached investors becomes evident. Again, the best thing you can do as a manager is to encourage your people to be flexible, productive, and skillful; this will make them the most attractive employees to retain in any restructuring.

Finally, you’ll note that I mention incompetence. It’s part of the reality of large groups of humans doing anything together. You should always approach anyone you work with with the initial belief that they are competent at their job, and continue like that until they prove that false. Incompetence gets into organizations because people often make hiring and performance decisions based on things other than fitness for the role or actual job performance. Basing these decisions on personal loyalty, nepotism, friendship, giving titles to justify pay increases, and other motivations promotes incompetence. It often gets into management because folks become managers by default; I can’t tell you the number of manager candidates I’ve interviewed who said “nobody else wanted to be manager so they picked me.” In good organizations, it eventually gets exposed and corrected, but that process can take a long time. You should be aware of incompetence and where it exists in your organization, and keep your team and its projects from being damaged by it. Also, if you’re not competent, do better—or remove yourself and do something you are good at. Life is too short. Recognizing your own strengths and weaknesses, and being honest with yourself about them, allows you to build a team that compensates for your shortcomings, and lets you focus on your strengths.

Management: The job of a manager...

I recently retired after 38 years in the software industry. I have been a software engineer, architect, chief architect, team lead, development manager, director of engineering, and VP of engineering. I’ve worked on and led teams from <10 engineers to >100 engineers at companies like Lotus Development Corporation, IBM, Intuit, Nokia, Elastic, and a bunch you’ve never heard of. I’ve built software for everything from 8-bit microcomputers to Cray Supercomputers and shipped it in boxes, downloads, web services, cell phones and Linux appliances to customer bases ranging from hundreds of specialists to millions of consumers. I’m sharing these retrospectives just to say “here’s my perspective…” I think there are lots of ways to succeed in the complex business of software engineering, these just describe my approach..

I have been asked more than once: “What is the job of a manager?” All of my management experience has been managing software engineering teams. So, my answer is in terms of that field, but I think a lot of it is the same across fields. The HR department might have a whole bulleted list of responsibilities for managers, but I don’t often refer to those. My answer is usually a combination of saying what a manager does and what they shouldn’t do. Often the things you don’t do are very important.

Their manager had created an enormous spreadsheet, listing hundreds of product features, ranked in some arbitrary way. “Here you go, these are  your priorities” they said. There was nothing to tie the features or the ranking to any business goal that could be measured. Weeks later the manager was frustrated saying “Why did they choose to do THOSE things? Those aren’t important.” The team said “See, we ticked off these things from your list! They were easy to get done.”

I think the most vital role that a manager has is to communicate the team’s goals and the relative priority of those goals to the team. This is hard to do well because it involves understanding the reality of the business and organization that you’re working in. It is not as simple as just listening to your boss and passing down whatever they say. You should understand your team’s stakeholders needs and how high priority they are, how much business impact they have, and where your team is in terms of satisfying their requirements. The team itself is a stakeholder, often generating goals internally that need to be aligned with the wider business.

A manager needs to at some regular interval update the team’s priorities and goals and reflect back to the team where they are in terms of accomplishing their goals. It is critical to give ownership of the “how” part of accomplishing the goals to the teams almost entirely. It’s fine to apply “taste & discretion” or “guidelines” to their work, but the manager should not delve down into implementation details. The manager should ask their teams for a plan for how they will address the goals, and that plan should include what is going to happen, who is doing what, and what order things will happen; sometimes they also include time estimates. A manager should provide feedback and coaching on the plan, seek to reduce scope and risk, and question unnecessary work. When the work is in progress the manager should look at how the work is tracking to the plan and suggest re-planning if new information supports that.

All of this planning and feedback should happen in the context of the set of goals and priorities and the goals should support the team’s decisions. If you find yourself or a team going away from those goals, then it’s time to re-evaluate the goals.

A new manager comes to take over an existing team, they’re informed by their boss: “This team is all messed up, you’ve got a lot of performance problems. Here is a list of the people you should get rid of…” The new manager asks “Have you given them any feedback about their performance?” Their boss responds “They know what’s expected of them…” In other words, “no.” The new manager reviews the performance of the people in question and gives them appropriate feedback. The majority of the team improve their performance immediately. Some of them are managed out of the team. The rest of the team gets regular feedback and they steadily improve. 

This gets into the second highest priority of a manager: giving feedback. Once you’ve been clear with your teams about goals and priorities, and they have given you plans and status, which you’ve reviewed, you’ll probably have great content for feedback. First rule of feedback is: “Don’t wait!” As soon as there is an opportunity to learn something together, it is time to talk about it. The punctuated reporting schedule of HR systems is not a good structure for managing successful projects. 

Feedback should be 75% praise, 25% critical feedback. If you can’t come up with 75% praise, you probably have a real performance or morale problem. The 25% critical feedback that you give should be for the highest priority things that are impacting the effectiveness of a team or individual. These should include one to three points, with accompanying suggestions for how to take action as a prompt for the person or team to suggest their own ways to improve. The critical feedback should be something that is measurable in a goal or deliverable.

Solicit feedback regularly from the team or individual’s stakeholders and summarize the trends in that feedback, both positive and critical. Often the best language and suggestions for describing improvements come directly from stakeholders (including peers). Be careful not to overweight feedback based on the age/rank/level of the person giving feedback. Similar feedback from multiple stakeholders is much more useful than cranky feedback from an executive. Of course you should monitor that crankiness and perhaps discuss it with the executive, to try to keep that executive from developing a grudge against your team or employee.

The CTO would rigorously review every project schedule with dedicated project managers, schedules, and task lists. The same CTO would drop in on the most productive engineers and ask them to build things for them, speculative projects that didn’t appear on any plan. Projects would then miss their dates, deep concern would be expressed, and pressure applied to correct the issue… The speculative project would be sidelined and never shipped. The cycle would repeat.

The third thing is to drive a cadence in the work of your team and protect them from chaos agents. In some companies that are very early stage or prototypical startup efforts, chaos is the normal environment, but there are processes to focus and control that chaos and as a manager you should work to do that. The key thing is to allow your team to complete projects and have the satisfaction of delivering things to the market. This isn’t as simple as saying “no” to everyone; it involves working with your teams to determine a structure for how to acknowledge, prioritize, and sequence the new work that inevitably comes in. The other thing to fold smoothly into the workflow is technical debt or maintenance. This needs to be a high priority and carefully chosen, so that it doesn’t end up completely overwhelming the flow of work at random, unpredictable intervals.

Supporting your team in resisting distractions when they come in (from executives with a great idea, internal teams hacking up competition to their products, etc.) is a key part of this process. There may need to be some reserved capacity for ego maintenance of executives, but like a lot of political capital, it needs to be carefully managed because the backlash will be even worse if the team fails in its core mission for the company while delivering an executive’s pet project. Usually engaging executives in the boring process of figuring out all the trade-offs required to make room for their project can make them wander off to bother a different team.

Everyone who applied and passed the phone screen by the recruiter was sent to do an online coding test. Anyone who got past the test was interviewed by the team. People were often rejected after seven interviews, seven hours, by at least seven different people. The team’s hiring rate was very low and the people they spoke to were often not senior enough for the role and were being rejected at the final executive interview. None of the interviewers were clear on what they were interviewing for and what criteria they should use; they often passed people along figuring the next person would reject them. Sadly, the automated coding test was causing some of their best candidates to be offended and to simply opt out and take a different job at another company.

The final key is to make sure that you have great people on your team and that they are the right people for what you’re doing. This involves hiring as well as performance management and internal staffing. You should be clear on the profile of the folks the team needs, both from a “skills and experience perspective,” but also personality type and social fit. The hiring process should be as short as possible, but comprehensive in having at least a couple of people check out each attribute you’re looking for. I personally like combining an interview step with multiple goals; for example, an interactive coding session with two engineers and having the candidate work through the problem with them and interact with them in a similar way to the way the team would work. This can answer questions beyond “can you code?” and get way into team fit.

Like any process, you and your team should examine your hiring process at regular intervals and ask if it is delivering what you want. For example, it is expensive to have your team interview and then not hire people. So, the more that candidates can be screened at the resume screen or at the initial phone contact, the better. Likewise, if you have an executive approval phase in the interview process, you should have addressed all of that executive’s concerns before a candidate gets there, because that is the most expensive time to have someone exit the hiring process.

“Look, “ I said “you are very good whenever we have a support escalation, I get messages from customers praising you and marveling at how passionate you are about solving their problem. On the other hand, you struggle to keep up with even our most junior engineers, people have to step in and correct or redo your work. You are visibly unhappy whenever we talk about your job…” They had already started sobbing. I continued, “Why don’t we talk to the support organization and see if they have something…” They look up in amazement. “You’re not firing me? You want to help me?...”

Performance management is the other side of the coin, and you should act promptly when someone is under-performing. Effective 360 reviews and close examination of status vs. planned assignments will help identify team members who aren’t meeting their goals. Finally, metrics on code base productivity can be useful to support or refute a performance issue. Understandable feedback (along with clear explanation of the consequences of not improving) is crucial all along. Again, don’t wait for a review: As soon as you know something is going on, give the feedback. There are HR processes for dealing with folks who can’t listen to feedback and respond to it. Don’t be scared of them—work with your HR person and replace people quickly who are not performing well. Even in the best teams, a poorly performing person is a drag on morale and will impact the whole team.

A different problem is having the wrong person for a role. Once you recognize this, start a career path discussion with that person. Sometimes they can find a role in the company better suits them, and you can replace them with someone who is a better fit for your team. You can usually differentiate this situation from other performance issues because the person will sincerely try very hard to respond to feedback, but will swing back and forth, first getting better, then worse. They will also show symptoms of disengagement, lack of attention, lack of communication, etc., so it’s vital to suggest changing roles for folks in this situation.

I talk about some organizational context for these four parts of a manager’s job in the next post: “Management: Getting the most out of your team’s brain matter…”